文中表格出处https://www.cnblogs.com/xrq730/p/4979021.html
文中图片出处https://blog.csdn.net/luonanqin/article/details/41871909
对于java中实现并发加锁的方式可以分为两种，一种是重量级的synchronized，一种是concurrent包下的lock接口。本系列文章将对这两种锁和依赖于cpu嗅探技术的volatile进行详细说明。
在Lock接口出现前，Java程序是靠synchronized的关键字实现锁功能的，而Java SE 5 之后，并发包中新增了Lock接口及其相关实现类用来实现锁功能，它提供了与synchronized关键字类似的同步功能，知识在使用时需要显示的获取和释放锁。虽然它缺少了隐式获取释放锁的便捷性，但是拥有了锁获取与释放的可操作性，可中断的获取锁以及超时获取锁等synchronized关键字所不具备的同步特性。
使用范例:这里使用的是lock的实现类Reentrantlock
private static Lock lock = new ReentrantLock();
public static void critical() {
lock.lock();
try {
System.out.println("start " + Thread.currentThread().getName());
Thread.sleep(1000);
System.out.println("end " + Thread.currentThread().getName());
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}注意：不能在try块中进行lock，如果代码发生异常，会导致锁的无故释放
在介绍Reentrantlock前首先需要介绍一下AbstractQueuedSynchronizer，下面简称AQS。它是一个非常重要的同步队列，concurrent包下许多工具都用到了这个队列同步器，比如著名的CountDownLatch。通过查看源码可以发现，AQS在内部实现了一个链式FIFO的双向队列，拥有Head和Tail指针，并且实现了setHead(),setTail()等队列方法。既然是队列，那势必有结点，AQS就是通过对一个个结点的管理实现同步作用的，当当前线程获取锁失败的时候，AQS将当前线程的状态包装为一个结点，放入内部的queue中并阻塞当前线程。当可以再次获取锁的时候，AQS将首结点对应的线程唤醒并再次尝试获取锁。
下面用一张表说明结点内的属性。
| 属 性 | 定 义 |
| Node SHARED = new Node() | 表示Node处于共享模式 |
| Node EXCLUSIVE = null | 表示Node处于独占模式 |
| int CANCELLED = 1 | 因为超时或者中断，Node被设置为取消状态，被取消的Node不应该去竞争锁，只能保持取消状态不变，不能转换为其他状态，处于这种状态的Node会被踢出队列，被GC回收 |
| int SIGNAL = -1 | 表示这个Node的继任Node被阻塞了，到时需要通知它 |
| int CONDITION = -2 | 表示这个Node在条件队列中，因为等待某个条件而被阻塞 |
| int PROPAGATE = -3 | 使用在共享模式头Node有可能处于这种状态， 表示锁的下一次获取可以无条件传播 |
| int waitStatus | 0，新Node会处于这种状态 |
| Node prev | 队列中某个Node的前驱Node |
| Node next | 队列中某个Node的后继Node |
| Thread thread | 这个Node持有的线程，表示等待锁的线程 |
| Node nextWaiter | 表示下一个等待condition的Node |
再用一张表说明AQS的属性和方法
| 属性/方法 | 含 义 |
| Thread exclusiveOwnerThread | 这个是AQS父类AbstractOwnableSynchronizer的属性，表示独占模式同步器的当前拥有者 |
| Node | 上面已经介绍过了，FIFO队列的基本单位 |
| Node head | FIFO队列中的头Node |
| Node tail | FIFO队列中的尾Node |
| int state | 同步状态，0表示未锁 |
| int getState() | 获取同步状态 |
| setState(int newState) | 设置同步状态 |
| boolean compareAndSetState(int expect, int update) | 利用CAS进行State的设置 |
| long spinForTimeoutThreshold = 1000L | 线程自旋等待的时间 |
| Node enq(final Node node) | 插入一个Node到FIFO队列中 |
| Node addWaiter(Node mode) | 为当前线程和指定模式创建并扩充一个等待队列 |
| void setHead(Node node) | 设置队列的头Node |
| void unparkSuccessor(Node node) | 如果存在的话，唤起Node持有的线程 |
| void doReleaseShared() | 共享模式下做释放锁的动作 |
| void cancelAcquire(Node node) | 取消正在进行的Node获取锁的尝试 |
| boolean shouldParkAfterFailedAcquire(Node pred, Node node) | 在尝试获取锁失败后是否应该禁用当前线程并等待 |
| void selfInterrupt() | 中断当前线程本身 |
| boolean parkAndCheckInterrupt() | 禁用当前线程进入等待状态并中断线程本身 |
| boolean acquireQueued(final Node node, int arg) | 队列中的线程获取锁 |
| tryAcquire(int arg) | 尝试获得锁（由AQS的子类实现它） |
| tryRelease(int arg) | 尝试释放锁（由AQS的子类实现它） |
| isHeldExclusively() | 是否独自持有锁 |
| acquire(int arg) | 获取锁 |
| release(int arg) | 释放锁 |
| compareAndSetHead(Node update) | 利用CAS设置头Node |
| compareAndSetTail(Node expect, Node update) | 利用CAS设置尾Node |
| compareAndSetWaitStatus(Node node, int expect, int update) | 利用CAS设置某个Node中的等待状态 |
上表中有很多的CAS操作，这里解释一下CAS，全称为CompareAndSwap，即比较并交换。顾名思义，当需要更新值的时候，先用当前值和旧值进行比较，如果相同则更新，不同则返回一个错误码。它是concurrent存在的基础，CAS的实现并不是通过代码，而是通过CPU对其的支持，不同的CPU对CAS的实现方式不同，但是最后的效果是相同的，当需要触发CAS的时候，通过调用Java的Unsafe类对硬件级别进行操作，从而实现比较并交换这一操作，Unsafe类是Java自己留的后门，从而实现不依赖native方法就可以实现硬件级别的原子操作。
Reentrantlock中的锁分为两种，公平锁和非公平锁，通过new Reentrantlock(true)可以获得公平锁，默认是非公平锁。对于公平锁，每次有线程到达时，都会先通过hasQueuedPredecessors()方法查看等待队列是否为空，不为空则加入等待队列。而非公平锁则不然，可以通过查看下面我的源码分析看出，非公平锁回多次尝试对锁的所有权进行抢占，全部失败之后，才会按公平锁的方式完全加入等待队列。至于为什么要用非公平锁，自然是因为它快啊，这一点在源码的注释中也写了。一个形象的比喻就是打官司是私了肯定比上法庭快，免去了线程挂起的时候进行线程切换的时间。
Reentrantlock是一种可重入锁，也就是一个线程可以获取锁多次。操作系统在切换线程的时候，是需要保存并切换上下文的，这也就是为什么在单核的cpu上进行多线程操作时反而更加费时的原因。在可重入锁中当前线程可以直接进行重入，这样就不会存在上下文切换的时间，从而提高了效率。下文介绍的lock和unlock都是针对非公平锁的。
1.lock
首先，我们假设线程1先占有了锁，这个过程是非常简单的
(1)首先，调用
private final Sync sync;
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}实例化出一个非公平锁，其中Sync是一个继承了AQS的类。
(2)调用sync的lock方法
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}(3)调用AQS的compareAndSetState方法，将state属性设为1，表示线程1独占锁
protected final boolean compareAndSetState(int expect, int update) {
// See below for intrinsics setup to support this
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}(4)调用AQS父类AOS的setExclusiveOwnerThread方法将占有锁的线程设为当前线程
protected final void setExclusiveOwnerThread(Thread thread) {
exclusiveOwnerThread = thread;
}此时线程1成功占有锁，此时AQS中的state=1，exclusiveOwnerThread = thread1
线程1占有锁之后，线程2到来，由于是非公平锁，线程2从到来直到加入队列的过程中，它会多次尝试抢占锁，如果均不成功，最后会阻塞并被加入到AQS的等待队列中，下图是调用链。
(1)调用lock()方法
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}在调用lock时，首先会尝试使用CAS判断state是不是0，如果是0就设为1。这里是非公平的一个体现，新到线程可以去抢占队首节点的锁的所有权。但是现在这里是失败的，因为线程1已经把state设置成了1。所以跳到第二步
(2)调用AQS的acquire方法
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}可以看到这个if语句，之前说过，非公平锁从开始到放入等待队列结束期间，会多次尝试获得锁，这里的tryAcquire()就是尝试获得锁，非公平锁中它最后会走nonfairTryAcquire方法
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
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;
}首先获取到当前线程，获取当前占有锁的线程数，如果state等于0说明锁没有被占用。此时尝试用CAS将state设置为1，如果失败，再判断占有锁的是不是当前线程。如果是，走else if里的代码，则开始重入，这里是对锁的重入次数做了一个限制，我们知道，整型的数如果超过范围会溢出为负数，所以当锁被当前线程重入时，每次都会对state加一，如果state变成负数，那么说明重入次数已经超过2147483647次，此时抛出异常。很简单的就实现了一个偏向锁。
如果acquire失败，走第二个条件尝试将当前线程加入等待队列中。首先走addWaiter方法将当前线程的信息包装成node并加入队尾
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;
}首先先创建一个节点，因为是独占锁，所以实际上传进来的mode是个NULL，此时new Node会创建一个独占模式的节点。此时先获取一下尾节点，如果尾节点都是null那么说明这个队列就是空，此时走enq方法新建一个队列。如果存在，用CAS把它设为队列的头节点，用CAS的原因是cpu时间片是切换的，可能有其他线程把队列已经创建好了，此时CAS失败，由于tail是volatile的，所以对当前线程可见，此时看见tail不为null再次循环后将会将当前节点放到队尾。
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;
}
}
}
}在enq中这里用了一个for的死循环保证队列是一定新建成功的，它会先再次判断一下队列是不是不存在，然后新建头节点，然后把当前节点连在头节点后面。并将当前节点设为尾节点。这里其实是这样的,
到这里算是把一个就绪的节点放入AQS的等待队列中了，开始走acquireQueued(addWaiter(Node.EXCLUSIVE), arg))最外层的acquireQueued方法。这个方法主要是对新加入等待队列的线程进行阻塞。
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);
}
}这里第一个if语句是对当前节点能否获得锁进行判断，因为此时可能锁已经被释放。如果当前节点是队列中的第一个节点而且能够获得锁，那么就把当前节点设置为头节点。如果还是不能获取锁，那么需要对这条线程进行阻塞。但因为并不是所有线程都需要阻塞，比如取消状态。这里开始走shouldParkAfterFailedAcquire(p, node)方法判断是否需要阻塞。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
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;
}因为是多线程环境，当前节点的位置是有可能变得，所以这里需要再判断一下status，这里根据status设定三个规则
规则1：如果前继的节点状态为SIGNAL，表明当前节点需要unpark，则返回成功，此时acquireQueued方法的第12行（parkAndCheckInterrupt）将导致线程阻塞
规则2：如果前继节点状态为CANCELLED(ws>0)，说明前置节点已经被放弃，则回溯到一个非取消的前继节点，返回false，acquireQueued方法的无限循环将递归调用该方法，直至规则1返回true，导致线程阻塞
规则3：如果前继节点状态为非SIGNAL、非CANCELLED，则设置前继的状态为SIGNAL，返回false后进入acquireQueued的无限循环，与规则2同
这里如果返回true，说明线程需要被阻塞，那么通过parkAndCheckInterrupt调用native方法进行阻塞。
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
public static void park(Object blocker) {
Thread t = Thread.currentThread();
setBlocker(t, blocker);
UNSAFE.park(false, 0L);
setBlocker(t, null);
}如果在acquireQueued方法中出现了异常，此时failed值为true，会走finally块中的cancelAcquire方法把当前节点设为CANCELLED状态
private void cancelAcquire(Node node) {
// Ignore if node doesn't exist
if (node == null)
return;
node.thread = null;
Node pred = node.prev;
while (pred.waitStatus > 0)
node.prev = pred = pred.prev;
Node predNext = pred.next;
node.waitStatus = Node.CANCELLED;
if (node == tail && compareAndSetTail(node, pred)) {
compareAndSetNext(pred, predNext, null);
} else {
int ws;
if (pred != head &&
((ws = pred.waitStatus) == Node.SIGNAL ||
(ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
pred.thread != null) {
Node next = node.next;
if (next != null && next.waitStatus <= 0)
compareAndSetNext(pred, predNext, next);
} else {
unparkSuccessor(node);
}
node.next = node; // help GC
}
}在cancelAcquire方法中，首先将node.thread设为null，表示此节点不关联任何线程。然后通过while找到当前节点前面第一个不是CANCELLED状态的节点，并且将当前节点的status设置为CANCELLED。因为头节点一定不是CANCELLED状态，所以这里是一定能够找到的，新增一个predNext便于下面CAS操作。然后接下来分三种情况
规则1：如果当前节点是尾节点，那么将当前节点的前一个节点为尾节点，并将其next设为null，注意这里并没有设置pre为null，后面unlock的时候会用到。
规则2：如果当前节点不是尾节点也不是头节点的后继节点，那么判断其前驱节点的status是不是SIGNAL，如果不是那么尝试将其设为SIGNAL。这两个条件满足一个之后继续判断前驱节点是否与线程关联，如果这些都满足，那么将当前节点的前驱节点和当前节点的后继节点相连，相当于将当前节点从队列删除。
规则3：如果当前节点是头节点的后继节点，那么调用unparkSuccessor唤醒当前节点的后继节点。
最后把next指向自身，减少引用达到help GC的目的。
这里用一张网上的图总结一下lock的流程
至此，lock过程结束。接下来看unlock方法，首先肯定是调用unlock方法，我们可以看到unlock里调用release方法
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;
}这里先走外层的if语句，这里进入tryRelease方法，arg = 1
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;
}首先获取计算锁释放之后的state值，用于后续是否释放成功的判断。这里会先对要释放的锁的线程是不是当前线程做判断，如果不是直接抛出异常。如果是当前线程，再看刚才计算的state是不是0。因为有重入锁的概念，每次拥有锁state会加一，释放锁会减一。这里如果state为0说明当前线程将锁完全释放，此时可以用setExclusiveOwnerThread把当前锁的拥有者设为null。如果不是0那就把state设置为state-1。
此时进入release的if方法体内，这里对头节点的状态进行了判断，由于之前对waitStatus的设置，现在队列里除了最后一个节点之外应该所有节点的waitStatus都是SIGNAL也就是-1。所以走unparkSuccessor方法。
private void unparkSuccessor(Node node) {
/*
* If status is negative (i.e., possibly needing signal) try
* to clear in anticipation of signalling. It is OK if this
* fails or if status is changed by waiting thread.
*/
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
/*
* Thread to unpark is held in successor, which is normally
* just the next node. But if cancelled or apparently null,
* traverse backwards from tail to find the actual
* non-cancelled successor.
*/
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);
}在unparkSuccessor方法里首先会获取node的waitStatus，首先会把当前节点的值waitStatus设为0，也就是新节点，前提当前节点的waitStatus是SIGNAL。然后获取当前节点的后继节点，这里还是要判断一下是否为空和是否为CANCELLED。如果是的话，它会从队尾到队首向前遍历，直到找到最靠近头节点的那个可以被唤醒的节点，然后把它赋值给s。这里有个为什么是从后往前找的问题，这样做有两个原因
1.我们可以回忆一下之前往队列里加node时候自旋操作的代码。
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;
}
}
}
}我们可以看到这里用CAS设置了头节点，这是可以保证线程安全的，但是在CAS操作和t.next = node这一步之间，如果有别的线程进行释放锁，这时候next还没设置完，从前往后遍历是无法访问到最后一个节点的。
2.之所以要遍历队列就是因为出现了CANCELLED状态的节点，在之前调用cancelAcquire方法将节点设为CANCELLED状态时，最后为了help GC将node.next指向了自己，这时候从前往后遍历，势必会造成死循环。
第一个if方法走完之后，调用LockSupport.unpark方法，这个方法通过调用native方法唤醒后面的线程。至此unlock结束。
扫一扫
731
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
