并发学习第六篇——Unsafe类和CAS

之前看JUC的源码，一直有发现一个怪异的类：Unsafe，怪，是因为名字有点怪......它在sun.misc包下，

不属于Java标准，但是很多java的高性能的类都基于Unsafe，而且它竟然可以直接操作内存，让java直

接操作内存是很危险的，这个类就明着告诉我们，不安全，不要直接用我

先看一个最常见到的方法：getUnsafe()

private Unsafe() {} 

private static final Unsafe theUnsafe = new Unsafe();

@CallerSensitive  ------这个注解查了下是用来控制权限的，跟踪到最初的调用者，望文生义：调用者敏感的
public static Unsafe getUnsafe() {
     Class<?> caller = Reflection.getCallerClass();
     //仅在BootstrapClassLoader加载时是合法的
     if (!VM.isSystemDomainLoader(caller.getClassLoader()))
         throw new SecurityException("Unsafe");
     return theUnsafe;
}

很容易看出来是个单列模式，上面的注解，用来控制权限，可以跟踪到最初的调用者，可以望文生义的理解：

调用者敏感；普通调用者调用直接抛异常，必须是systemDomainLoader这样的classLoader（BootstrapClassLoader）

Unsafe类提供的API的脑图：

CAS操作

/** 
 * @param o 包含要修改field的对象 
 * @param offset 对象中某field的偏移量 
 * @param expected 期望值（预期的原值） 
 * @param update 更新值 
 * @return true | false 
 */
public native boolean compareAndSwapInt(Object obj, long offset, int expect, int update);
public native boolean compareAndSwapLong(Object obj, long offset, long expect, long update);
public native boolean compareAndSwapObject(Object obj, long offset, Object expect, Object update);

Unsafe提供的CAS操作有这三个，都是compareAndSwapXXX的形式，执行的是一条CPU的原子指令（cmpxchg）

CAS操作有3个操作数，内存值M，预期值E，新值U，如果M==E，则将内存值修改为U，否则啥都不做

这个对比下mysql中的MVCC机制很好理解，MVCC存的是个隐藏的版本号值，做记录变更的操作时会拿

先前已经获取到的版本号跟当前记录最新的版本号做比较（就像比较M和E），然后决定操作是成功还是失败

典型应用：java.util.concurrent.atomic相关类、Java AQS、CurrentHashMap

这里讲CAS,需要顺带提一下坊间关于CAS设计存在的三个问题：

1、ABA问题

很好理解，既然比较的是值，那最新的值A可能是变成了B后又变回了A，如果要求A不变指的是完全没变，而不是结果没变

那CAS无法判断，这个时候可以加版本号解决，如上面说的mysql的mvcc的设计,java里有专门的针对此问题的设计类：

AtomicStampedReference

2、自旋消耗

经常见到的是 while(!compareAndSwap(a,b,c)){},然后就一直自旋转，如果自旋一直不成功，会一直让CPU花费开销

聪明的设计者自然有应对之策-------->  自适应自旋锁：

即自旋的次数不再固定，而是由前一次在同一个锁上的自旋次数及锁的拥有者的状态来决定

补充一下：LongAdder这个类，可以将单一变量的CAS操作分散为对数组Cell中多个cell的CAS操作，最后再求和，也是

解决的一个思路，java8已提供

3、只能支持单个共享变量的原子操作

这个问题思路也好解决，多个共享变量组合成一个对象，只要保证对象可原子操作即可------->JUC中的AtomicReference

内存操作

包含堆外内存的分配、拷贝、释放、给定地址值操作等方法

在Java中创建的对象都处于堆内内存（heap）中，堆内内存是由JVM所管控的Java进程内存，遵循JVM的内存

管理机制，JVM会采用垃圾回收机制统一管理堆内存。

堆外内存存在于JVM管控之外的内存区域，Java中对堆外内存的操作，依赖于Unsafe提供的和memory相关的

native方法，如分配内存allocateMemory，扩充内存reallocateMemory，释放内存freeMemory

线程调度

包括线程的挂起，恢复，锁机制方法

//取消阻塞线程 
public native void unpark(Object thread); 
//阻塞线程 
public native void park(boolean isAbsolute, long time); 
//获得对象锁（可重入锁） 
@Deprecated 
public native void monitorEnter(Object o); 
//释放对象锁 
@Deprecated 
public native void monitorExit(Object o); 
//尝试获取对象锁 
@Deprecated 
public native boolean tryMonitorEnter(Object o);

锁机制相关的native方法已过时，不关注

park：将一个线程挂起，调用park方法后，线程将一直阻塞直到超时或者中断等条件出现；

unpark：终止一个挂起的线程，使其恢复正常

典型应用：

Java锁和同步器框架的核心类AbstractQueuedSynchronizer，通过调用LockSupport.park()和LockSupport.unpark()

实现线程的阻塞和唤醒，LockSupport的park、unpark方法实际是调用Unsafe的park、unpark方式来实现

LockSupport先点名，下一篇上

内存屏障

有点熟悉，volatile也用到了内存屏障，用来禁止代码重排序，Unsafe的这几个方法也是为了禁止重排，理解上是一样的

//内存屏障，禁止load操作重排序。屏障前的load操作不能被重排序到屏障后，屏障后的load操作不能被重排序到屏障前
public native void loadFence();
//内存屏障，禁止store操作重排序。屏障前的store操作不能被重排序到屏障后，屏障后的store操作不能被重排序到屏障前
public native void storeFence();
//内存屏障，禁止load、store操作重排序
public native void fullFence();

典型应用

java8中读写锁的改进版本：StampedLock

StampedLock.validate方法源码：

 StampedLock的典型用法是

1、获取乐观读锁

2、copy变量到工作内存

3、锁状态检测

其中第2和3步要保证不会发生重排序，因为按照执行逻辑，2必须在3之前发生，3处使用loadFence()加上内存屏障，保证顺序

StampedLock类，后面介绍

其他功能，碰到的位置比较少，不做介绍

总结Unsafe类

单例模式的体现；

提供了很多native的不安全操作的方法；

提供了三个CAS原子操作的API方法；

提供了JUC下实现"锁"的基本类(Atomic，AQS，LockSupport)所需的线程调度和CAS方法