java公平锁和非公平锁
最经常使用的方式：node
View Code安全
一、对于ReentrantLock须要掌握如下几点数据结构
- ReentrantLock的建立（公平锁/非公平锁）
- 上锁：lock()
- 解锁：unlock()
首先说一下类结构：ui
- ReentrantLock-->Lock
- NonfairSync/FairSync-->Sync-->AbstractQueuedSynchronizer-->AbstractOwnableSynchronizer
- NonfairSync/FairSync-->Sync是ReentrantLock的三个内部类
- Node是AbstractQueuedSynchronizer的内部类
注意：上边这四条线，对应关系："子类"-->"父类"this
二、ReentrantLock的建立线程
- 支持公平锁（先进来的线程先执行）
- 支持非公平锁（后进来的线程也可能先执行）
非公平锁与非公平锁的建立队列
- 非公平锁：ReentrantLock()或ReentrantLock(false)
final ReentrantLock lock = new ReentrantLock();
- 公平锁：ReentrantLock(true)
final ReentrantLock lock = new ReentrantLock(true)
默认状况下使用非公平锁。ci
源代码以下：get
ReentrantLock：同步
/** 同步器：内部类Sync的一个引用 */
private final Sync sync;
/**
* 建立一个非公平锁
*/
public ReentrantLock() {
sync = new NonfairSync();
}
/**
* 建立一个锁
* @param fair true-->公平锁 false-->非公平锁
*/
public ReentrantLock(boolean fair) {
sync = (fair)? new FairSync() : new NonfairSync();
}
上述源代码中出现了三个内部类Sync/NonfairSync/FairSync，这里只列出类的定义，至于这三个类中的具体的方法会在后续的第一次引用的时候介绍。
Sync/NonfairSync/FairSync类定义：
/**
* 该锁同步控制的一个基类.下边有两个子类：非公平机制和公平机制.使用了AbstractQueuedSynchronizer类的
*/
static abstract class Sync extends AbstractQueuedSynchronizer
/**
* 非公平锁同步器
*/
final static class NonfairSync extends Sync
/**
* 公平锁同步器
*/
final static class FairSync extends Sync
三、非公平锁的lock()
具体使用方法：
lock.lock();
下面先介绍一下这个整体步骤的简化版，而后会给出详细的源代码，并在源代码的lock()方法部分给出详细版的步骤。
简化版的步骤：（非公平锁的核心）
基于CAS尝试将state（锁数量）从0设置为1
A、若是设置成功，设置当前线程为独占锁的线程；
B、若是设置失败，还会再获取一次锁数量，
B一、若是锁数量为0，再基于CAS尝试将state（锁数量）从0设置为1一次，若是设置成功，设置当前线程为独占锁的线程；
B二、若是锁数量不为0或者上边的尝试又失败了，查看当前线程是否是已是独占锁的线程了，若是是，则将当前的锁数量+1；若是不是，则将该线程封装在一个Node内，并加入到等待队列中去。等待被其前一个线程节点唤醒。
源代码：（再介绍源代码以前，内心有一个获取锁的步骤的总的一个印象，就是上边这个"简化版的步骤"）
3.一、ReentrantLock：lock()
/**
*获取一个锁
*三种状况：
*一、若是当下这个锁没有被任何线程（包括当前线程）持有，则当即获取锁，锁数量==1，以后再执行相应的业务逻辑
*二、若是当前线程正在持有这个锁，那么锁数量+1，以后再执行相应的业务逻辑
*三、若是当下锁被另外一个线程所持有，则当前线程处于休眠状态，直到得到锁以后，当前线程被唤醒，锁数量==1，再执行相应的业务逻辑
*/
public void lock() {
sync.lock();//调用NonfairSync（非公平锁）或FairSync（公平锁）的lock()方法
}
3.二、NonfairSync：lock()
/**
* 1）首先基于CAS将state（锁数量）从0设置为1，若是设置成功，设置当前线程为独占锁的线程；-->请求成功-->第一次插队
* 2）若是设置失败(即当前的锁数量可能已经为1了，即在尝试的过程当中，已经被其余线程先一步占有了锁)，这个时候当前线程执行acquire(1)方法
* 2.1）acquire(1)方法首先调用下边的tryAcquire(1)方法，在该方法中，首先获取锁数量状态，
* 2.1.1）若是为0(证实该独占锁已被释放，当下没有线程在使用)，这个时候咱们继续使用CAS将state（锁数量）从0设置为1，若是设置成功，当前线程独占锁；-->请求成功-->第二次插队；固然，若是设置不成功，直接返回false
* 2.2.2）若是不为0，就去判断当前的线程是否是就是当下独占锁的线程，若是是，就将当前的锁数量状态值+1（这也就是可重入锁的名称的来源）-->请求成功
*
* 下边的流程一句话：请求失败后，将当前线程链入队尾并挂起，以后等待被唤醒。
*
* 2.2.3）若是最后在tryAcquire(1)方法中上述的执行都没成功，即请求没有成功，则返回false，继续执行acquireQueued(addWaiter(Node.EXCLUSIVE), arg)方法
* 2.2）在上述方法中，首先会使用addWaiter(Node.EXCLUSIVE)将当前线程封装进Node节点node，而后将该节点加入等待队列（先快速入队，若是快速入队不成功，其使用正常入队方法无限循环一直到Node节点入队为止）
* 2.2.1）快速入队：若是同步等待队列存在尾节点，将使用CAS尝试将尾节点设置为node，并将以前的尾节点插入到node以前
* 2.2.2）正常入队：若是同步等待队列不存在尾节点或者上述CAS尝试不成功的话，就执行正常入队（该方法是一个无限循环的过程，即直到入队为止）-->第一次阻塞
* 2.2.2.1）若是尾节点为空（初始化同步等待队列），建立一个dummy节点，并将该节点经过CAS尝试设置到头节点上去，设置成功的话，将尾节点也指向该dummy节点（即头节点和尾节点都指向该dummy节点）
* 2.2.2.1）若是尾节点不为空，执行与快速入队相同的逻辑，即便用CAS尝试将尾节点设置为node，并将以前的尾节点插入到node以前
* 最后，若是顺利入队的话，就返回入队的节点node，若是不顺利的话，无限循环去执行2.2)下边的流程，直到入队为止
* 2.3）node节点入队以后，就去执行acquireQueued(final Node node, int arg)（这又是一个无限循环的过程，这里须要注意的是，无限循环等于阻塞，多个线程能够同时无限循环--每一个线程均可以执行本身的循环，这样才能使在后边排队的节点不断前进）
* 2.3.1）获取node的前驱节点p，若是p是头节点，就继续使用tryAcquire(1)方法去尝试请求成功，-->第三次插队（固然，此次插队不必定不会使其得到执行权，请看下边一条），
* 2.3.1.1）若是第一次请求就成功，不用中断本身的线程，若是是以后的循环中将线程挂起以后又请求成功了，使用selfInterrupt()中断本身
* （注意p==head&&tryAcquire(1)成功是惟一跳出循环的方法，在这以前会一直阻塞在这里，直到其余线程在执行的过程当中，不断的将p的前边的节点减小，直到p成为了head且node请求成功了--即node被唤醒了，才退出循环）
* 2.3.1.2）若是p不是头节点，或者tryAcquire(1)请求不成功，就去执行shouldParkAfterFailedAcquire(Node pred, Node node)来检测当前节点是否是能够安全的被挂起，
* 2.3.1.2.1）若是node的前驱节点pred的等待状态是SIGNAL（便可以唤醒下一个节点的线程），则node节点的线程能够安全挂起，执行2.3.1.3）
* 2.3.1.2.2）若是node的前驱节点pred的等待状态是CANCELLED，则pred的线程被取消了，咱们会将pred以前的连续几个被取消的前驱节点从队列中剔除，返回false（即不能挂起），以后继续执行2.3）中上述的代码
* 2.3.1.2.3）若是node的前驱节点pred的等待状态是除了上述两种的其余状态，则使用CAS尝试将前驱节点的等待状态设为SIGNAL，并返回false（由于CAS可能会失败，这里无论失败与否，都返回false，下一次执行该方法的以后，pred的等待状态就是SIGNAL了），以后继续执行2.3）中上述的代码
* 2.3.1.3）若是能够安全挂起，就执行parkAndCheckInterrupt()挂起当前线程，以后，继续执行2.3）中以前的代码
* 最后，直到该节点的前驱节点p以前的全部节点都执行完毕为止，咱们的p成为了头节点，而且tryAcquire(1)请求成功，跳出循环，去执行。
* （在p变为头节点以前的整个过程当中，咱们发现这个过程是不会被中断的）
* 2.3.2）固然在2.3.1）中产生了异常，咱们就会执行cancelAcquire(Node node)取消node的获取锁的意图。
*/
final void lock() {
if (compareAndSetState(0, 1))//若是CAS尝试成功
setExclusiveOwnerThread(Thread.currentThread());//设置当前线程为独占锁的线程
else
acquire(1);
}
注意：在这个方法中，我列出了一个线程获取锁的详细的过程，本身看注释。
下面列出NonfairSync：lock()中调用的几个方法与相关属性。
3.2.一、AbstractQueuedSynchronizer：锁数量state属性+相关方法：
/**
* 锁数量
*/
private volatile int state;
/**
* 获取锁数量
*/
protected final int getState() {
return state;
}
protected final void setState(int newState) {
state = newState;
}
注意：state是volatile型的
3.2.二、AbstractOwnableSynchronizer：属性+setExclusiveOwnerThread(Thread t)
/**
* 当前拥有独占锁的线程
*/
private transient Thread exclusiveOwnerThread;
/**
* 设置独占锁的线程为线程t
*/
protected final void setExclusiveOwnerThread(Thread t) {
exclusiveOwnerThread = t;
}
3.2.三、AbstractQueuedSynchronizer：属性+acquire(int arg)
/**
* 获取锁的方法
* @param arg
*/
public final void acquire(int arg) {
if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();//中断本身
}
在介绍上边这个方法以前，先要说一下AbstractQueuedSynchronizer的一个内部类Node的总体构造，源代码以下：
/**
* 同步等待队列（双向链表）中的节点
*/
static final class Node {
/** 线程被取消了 */
static final int CANCELLED = 1;
/**
* 若是前驱节点的等待状态是SIGNAL，表示当前节点未来能够被唤醒，那么当前节点就能够安全的挂起了
* 不然，当前节点不能挂起
*/
static final int SIGNAL = -1;
/**线程正在等待条件*/
static final int CONDITION = -2;
/**
* waitStatus value to indicate the next acquireShared should
* unconditionally propagate
*/
static final int PROPAGATE = -3;
/** Marker to indicate a node is waiting in shared mode */
static final Node SHARED = new Node();
/** 一个标记：用于代表该节点正在独占锁模式下进行等待 */
static final Node EXCLUSIVE = null;
//值就是前四个int（CANCELLED/SIGNAL/CONDITION/PROPAGATE），再加一个0
volatile int waitStatus;
/**前驱节点*/
volatile Node prev;
/**后继节点*/
volatile Node next;
/**节点中的线程*/
volatile Thread thread;
/**
* Link to next node waiting on condition, or the special value SHARED.
* Because condition queues are accessed only when holding in exclusive
* mode, we just need a simple linked queue to hold nodes while they are
* waiting on conditions. They are then transferred to the queue to
* re-acquire. And because conditions can only be exclusive, we save a
* field by using special value to indicate shared mode.
*/
Node nextWaiter;
/**
* Returns true if node is waiting in shared mode
*/
final boolean isShared() {
return nextWaiter == SHARED;
}
/**
* 返回该节点前一个节点
*/
final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
}
Node() { // Used to establish initial head or SHARED marker
}
Node(Thread thread, Node mode) { // 用于addWaiter中
this.nextWaiter = mode;
this.thread = thread;
}
Node(Thread thread, int waitStatus) { // Used by Condition
this.waitStatus = waitStatus;
this.thread = thread;
}
}
注意：这里我给出了Node类的完整版，其中部分属性与方法是在共享锁的模式下使用的，而咱们这里的ReentrantLock是一个独占锁，只需关注其中的与独占锁相关的部分就好（具体有注释）
3.三、AbstractQueuedSynchronizer：acquire(int arg)方法中使用到的两个方法
3.3.一、NonfairSync：tryAcquire(int acquires)
View Code
Syn：
View Code
注意：这个方法就完成了"简化版的步骤"中的"A/B/B1"三步，若是上述的请求不能成功，就要执行下边的代码了，
下边的代码，用一句话介绍：请求失败后，将当前线程链入队尾并挂起，以后等待被唤醒。在你看下边的代码的时候内心默记着这句话。
3.3.二、AbstractQueuedSynchronizer：addWaiter(Node mode)
View Code
AbstractQueuedSynchronizer：enq(final Node node)
View Code
注意：这里就是一个完整的入队方法，具体逻辑看注释和ReentrantLock：lock()的注释部分的相关部分。
3.3.三、AbstractQueuedSynchronizer：acquireQueued(final Node node, int arg)
View Code
AbstractQueuedSynchronizer：shouldParkAfterFailedAcquire(Node pred, Node node)
View Code
AbstractQueuedSynchronizer：
View Code
以上就是一个线程获取非公平锁的整个过程（lock()）。
四、公平锁的lock()
具体用法与非公平锁同样
若是掌握了非公平锁的流程，那么掌握公平锁的流程会很是简单，只有两点不一样（最后会讲）。
简化版的步骤：（公平锁的核心）
获取一次锁数量，
B一、若是锁数量为0，若是当前线程是等待队列中的头节点，基于CAS尝试将state（锁数量）从0设置为1一次，若是设置成功，设置当前线程为独占锁的线程；
B二、若是锁数量不为0或者当前线程不是等待队列中的头节点或者上边的尝试又失败了，查看当前线程是否是已是独占锁的线程了，若是是，则将当前的锁数量+1；若是不是，则将该线程封装在一个Node内，并加入到等待队列中去。等待被其前一个线程节点唤醒。
源代码：
4.一、ReentrantLock：lock()
View Code
4.二、FairSync：lock()
View Code
4.三、AbstractQueuedSynchronizer：acquire(int arg)就是非公平锁使用的那个方法
4.3.一、FairSync：tryAcquire(int acquires)
View Code
最后，若是请求失败后，将当前线程链入队尾并挂起，以后等待被唤醒，下边的代码与非公平锁同样。
总结：公平锁与非公平锁对比
- FairSync：lock()少了插队部分（即少了CAS尝试将state从0设为1，进而得到锁的过程）
- FairSync：tryAcquire(int acquires)多了须要判断当前线程是否在等待队列首部的逻辑（实际上就是少了再次插队的过程，可是CAS获取仍是有的）。
最后说一句，
- ReentrantLock是基于AbstractQueuedSynchronizer实现的，AbstractQueuedSynchronizer能够实现独占锁也能够实现共享锁，ReentrantLock只是使用了其中的独占锁模式
- 这一起代码比较多，逻辑比较复杂，最好在阅读的过程当中，能够拿一根笔画画入队等与数据结构相关的图
- 必定要记住"简化版的步骤"，这是整个非公平锁与公平锁的核心
- 1. Java锁之公平和非公平锁
- 2. java之公平锁与非公平锁
- 3. Java 公平锁与非公平锁
- 4. Java并发锁-公平锁和非公平锁
- 5. JAVA锁 —— ReentrantLock公平锁和非公平锁原理详解
- 6. java重入锁、公平锁和非公平锁
- 7. 公平锁与非公平锁
- 8. 公平锁与非公平锁是啥？
- 9. ReentrantLock公平锁与非公平锁
- 10. 重入锁和自旋锁(公平锁及非公平锁)
- 更多相关文章...
- • ionic 平台 - ionic 教程
- • Hibernate悲观锁 - Hibernate教程
- • 漫谈MySQL的锁机制
- • Java 8 Stream 教程
-
每一个你不满意的现在，都有一个你没有努力的曾经。