【并发的艺术】--同步锁-ReentrantLock底层实现原理
同步锁
锁是控制多个线程访问共享资源的方式，一个锁防止多个线程同时访问共享资源。
Lock接口出现之前，java程序只能依靠synchronized关键字来实现同步锁。在java5以后增加的JUC的并发包并且提供了lock接口用来实现锁的功能。提供与synchronized类似的功能，比synchronized更灵活，显示的获取和释放锁。
Lock锁的初步使用
Lock是一个接口，核心的两个方法lock和unlock，有很多的实现：ReentrantLock、ReentrantReadWriteLock；
ReentrantLock
重入锁，当前线程通过调用lock方法获取了锁之后，再次调用lock是不会再阻塞去获取锁的，直接增加重试次数就行了。
public class AtomicDemo {
private static int count=0;
static Lock lock=new ReentrantLock();
public static void inc(){
lock.lock();
try {
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
count++;
lock.unlock();
}
public static void main(String[] args) throws InterruptedException {
for(int i=0;i<1000;i++){
new Thread(()->{AtomicDemo.inc();}).start();;
}
Thread.sleep(3000);
System.out.println("result:"+count);
}
}
Lock和synchronized简单对比
1、直观的差异，一个是关键字，一个是类。
2、使用上，lock具备更大的灵活性，可以控制锁的释放和获取; 而synchronized的锁的释放是被动的，当出现 异常或者同步代码块执行完以后，才会释放锁。
3、lock可以判断锁的状态、而synchronized无法做到。
4、lock可以实现公平锁、非公平锁; 而synchronized只有非公平锁。
ReentrantLock的实现原理源码分析
独占锁
重入锁，分公平和不公平两种。
非公平锁实现的流程时序图：
源码
---获取锁--start---
ReentrantLock.lock
public void lock() {
sync.lock();
}这个是获取锁的入口，调用了sync.lock; sync是一个实现了AQS的抽象类，这个类的主要作用是用来实现同步控制的，并且sync有两个实现，一个是NonfairSync(非公平锁)、另一个是FailSync(公平锁); 我们先来分析一下非公 平锁的实现。
NonfairSync.lock
final void lock() {
if (compareAndSetState(0, 1)) //这是跟公平锁的主要区别,一上来就试探锁是否空闲,如果可以插队，则设置获得锁的线程为当前线程。
//exclusiveOwnerThread属性是AQS从父类AbstractOwnableSynchronizer中继承的属性，用来保存当前占用 同步状态的线程
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1); //尝试去获取锁
}通过cas算法去改变state的值，而这个state是什么呢? 在AQS中存在一个变量state，对于ReentrantLock来说，如果state=0表示无锁状态、如果state>0表示 有锁状态。
AbstractQueuedSynchronizer.acquire
如果CAS操作未能成功，说明state已经不为0，此时继续acquire(1)操作,acquire是AQS中的方法 当多个线程同时进 入这个方法时，首先通过cas去修改state的状态，如果修改成功表示竞争锁成功，竞争失败的，tryAcquire会返回false.
public final void acquire(int arg) {
if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
/*
这个方法的主要作用是
Ø 尝试获取独占锁，获取成功则返回，否则
Ø 自旋获取锁，并且判断中断标识，如果中断标识为true，则设置线程中断
Ø addWaiter方法把当前线程封装成Node，并添加到队列的尾部*/NonfairSync.tryAcquire
tryAcquire方法尝试获取锁，如果成功就返回，如果不成功，则把当前线程和等待状态信息构适成一个Node节点，并将结点放入同步队列的尾部。然后为同步队列中的当前节点循环等待获取锁，直到成功.
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}Sync.nofairTryAcquire
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState(); //获取当前的状态，前面讲过，默认情况下是0表示无锁状态
if (c == 0) {
if (compareAndSetState(0, acquires)) { //通过cas来改变state状态的值，如果更新成功，表 示获取锁成功, 这个操作外部方法lock()就做过一次，这里再做只是为了再尝试一次，尽量以最简单的方式获取锁。
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {//如果当前线程等于获取锁的线程，表示重入， 直接累加重入次数
int nextc = c + acquires;
if (nextc < 0) // overflow 如果这个状态值越界，抛出异常;如果没有越界，则设置后返回true
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
如果状态不为0，且当前线程不是owner，则返回false。
return false; //获取锁失败，返回false
}AQS.addWaiter
当前锁如果已经被其他线程锁持有，那么当前线程来去请求锁的时候，会进入这个方法,这个方法主要是把当前线程 封装成node，添加到AQS的链表中。
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode); //创建一个独占的Node节点,mode为排他模式
// 尝试快速入队,如果失败则降级至full enq
Node pred = tail; // tail是AQS的中表示同步队列队尾的属性，刚开始为null，所以进行enq(node)方
法
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) { // 防止有其他线程修改tail,使用CAS进行修改,如果失 败则降级至full enq
pred.next = node; // 如果成功之后旧的tail的next指针再指向新的tail,成为双向链表
return node;
}
}
enq(node); // 如果队列为null或者CAS设置新的tail失败
return node;
}enq
enq就是通过自旋操作把当前节点加入到队列中。
private Node enq(final Node node) {
for (;;) { //无效的循环，为什么采用for(;;)，是因为它执行的指令少，不占用寄存器
Node t = tail;// 此时head, tail都为null
if (t == null) { // Must initialize// 如果tail为null则说明队列首次使用,需要进行初始化
if (compareAndSetHead(new Node()))// 设置头节点,如果失败则存在竞争,留至下一轮循环 tail = head; // 用CAS的方式创建一个空的Node作为头结点，因为此时队列中只一个头结
点，所以tail也指向head，第一次循环执行结束
} else {
//进行第二次循环时，tail不为null，进入else区域。将当前线程的Node结点的prev指向tail，然后使用CAS将 tail指向Node
//这部分代码和addWaiter代码一样，将当前节点添加到队列
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node; //t此时指向tail,所以可以CAS成功，将tail重新指向CNode。此时t为更 新前的tail的值，即指向空的头结点，t.next=node，就将头结点的后续结点指向Node，返回头结点
return t;
}
}
}
}代码运行到这里，aqs队列的结构就是这样一个表现。
acquireQueued
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();// 获取prev节点,若为null即刻抛出 NullPointException
if (p == head && tryAcquire(arg)) {// 如果前驱为head才有资格进行锁的抢夺
setHead(node); // 获取锁成功后就不需要再进行同步操作了,获取锁成功的线程作为新的head节点
//凡是head节点,head.thread与head.prev永远为null, 但是head.next不为null
p.next = null; // help GC
failed = false; //获取锁成功
return interrupted;
}
//如果获取锁失败，则根据节点的waitStatus决定是否需要挂起线程
if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())// 若前面为true,则执行挂起,待下次唤醒的时候检测中断的标志
interrupted = true;
}
} finally {
if (failed) // 如果抛出异常则取消锁的获取,进行出队(sync queue)操作
cancelAcquire(node);
}
}原来的head节点释放锁以后，会从队列中移除，原来head节点的next节点会成为head节点。
shouldParkAfterFailedAcquire
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { int ws = pred.waitStatus; //前继节点的状态
if (ws == Node.SIGNAL)//如果是SIGNAL状态，意味着当前线程需要被unpark唤醒
return true; 如果前节点的状态大于0，即为CANCELLED状态时，则会从前节点开始逐步循环找到一个没有被“CANCELLED”节点设置 为当前节点的前节点，返回false。在下次循环执行shouldParkAfterFailedAcquire时，返回true。这个操作实 际是把队列中CANCELLED的节点剔除掉。
if (ws > 0) {// 如果前继节点是“取消”状态，则设置 “当前节点”的 “当前前继节点” 为 “‘原前继节 点'的前继节点”。
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else { // 如果前继节点为“0”或者“共享锁”状态，则设置前继节点为SIGNAL状态。
/*
* 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;
}解读:假如有t1,t2两个线程都加入到了链表中img
如果head节点位置的线程一直持有锁，那么t1和t2就是挂起状态，而HEAD以及Thread1的的awaitStatus都是SIGNAL，在多次尝试获取锁失败以后，就会通过下面的方法进行挂起(这个地方就是避免了惊群效应，每个节点 只需要关心上一个节点的状态即可)
imgSIGNAL:值为-1，表示当前节点的的后继节点将要或者已经被阻塞，在当前节点释放的时候需要unpark后继节
点;CONDITION:值为-2，表示当前节点在等待condition，即在condition队列中;PROPAGATE:值为-3，表示releaseShared需要被传播给后续节点(仅在共享模式下使用);
parkAndCheckInterrupt
如果shouldParkAfterFailedAcquire返回了true，则会执行:“parkAndCheckInterrupt()”方法，它是通过LockSupport.park(this)将当前线程挂起到WATING状态，它需要等待一个中断、unpark方法来唤醒它，通过这样一种FIFO的机制的等待，来实现了Lock的操作
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);// LockSupport提供park()和unpark()方法实现阻塞线程和解除线程阻塞
return Thread.interrupted();
}---获取锁--end---
---释放锁--start---
ReentrantLock.unlock
加锁的过程分析完以后，再来分析一下释放锁的过程，调用release方法，这个方法里面做两件事，
1，释放锁 ;
2，唤醒park的线程.
public final boolean release(int arg) {
if (tryRelease(arg)) {//释放锁
Node h = head;//AQS同步队列头节点
if (h != null && h.waitStatus != 0)
//唤醒节点中的线程
unparkSuccessor(h);
return true;
}
return false;
}tryRelease
这是设置锁状态的操作，将状态减掉传入的参数值(参数是1)，如果结果状态为0， 就将排它锁的Owner设置为null，以使得其它的线程有机会进行执行。 在排它锁中，加锁的时候状态会增加1(当 然可以自己修改这个值)，在解锁的时候减掉1，同一个锁，在可以重入后，可能会被叠加为2、3、4这些值，只有unlock()的次数与lock()的次数对应才会将Owner线程设置为空，而且也只有这种情况下才会返回true。
protected final boolean tryRelease(int releases) {
int c = getState() - releases; // 这里是将锁的数量减1
if (Thread.currentThread() != getExclusiveOwnerThread())// 如果释放的线程和获取锁的线程 不是同一个，抛出非法监视器状态异常
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
// 由于重入的关系，不是每次释放锁c都等于0，
// 直到最后一次释放锁时，才会把当前线程释放
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}private void unparkSuccessor(Node node) {
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
//唤醒阻塞线程
LockSupport.unpark(s.thread);
}LockSupport
public native void unpark(Thread jthread);
public native void park(boolean isAbsolute, long time);unpark函数为线程提供“许可(permit)”，线程调用park函数则等待“许可”。这个有点像信号量，但是这个“许可”是不 能叠加的，“许可”是一次性的。
permit相当于0/1的开关，默认是0，调用一次unpark就加1变成了1.调用一次park会消费permit，又会变成0。 如 果再调用一次park会阻塞，因为permit已经是0了。直到permit变成1.这时调用unpark会把permit设置为1.每个线 程都有一个相关的permit，permit最多只有一个，重复调用unpark不会累积
在使用LockSupport之前，我们对线程做同步，只能使用wait和notify，但是wait和notify其实不是很灵活，并且耦 合性很高，调用notify必须要确保某个线程处于wait状态，而park/unpark模型真正解耦了线程之间的同步，先后 顺序没有直接关联，同时线程之间不再需要一个Object或者其它变量来存储状态，不再需要关心对方的状态。
---释放锁--end---
公平锁和非公平锁的区别
非公平锁在获取锁的时候，会先通过CAS进行抢占，而公平锁则不会。
FairSync.tryAcquire
final void** lock() {
acquire(1);
}FairSync.tryAcquire
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;
}这个方法与nonfairTryAcquire(int acquires)比较，不同的地方在于判断条件多了hasQueuedPredecessors()方 法，也就是加入了[同步队列中当前节点是否有前驱节点]的判断，如果该方法返回true，则表示有线程比当前线程 更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁。