“道冲，而用之或不盈。
渊兮，似万物之宗。
挫其锐，解其纷，和其光，同其尘。
湛兮，似或存，吾不知其谁之子，象帝之先。”^ddj
###可重入
若一个程序或子程序可以“安全的被并行执行(Parallel computing)”，则称其为可重入（reentrant或re-entrant）的。即当该子程序正在运行时，可以再次进入并执行它（并行执行时，个别的执行结果，都符合设计时的预期）。可重入概念是在单线程操作系统的时代提出的。
ReentrantLock默认情况下为不公平锁
1 | private ReentrantLock lock = new ReentrantLock();//公平锁 |
2 | private ReentrantLock lock = new ReentrantLock(true);//不公平锁 |
不公平锁与公平锁的区别：
公平情况下，操作会排一个队按顺序执行，来保证执行顺序。（会消耗更多的时间来排队）
不公平情况下，是无序状态允许插队，jvm会自动计算如何处理更快速来调度插队。（如果不关心顺序，这个速度会更快）
使用场景
ReentrantLock的使用场景，通常有如下几个：
- 发现该操作已经在执行中则不再执行（有状态执行）
1private ReentrantLock lock = new ReentrantLock();//公平锁2...3if(lock.tryLock()){//如果已经被锁，则会立即返回false不会等待，忽略锁住的业务操作执行4try{5////业务操作6}finally{7lock.unlock();8}9}10... - 如果发现该操作已经在执行，等待一个一个执行（同步执行，类似synchronized）
- 如果发现该操作已经在执行，则尝试等待一段时间，等待超时则不执行（尝试等待执行）
1private ReentrantLock lock = new ReentrantLock();//公平锁2...3if(lock.tryLock(5,TimeUnit.SECONDS)){//尝试等待5秒4try{5////业务操作6}finally{7lock.unlock();8}9} - 如果发现该操作已经在执行，等待执行。这时可中断正在进行的操作立刻释放锁继续下一操作
synchronized与Lock在默认情况下是不会响应中断(interrupt)操作，会继续执行完。lockInterruptibly()提供了可中断锁来解决此问题。（场景2的另一种改进，没有超时，只能等待中断或执行完毕）
这种情况主要用于取消某些操作对资源的占用
源码分析
1 | /** 同步器：内部类Sync的一个引用 */ |
2 | private final Sync sync; |
3 | |
4 | /** |
5 | * 创建一个非公平锁 |
6 | */ |
7 | public ReentrantLock() { |
8 | sync = new NonfairSync(); |
9 | } |
10 | |
11 | /** |
12 | * 创建一个锁 |
13 | * @param fair true-->公平锁 false-->非公平锁 |
14 | */ |
15 | public ReentrantLock(boolean fair) { |
16 | sync = (fair)? new FairSync() : new NonfairSync(); |
17 | } |
三个内部类Sync/NonfairSync/FairSync
1 | /** |
2 | * 该锁同步控制的一个基类.下边有两个子类：非公平机制和公平机制.使用了AbstractQueuedSynchronizer类的 |
3 | */ |
4 | static abstract class Sync extends AbstractQueuedSynchronizer |
5 | |
6 | /** |
7 | * 非公平锁同步器 |
8 | */ |
9 | final static class NonfairSync extends Sync |
10 | |
11 | /** |
12 | * 公平锁同步器 |
13 | */ |
14 | final static class FairSync extends Sync |
ReentrantLock：lock()
1 | /** |
2 | *获取一个锁 |
3 | *三种情况： |
4 | *1、如果当下这个锁没有被任何线程（包括当前线程）持有，则立即获取锁，锁数量==1，之后再执行相应的业务逻辑 |
5 | *2、如果当前线程正在持有这个锁，那么锁数量+1，之后再执行相应的业务逻辑 |
6 | *3、如果当下锁被另一个线程所持有，则当前线程处于休眠状态，直到获得锁之后，当前线程被唤醒，锁数量==1，再执行相应的业务逻辑 |
7 | */ |
8 | public void lock() { |
9 | sync.lock();//调用NonfairSync（非公平锁）或FairSync（公平锁）的lock()方法 |
10 | } |
NonfairSync：lock()
1 | /** |
2 | * 1）首先基于CAS将state（锁数量）从0设置为1，如果设置成功，设置当前线程为独占锁的线程；-->请求成功-->第一次插队 |
3 | * 2）如果设置失败(即当前的锁数量可能已经为1了，即在尝试的过程中，已经被其他线程先一步占有了锁)，这个时候当前线程执行acquire(1)方法 |
4 | * 2.1）acquire(1)方法首先调用下边的tryAcquire(1)方法，在该方法中，首先获取锁数量状态， |
5 | * 2.1.1）如果为0(证明该独占锁已被释放，当下没有线程在使用)，这个时候我们继续使用CAS将state（锁数量）从0设置为1，如果设置成功，当前线程独占锁；-->请求成功-->第二次插队；当然，如果设置不成功，直接返回false |
6 | * 2.2.2）如果不为0，就去判断当前的线程是不是就是当下独占锁的线程，如果是，就将当前的锁数量状态值+1（这也就是可重入锁的名称的来源）-->请求成功 |
7 | * |
8 | * 下边的流程一句话：请求失败后，将当前线程链入队尾并挂起，之后等待被唤醒。 |
9 | * |
10 | * 2.2.3）如果最后在tryAcquire(1)方法中上述的执行都没成功，即请求没有成功，则返回false，继续执行acquireQueued(addWaiter(Node.EXCLUSIVE), arg)方法 |
11 | * 2.2）在上述方法中，首先会使用addWaiter(Node.EXCLUSIVE)将当前线程封装进Node节点node，然后将该节点加入等待队列（先快速入队，如果快速入队不成功，其使用正常入队方法无限循环一直到Node节点入队为止） |
12 | * 2.2.1）快速入队：如果同步等待队列存在尾节点，将使用CAS尝试将尾节点设置为node，并将之前的尾节点插入到node之前 |
13 | * 2.2.2）正常入队：如果同步等待队列不存在尾节点或者上述CAS尝试不成功的话，就执行正常入队（该方法是一个无限循环的过程，即直到入队为止）-->第一次阻塞 |
14 | * 2.2.2.1）如果尾节点为空（初始化同步等待队列），创建一个dummy节点，并将该节点通过CAS尝试设置到头节点上去，设置成功的话，将尾节点也指向该dummy节点（即头节点和尾节点都指向该dummy节点） |
15 | * 2.2.2.1）如果尾节点不为空，执行与快速入队相同的逻辑，即使用CAS尝试将尾节点设置为node，并将之前的尾节点插入到node之前 |
16 | * 最后，如果顺利入队的话，就返回入队的节点node，如果不顺利的话，无限循环去执行2.2)下边的流程，直到入队为止 |
17 | * 2.3）node节点入队之后，就去执行acquireQueued(final Node node, int arg)（这又是一个无限循环的过程，这里需要注意的是，无限循环等于阻塞，多个线程可以同时无限循环--每个线程都可以执行自己的循环，这样才能使在后边排队的节点不断前进） |
18 | * 2.3.1）获取node的前驱节点p，如果p是头节点，就继续使用tryAcquire(1)方法去尝试请求成功，-->第三次插队（当然，这次插队不一定不会使其获得执行权，请看下边一条）， |
19 | * 2.3.1.1）如果第一次请求就成功，不用中断自己的线程，如果是之后的循环中将线程挂起之后又请求成功了，使用selfInterrupt()中断自己 |
20 | * （注意p==head&&tryAcquire(1)成功是唯一跳出循环的方法，在这之前会一直阻塞在这里，直到其他线程在执行的过程中，不断的将p的前边的节点减少，直到p成为了head且node请求成功了--即node被唤醒了，才退出循环） |
21 | * 2.3.1.2）如果p不是头节点，或者tryAcquire(1)请求不成功，就去执行shouldParkAfterFailedAcquire(Node pred, Node node)来检测当前节点是不是可以安全的被挂起， |
22 | * 2.3.1.2.1）如果node的前驱节点pred的等待状态是SIGNAL（即可以唤醒下一个节点的线程），则node节点的线程可以安全挂起，执行2.3.1.3） |
23 | * 2.3.1.2.2）如果node的前驱节点pred的等待状态是CANCELLED，则pred的线程被取消了，我们会将pred之前的连续几个被取消的前驱节点从队列中剔除，返回false（即不能挂起），之后继续执行2.3）中上述的代码 |
24 | * 2.3.1.2.3）如果node的前驱节点pred的等待状态是除了上述两种的其他状态，则使用CAS尝试将前驱节点的等待状态设为SIGNAL，并返回false（因为CAS可能会失败，这里不管失败与否，都返回false，下一次执行该方法的之后，pred的等待状态就是SIGNAL了），之后继续执行2.3）中上述的代码 |
25 | * 2.3.1.3）如果可以安全挂起，就执行parkAndCheckInterrupt()挂起当前线程，之后，继续执行2.3）中之前的代码 |
26 | * 最后，直到该节点的前驱节点p之前的所有节点都执行完毕为止，我们的p成为了头节点，并且tryAcquire(1)请求成功，跳出循环，去执行。 |
27 | * （在p变为头节点之前的整个过程中，我们发现这个过程是不会被中断的） |
28 | * 2.3.2）当然在2.3.1）中产生了异常，我们就会执行cancelAcquire(Node node)取消node的获取锁的意图。 |
29 | */ |
30 | final void lock() { |
31 | if (compareAndSetState(0, 1))//如果CAS尝试成功 |
32 | setExclusiveOwnerThread(Thread.currentThread());//设置当前线程为独占锁的线程 |
33 | else |
34 | acquire(1); |
35 | } |
FairSync：lock()
1 | final void lock() { |
2 | acquire(1); |
3 | } |
AbstractQueuedSynchronizer：acquire(int arg)就是非公平锁使用的那个方法
FairSync：tryAcquire(int acquires)
1 | /** |
2 | * 获取公平锁的方法 |
3 | * 1）获取锁数量c |
4 | * 1.1)如果c==0，如果当前线程是等待队列中的头节点，使用CAS将state（锁数量）从0设置为1，如果设置成功，当前线程独占锁-->请求成功 |
5 | * 1.2)如果c!=0，判断当前的线程是不是就是当下独占锁的线程，如果是，就将当前的锁数量状态值+1（这也就是可重入锁的名称的来源）-->请求成功 |
6 | * 最后，请求失败后，将当前线程链入队尾并挂起，之后等待被唤醒。 |
7 | */ |
8 | protected final boolean tryAcquire(int acquires) { |
9 | final Thread current = Thread.currentThread(); |
10 | int c = getState(); |
11 | if (c == 0) { |
12 | if (isFirst(current) && compareAndSetState(0, acquires)) { |
13 | setExclusiveOwnerThread(current); |
14 | return true; |
15 | } |
16 | } |
17 | else if (current == getExclusiveOwnerThread()) { |
18 | int nextc = c + acquires; |
19 | if (nextc < 0) |
20 | throw new Error("Maximum lock count exceeded"); |
21 | setState(nextc); |
22 | return true; |
23 | } |
24 | return false; |
25 | } |
最后，如果请求失败后，将当前线程链入队尾并挂起，之后等待被唤醒，下边的代码与非公平锁一样。