上一节重点介绍了Synchronized关键字的剖析，那么本章带你进入另一个锁的实现，就是李二狗写的Lock同步器，生平不识李二狗，学懂并发也枉然！！
1、前言
来看一段伪代码：
//我设计一个锁，这个锁是用来让线程停住，一次只能一个进入一个线程
MyLock lock = new MyLock();
lock.lock();
xxxxx业务逻辑代码
lock.unlock();
退出
假设这个时候有3个线程来了t0, t1, t2
//我设计一个锁，这个锁是用来让线程停住，一次只能一个进入一个线程
MyLock lock = new MyLock();
//t0, t1, t2在一起到这里
lock.lock();
xxxxx业务逻辑代码
lock.unlock();
退出
如果这个时候只有t0进来，那么其他两个锁怎么样？有人说阻塞，那就必定要唤醒，然后在通过时间片分配执行，一批线程都在阻塞，谁分到时间片谁就执行低，这种方式无疑不是一个好的解决办法，怎么办呢？想起前面的Synchronized有个自旋的办法，我让t1，t2进来后自旋，但是不可能一直在转圈，cpu也是要消耗的，怎么办呢，我做个判断行不行，如果获取了锁，那么就退出来：
//我设计一个锁，这个锁是用来让线程停住，一次只能一个进入一个线程
MyLock lock = new MyLock();
lock.lock();
while(true){
//t1 t2进来自旋
if(加锁成功){
break;
}
}
xxxxx业务逻辑代码
lock.unlock();
退出
可是这个时候如果来了100个线程呢？都在循环吗cpu要爆炸了？于是我想到了让出cpu的方法，Thread.yield()；如果不知道的可以去了解下这个方法。但是这样的话解决不了问题啊，这么多线程都在让cpu吗？是不是可以sleep（时间）；睡眠多久呢？是不是还得大概计算下每个线程执行下面的业务逻辑的时间？有的1s，有的10s，没法估计哇！！很明显也不行。那我是不是可以让线程阻塞住？java里有个方法叫做LockSupport.park()，线程一旦碰到这个方法后，立刻会被阻塞，不会再去使用cpu资源；
//我设计一个锁，这个锁是用来让线程停住，一次只能一个进入一个线程
MyLock lock = new MyLock();
lock.lock();
while(true){
//t1 t2进来自旋
if(加锁成功){
break;
}
LockSupport.park();
}
xxxxx业务逻辑代码
lock.unlock();
退出
问题我想了下又来了，这么多线程是阻塞了，一直躺这里吗，起码得有人唤醒你，在JVM里堆积的线程栈就会越来越多，总有一天会把你的内存干满的。所以有阻塞一定有唤醒，而unpark方法一定要传个参数，这个参数是线程的引用！
那要唤醒的话，那这个线程从哪里来呢？那我在park前起码要保存个线程的引用对吧，假设我做个队列来保存这些线程的引用；
//我设计一个锁，这个锁是用来让线程停住，一次只能一个进入一个线程
MyLock lock = new MyLock();
lock.lock();
while(true){
//t1 t2进来自旋
if(加锁成功){
break;
}
HashSet，LinkQueued()，ArrayList...等等
XXX.add|put(Thread);//塞进队列
LockSupport.park();
XXX.get|take();
LockSupport.unpark(XXX.get|take());
}
xxxxx业务逻辑代码
lock.unlock();
退出
那么唤醒在哪里唤醒？不可能在我上面的代码里去唤醒，又是阻塞又是唤醒，没有意义呀，所以我考虑放在unlock释放锁里面去唤醒线程。这样的话当T0执行到unlock的话，唤醒下一个线程，进入while中继续判断加锁逻辑：
//我设计一个锁，这个锁是用来让线程停住，一次只能一个进入一个线程
MyLock lock = new MyLock();
lock.lock();
while(true){
//t1 t2进来自旋
if(加锁成功){
break;
}
HashSet，LinkQueued()，ArrayList...等等
XXX.add|put(Thread);//塞进队列
LockSupport.park();
}
xxxxx业务逻辑代码
lock.unlock();
退出
unlock(){
//唤醒线程
XXX.get|take();
LockSupport.unpark(XXX.get|take());
}
大概思路这么玩，重点放在怎么实现互斥锁，边边角角先别理会！
所以这锁实现的几大核心：
- 自旋
- LockSupport
- CAS
- queue队列
这里冒出来个CAS，我们看上面代码if里这个加锁怎么保证100，1000个线程来加锁永远只有一个线程可以加到锁？这个时候我们大部分会想到Synchronized，所以if(Synchronied(Object o))这么写吗？我相信没人会这么写，毕竟Synchronized性能虽好，但是他本身是基于JVM封装去实现，非直接和硬件指定，cpu打交道，于是Java中给我们提供另一个加锁的东西，就是CAS
CAS：Compare And Swap是个原子操作，比较与交换，能够保证不管并发有多高我都可以保证你的原子性。
举个例子，如果在内存中有个变量叫做a=0，这么多线程怎么去修改他呢？
假设t1,t2来了，先把这值读到自己的内存去，此时两个线程中分别记录。
t1{ address = 0x1111，a = 0，refresh = 1}，t2{address = 0x1111，a = 0，refresh = 2}，这个refresh就是要修改的值，t1要修改成1，t2要修改成2，每个线程都存了这个a的地址引用。
此时如果t2要修改线程值从0改成2，改了后t1来了发现地址相同，看下a的值不一样啊，如果想修改，就必须要把a的值读回来，然后再去比较下，倘若这个时候还被改了，就一直这样下去，修改完后结束。这样每个线程都要干3个事情：执行读-修改-写操作；CAS 有效地说明了“我认为位置 address 应该包含值 a=xx；如果包含该值，则将refresh的值放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。当然CAS会产生ABA问题，这里先不多讨论。
在java中有个Unsafe类，你可以理解为这个是JVM给开的一个后门，之间可以和硬件打交道的，这个Unsafe中有这些方法：对象比较，Int比较，Long型比较
这个CAS其实底层调用的是汇编指令，cmpxchg()，也就是对应我们Unsafe这个实现类，调用的是c++库函数；
那么为什么要有个队列呢？回想下线程再多，也会存在优先级，引出两个概念：公平和非公平，啥是公平？就是正常的给我排队买饭去别插队，其他人都在阻塞着，cpu唤醒线程的开销就会很大，每次老板都要来喊人下一位！非公平是什么呢？就是你们去打饭，都伸着盘子找阿姨，如果阿姨不理你，那么就还是老老实实排在后面去，如果阿姨看你帅，给你打饭了，很幸运你被选中。而排在后面的还是一样按照先进先出的顺序来，那么优点就是减少唤醒的开销，这样就有可能导致中间排队的一直打不到饭....
说的标准点，公平锁是按照锁申请的顺序来获取锁，线程直接进入同步队列中排队，队列中的第一个线程才能获得到锁。非公平锁是线程申请锁时，直接尝试加锁，获取不到才会进入到同步队列排队。如果此时该线程刚好获取到了锁，那么它不需要因为队列中有其他线程在排队而阻塞，省去了CPU唤醒该线程的开销。而对于已经在同步队列中的线程，仍然是按照先进先出的公平规则获取锁。
其实剩下的就是不断的生产实践，优化细节，不断迭代后就成了现在的稳定版本的Lock锁！！正式进入主题
2、什么是AQS
Java并发编程核心在于java.concurrent.util包而juc当中的大多数同步器实现都是围绕着共同的基础行为，比如等待队列、条件队列、独占获取、共享获取等，而这个行为的抽象就是基于AbstractQueuedSynchronizer简称AQS，顾名思义叫做抽象的队列同步器，AQS定义了一套多线程访问共享资源的同步器框架，是一个依赖状态(state)的同步器。
我们看下源码的结构图：
看到很多Sync类，每个Sync类中都有两个子类，一个是公平，一个是非公平。
3、ReentrantLock
ReentrantLock是一种基于AQS框架的应用实现，是JDK中的一种线程并发访问的同步手段，它的功能类似于synchronized是一种互斥锁，可以保证线程安全。而且它具有比synchronized更多的特性，比如它支持手动加锁与解锁，支持加锁的公平性。
使用ReentrantLock进行同步
ReentrantLock lock = new ReentrantLock(false);//false为非公平锁，true为公平锁
lock.lock() //加锁
lock.unlock() //解锁那么，ReentrantLock如何实现Synchronized不具备的公平与非公平性呢？我们都知道Synchronized关键字实现的是非公平锁，也就是大家都来抢锁，抢不到的话，就老老实实去排队。
ReentrantLock内部定义了一个Sync的内部类，该类继承AbstractQueuedSynchronized，对该抽象类的部分方法做了实现；并且还定义了两个子类：
1、FairSync 公平锁的实现
2、NonfairSync 非公平锁的实现
这两个类都继承自Sync，也就是间接继承了AbstractQueuedSynchronized，所以这一个ReentrantLock同时具备公平与非公平特性。上面主要涉及的设计模式：模板模式-子类根据需要做具体业务实现。
AQS具备的特性：
- 阻塞等待队列：上面提到的Queue
- 共享/独占：后面说
- 公平/非公平
- 可重入：同一个线程可以反复多次获得锁，多次进行加锁释放锁
- 允许中断
既然说ReentrantLock是AQS的实现，那么我们看看这个是怎么实现的？
看下抽象父类AQS的定义，这个exclusiveOwnerThread，记录的是当前独占模式下，获取锁的线程是谁？
既然可以记录获取锁，那锁的状态，线程是否加上锁，通过什么来记录这个同步状态呢？实际上是state，这个被volatile修饰的变量。volatile可以保证可见性，其实就是让每个线程都知道这个state的值，好方便去得知锁的状态。
那么队列怎么实现的？实际上通过一个Node内部类，构成一个双向链表，其中Node中有几个重要的属性【prev前驱节点，next下一个节点，Thread的引用，为了要唤醒线程】，为什么要用双向链表呢？好处就是可以从前往后或者从后往前遍历。
具体来看Lock.lock()方法是怎么加锁的：
因为内部类有公平或者非公平，在new的时候其实已经默认为公平锁。
进去后里面有几个比较重要的方法，tryAcquire()、acquireQueued()、addWaiter()
tryAcquire()：尝试获取锁，AQS定义这个方法，实现是在子类Sync的公平锁。
protected final boolean tryAcquire(int acquires) {
//获取当前线程
final Thread current = Thread.currentThread();
//获取当前锁的状态，如果是0,表示没有加锁，可以加锁
int c = getState();
//加锁前要判断下是否有线程排队，因为默认用的公平锁，没人获取的话我还不能直接获取，因为公平锁要进行排队加锁
if (c == 0) {
//如果没有线程在队列里排队，取反就是true，继续判断cas去加锁，aqcuire值传的是1，即从0改成1，加锁成功后，把独占锁的线程引用指向当前线程。
//如果有线程在队列里，取反就是false，直接走下面的else
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}//如果获取锁的当前线程是自己，也就是自己再去获取锁
} else if (current == getExclusiveOwnerThread()) {
//则只要把state+1，这里和Synchronized重入性原理是一样的，这里else判断一定只能保证一个线程进来修改这个值，
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}acquireQueued()，跳出了tryAcquire，如果加锁不成功，取反就是true，就尝试去入队列
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
//创建一个节点
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}addWaiter(Node.EXCLUSIVE)：线程入队
private Node addWaiter(Node mode) {
//mode属性传的是独占，Exclusive，共享是shared
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;
}Node节点有几个比较重要的属性：【pre，next，waitState，thread指向】，其中重点要说下这个waitState，描述了节点的生命状态，可以称为信号量。这个waitState有几种状态：
-
SIGNAL：表示可被唤醒
-
CANCELLED：代表出现异常，中断引起需要废弃结束
-
CONDITION：条件等待
-
PROPAGATE：传播
-
0：初始状态Init
那么整个节点形成的队列是这样的：其中head和tail实际上是在AQS的，拿出来为了方便看整个的节点队列，那这个节点怎么生成的呢？我们往下看
AQS中的属性是这样的：
下面我们开始分析addWaiter这个方法的细节：
addWaiter(Node.EXCLUSIVE)：传入一个空的Node节点，很明显Node EXCLUSIVE = null;
在初始化的时候，创建第一个节点。
一开始的AQS，tail其实就是null，并没有地方给初始化值。
所以pred一定是空，if判断是不走的，看enq（node）；这个应该可以猜出来，enterQueue缩写的入队方法，这里for循环有点像在自旋，验证下对不对：
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}继续看逻辑，先定义一个Node节点指向tail，因为这个tail本身指向的就是null，把自己指向为null的赋值给这新的Node节点t，其实也是null；执行if（t == null）的判断；这里一定要注意compareAndSetHead这个方法，细心的同学点进去可以发现，这个实现的效果是，将AQS的head指针从null赋值给新new的Node节点！！这个操作，也是原子的，即使来了几个线程，也只能保证当前节点只有一个线程初始化队列成功。
李二狗为了防止空指针，以这样的方式来初始化一个AQS形成的队列！！将AQS的head节点和tail都指向一个new Node();
接下来再一次循环，很明显t指向new Node()不为空了，所以走到else判断，入队同样也存在线程的竞争，不然没法保证先进先出，compareAndSetTail()保证了入队的原子性，否则会出现else里面，尾部先指向某个节点了，然后这个时候别的线程过来也修改了这tail的引用，那么刚刚上一个的线程节点就不在队列里，永远是阻塞不会被唤醒，同样栈的空间永远会存在，如果是100个线程，很明显就泄露了。
这样就形成了节点双向链链表队列，如果依次下去，会形成非常多的节点，每个节点的线程引用都存在，方便后面唤醒线程。
这就很好理解为什么要用for 一直循环了，因为同一时刻CAS保证只有一个线程加锁成功，其他线程入队失败了，那么可以进行重试，也就是我们说的自旋，保证线程都不会被浪费掉。
既然enq方法走完了，返回的是当前的node节点，进入到acquireQueued(final Node node, args)这个方法里。
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
//如果p是头结点，并且可以获取到锁就出队
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}假设当前的队列状态是这样的（优化下图结构），那么进入acquireQueued方法后，有个for循环，为了防止上下文切换的开销，李二狗在队列中获取Node的第一个节点 node.predecessor(); 因为进入队列的线程不是立刻进行阻塞，阻塞前要尝试获取一次锁：
1、能获取到就出队；
2、不能获取到就阻塞住；
a) 首先第一轮循环，修改head的状态，修改成Signal标记可以被唤醒。
b) 第二轮循环，阻塞线程parkAndCheckInterrupt()，判断线程是否可中断。
if (p == head && tryAcquire(arg)) //如果p是头结点，并且可以获取到锁就出队；很明显图中已经表明了setHead()要做的事情，原先的头结点就已经没有了引用，后面会被gc回收掉，然后直接return掉。
当下一轮for进来，走到现在的头结点的时候，要判断shouldParkAfterFailedAcquire(前驱结点，当前结点)，实际上这个方法内部就是对状态进行的判断：实际上node结点是头结点的下一个结点，所于是要判断node的前驱结点，根据waitStatus状态位是什么，再选择是否出队。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
// 先拿到当前结点的前驱结点，如果这个状态是Signal，则表示可以被唤醒
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
//如果是其他状态
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}假设waitStatus的状态是Init=0，那么就走到下面的else，shouldParkAfterFailedAcquire()，把前驱结点head的状态从0改成Signal = -1表示可以被唤醒（要想唤醒排队的第一个线程T1，持有锁的线程T0在释放锁的时候，需要判断T0结点的waitStatus是否!=0，如果!=0成立，会再把waitStatus从-1改成0；从而T1再被唤醒去抢锁，在非公平状态下可能会再失败，此时可能T3持有了锁。）。实际上前驱结点是为了后面结点服务的。这里可能文字讲的不是很清楚，读者多读几次代码就知道了，这里是很有难度的，也是并发里的精髓。
剩下的边边角角我这里就不多说了，整体下来，李二狗写的代码可读性我觉得是比较不好的，和Spring相比还是有点生涩，但是思路我们要get到，毕竟面试喜欢聊这些。
242
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
