本文参考：

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

ReentrantLock（AQS），Volatile，Synchronized的实现原理