ReentrantLock（AQS），Volatile，Sync
本文参考：
JUC学习（八）：AQS的CLH队列
并发编程——详解 AQS CLH 锁
JMM和底层实现原理
AQS
ReentrantLock类关于lock接口的操作都交给了内部类Sync类来实现，Sync类又有两个子类NonFairSync，FairSync，公平锁和不公平锁；
abstract static class Sync extends AbstractQueuedSynchronizer
static final class NonfairSync extends Sync
static final class FairSync extends Sync
AQS重要成员变量
private transient volatile Node tail; // CLH队列
private volatile int state; // 锁的状态
AQS使用的设计模式：
模板方法设计模式：定义一个代码模板结构，相同部分在父类实现，不同部分由子类实现
模板方法模式（Template Method） - 最易懂的设计模式解析
安卓中的View，Activity都使用了模板方法设计模式，View类规范了所有View需要实现的行为，View的子类可以在onMeasure，onLayout，onDraw中扩展各自不同的行为；体现了设计模式的开闭原则
AQS抽象类为子类提供了tryAcquire，tryRelease去扩展自己的不同行为
NonfairSync：
NonfairSync.lock()
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean compareAndSetState(int expect, int update) {
// See below for intrinsics setup to support this
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
首先通过CAS尝试将AQS的state由0变为1，如果成功，说明当前锁没有被线程持有，调用setExclusiveOwnerThread（）设置当前线程持有当前锁即可；
如果失败了说明当前锁被持有，调用acquire（1）；
acquire()
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
在acquire（）中，首先调用了tryAcquire（）尝试获取
NonFairSync的tryAcquire的实现
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
首先判断AQS的state是否为0，如果是0，则当前锁为被持有，设置当前线程即可，如果不为0，说明当前锁被持有，并且有另一个线程尝试进入，则将AQS的state+1（类似synchronized的monitor的进入数）；
addWaiter（）
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
enq(node);
return node;
}
addWaiter的作用是将为获得锁被阻塞的线程打包成Node添加到tail链表（队列）中保存起来，添加链表节点的过程使用了CAS添加；
UnFairSync lock
回顾一下UnFairSync的lock（）过程：首先尝试通过CAS将锁的状态（AQS的state）由0变为1；如果成功说明锁未被持有，设置当前线程持有即可，如果失败，说明锁已经被持有，调用acquire（1）；在acquire（）中，1首先调用tryAcquire（）再次尝试获取锁，如果失败将锁的state+1，2其次调用addWaiter（）将当前线程包装成Node放入等待队列AQS的tail中，3调用当线程的interrupt（）尝试中断；
unLock（）：
public void unlock() {
sync.release(1);
}
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
unLock()做的事情：将锁的state-1，如果state==0了，在等待队列中唤醒一个线程；
公平锁和不公平锁的区别：
FairLock.lock（）
final void lock() {
acquire(1);
}
公平锁的lock方法是直接调用acquire（）；
tryAcquire的实现：
/**
* Performs non-fair tryLock. tryAcquire is implemented in
* subclasses, but both need nonfair try for trylock method.
*/
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
在调用tryAcquire（）尝试获取锁时，公平和不公平锁的实现稍微不同，公平锁会在state == 0的时候直接设置当前线程去持有锁，而非公平锁会调用hasQueuedPredecessors()去判断tail等待队列中有没有比当前线程等待时间更长的线程，如果有，就不会设置当前线程去持有锁；
AQS内部的CLH自旋锁
CLH是一个基于链表（队列）的自旋（公平）锁，每一个等待锁的线程封装成节点，不断自旋判断前一个节点的状态，如果前一个节点释放锁就结束自旋；
AQS的CLH队列tail对CLH自旋锁进行了两个方面改进：
-
节点的结构：AQS中的CLH队列的节点采用双向链表 -
节点等待机制:传统的CLH是通过不断自旋判断前一个节点的状态，AQS改成了自旋+阻塞+唤醒，线程在经过几次自旋后会进入阻塞状态等待唤醒，唤醒后继续自旋，等待前一个线程释放锁，兼顾了性能和效率；
可重入锁的实现：
可重入锁：指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞
- 在 tryAcquire()中判断是否是当前线程持有，如果是则将state通过CAS +1；
- 在释放锁时，只有state为0时，锁才会正真释放，可以被其他线程持有；
JMM
JAVA Memory Model
JVM定义了JMM用来屏蔽各种硬件和操作系统的内存访问差异，即JMM的主要目标是定义程序中各个变量的访问规则；
JMM规定了所有的变量都存放在主内存，每个线程有自己的工作内存，工作内存中保存着主内存变量的副本，线程对变量的访问只能通过自己的工作内存的副本访问，每个线程只能访问自己的工作线程；
内存间交互操作：
JMM定义了8种原子操作用来实现主内存到工作内存的拷贝，工作内存到主内存的同步：
-
lock 锁定:作用于主内存 ，将主内存的一个变量标识为一个线程独占 -
unlock 解锁:作用于主内存，把主内存中一个处于被线程独占的变量释放出来 -
read 读取:作用于主内存，把主内存的变量传入到工作内存，配合load使用 -
load 载入:作用于工作内存，配合read将主内存的值放入工作内存的副本中 -
use 使用:作用于工作内存，当虚拟机遇到一个需要使用这个变量的字节码指令时，将工作内存变量的值传递给执行引擎 -
assign 赋值：作用于工作内存，当虚拟机遇到一个需要给变量赋值的字节码指令时，从执行引擎接收新的值传入工作内存 -
store 存储：作用于工作内存，将工作内存的一个变量传递给主内存，配合write使用 -
write 写入：作用于主内存，配合store将工作内存副本的值在主内存更新
Volatile：
被volatile修饰的变量具有可见性，有序性，保证单个变量的读写的原子性(i++不保证)
volatile原理：
- 被volatile修饰的变量会存在一个
lock前缀，lock前缀的作用是将当前线程的工作内存中副本值直接写入主内存，并且将其他工作内存的值失效（立刻执行store，write操作）；强制刷新变量，保证可见性； - lock前缀还有一个功能：
内存屏障（重排序不能在内存屏障前执行），抑制重排序，保证有序性；
happen-before：先行发生原则
如果操作1 happen-before 操作2，那么操作1 的结果对 操作2 是可见的（仅要求可见性，不要求有序性，可以重排序）；
- volatile规定了变量的写 happen-before 变量的读；
Synchronized原理：
每一个对象都会有一个monitor，monitor是由C++实现的一个ObjectMonitor类，可以理解为一个实现线程同步的对象；
Monitor的属性
-
当多个线程同时访问同步代码块时，会先将线程放入
EntryList中，当一个线程持有monitor对象后，会count++，设置owner为此线程； -
如果
owner调用wait（）或者同步任务完成，就会将count--，owner设置为null，并且将这个线程放入WaitSet，等待下一次被唤醒
monitorenter:
遇到monitorenter指令会尝试获取monitor对象，通过判断monitor对象的count是否为0，如果count = 0，当前线程就持有锁，count++，如果不会零，就阻塞，如果持有锁的线程重新进入锁，count继续++；
monitorexit：
执行exit指令的线程必须是锁的持有者，执行完exit后，monitor的count--，如果count == 0，则退出锁，被阻塞的线程可以尝试获取锁；
同步代码块时通过enter/exit字节码指令实现的，如果是同步方法，就会在方法的字节码加入一个ACC_SYNCHRONIZED的flag，如果有这个flag，表明这是一个同步方法，线程在执行时会尝试获取Monitor对象（静态方法是类的Monitor，非静态方法则是实例对象的Monitor），本质上和enter、exit一样都是通过Monitor对象来实现的；
synchronized优化：
在早期的版本中，使用synchronized关键字加锁都会将拿不到锁的线程进行阻塞，需要上下文切换，效率较低，在jdk1.6以后对synchronized锁进行了优化；
-
锁消除：在代码上加了锁，但是虚拟机判断出这一块代码不可能被多线程竞争，就会把这个锁消除掉；虚拟机判断的依据是逃逸分析
逃逸分析：
分析对象的动态作用域，当一个对象在方法中被定义后，它可能被外部其他方法访问（作为参数传入），这种称为方法逃逸，如果被其他线程访问，称为线程逃逸，如果能证明这个对象不会逃逸到其他方法或者线程，虚拟机会对它做一些优化：
- 栈上分配：对象的内存存放在栈帧中而不是堆上；
- 同步消除：锁消除
- 标量替换： 标量：一个数据无法分解成更小的数据，比如java原始类型；聚合量：可以被分解成更小的数据，比如对象；如果逃逸分析证明这个对象不会方法逃逸，并且这个对象是聚合量，那么程序执行的时候可能不会创建这个对象，而是创建它的成员变量；
-
锁粗化：如果虚拟机检测到一串操作都对一个对象加锁，释放锁，将会把加锁的范围粗化到整个操作的外部；
StringBuffer stringBuffer = new StringBuffer();
stringBuffer.append("加锁----释放锁");
stringBuffer.append("加锁----释放锁");
stringBuffer.append("加锁----释放锁");
@Override
public synchronized StringBuffer append(String str) {
toStringCache = null;
super.append(str);
return this;
}
上面的操作就会进行synchronized锁粗化的优化
-
自适应自旋：自旋时间由前一次在同一个锁的自旋时间和锁的拥有者状态来决定，如果虚拟机判断获得这个锁的可能性很大，就会增加自旋时间，如果觉得很难获得锁，可能会省去自旋这一步节约CPU； -
偏向锁：这个锁会偏向于第一个持有它的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，减少加锁／解锁的一些CAS操作（比如等待队列的一些CAS操作），这种情况下，就会给线程加一个偏向锁。 如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁 -
轻量级锁：由偏向锁转化来，相对于传统的重量级锁，不会阻塞线程，而是通过自旋进行等待；以CPU为代价，避免线程的上下文切换，追求响应速度；偏向锁切换到轻量级锁会Stop the World
