java基础：java.util.concurrent.lock
前言
最近在使用BlockQueue和ConcurrentHashMap中都有个核心的东西ReentrantLock，网上有很多关于重入锁的介绍。下面自己的几个问题，然后再通过自己的实现来把问题讲清楚。
API官方解释
一个可重入的互斥锁 Lock，它具有与使用 synchronized 方法和语句所访问的隐式监视器锁相同的一些基本行为和语义，但功能更强大。 ReentrantLock 将由最近成功获得锁，并且还没有释放该锁的线程所"拥有"。当锁没有被另一个线程所拥有时，调用 lock 的线程将成功获取该锁并返回。如果当前线程已经拥有该锁，此方法将立即返回。可以使用 isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。
此类的构造方法接受一个可选的公平 参数。当设置为 true 时，在多个线程的争用下，这些锁倾向于将访问权授予等待时间最长的线程。否则此锁将无法保证任何特定访问顺序。与采用默认设置（使用不公平锁）相比，使用公平锁的程序在许多线程访问时表现为很低的总体吞吐量（即速度很慢，常常极其慢），但是在获得锁和保证锁分配的均衡性时差异较小。不过要注意的是，公平锁不能保证线程调度的公平性。因此，使用公平锁的众多线程中的一员可能获得多倍的成功机会，这种情况发生在其他活动线程没有被处理并且目前并未持有锁时。还要注意的是，未定时的 tryLock 方法并没有使用公平设置。因为即使其他线程正在等待，只要该锁是可用的，此方法就可以获得成功。
典型用法
class X {
private final ReentrantLock lock = new ReentrantLock();
// ...
public void m() {
lock.lock(); // block until condition holds
try {
// ... method body
} finally {
lock.unlock()
}
}
}
为什么理解ReentrantLock
- JDK里面的ReentrantLock实现非常精巧，ConcurrentHashMap，各种Queue都是基于ReentrantLock实现的，所以，了解ReentrantLock是十分必要的。
- ReentrantLock使用非常灵活，synchronized是JVM实现的，用起来不那么灵活。
- 了解内部实现原理，可以更好的帮助我们在开发中选型，也能更加容易理解并发包下其他实现类的原理。
ReentrantLock和synchronized
java中存在两种锁，一种是JDK实现的synchronized，还有一种是Lock，两者用法相似，又各有特点，了解其中的区别，才能更好的取舍。
实现
- synchronized是基于JVM实现的，Lock是基于java API实现的，我们可以通过源码就能知道Lock的实现。
- 两者的实现思路一致，都是抽象出来一个同步队列和一个等待队列，争抢锁的线程不断在同步队列和等待队列中不断转换。
- synchronized基于并发程度抽象出偏向锁、轻量级锁和重量级锁，而Lock没有这样的概念。
使用
- 对于使用者的直观体验上Lock是比较复杂的，需要lock和unlock，如果忘记释放锁就会产生死锁的问题，通常需要在finally中进行锁的释放。但是synchronized的使用十分简单，只需要对自己的方法或者关注的同步对象或类使用synchronized关键字即可
特点
| 功能 | synchronized | ReentrantLock |
|---|---|---|
| 锁获取超时 | 不支持 | 支持 |
| 获取锁响应中断 | 不支持 | 支持 |
| 是否要手动释放锁 | 否 | 是 |
性能
- 早期的synchronized是十分低下的，在1.5之后引入了偏向锁，轻量级锁，重量级锁，同时也优化了锁的争抢流程，大大提高 了synchronized的性能，同时在后面的版本中也还在对synchronized有优化。后面在JDK1.8中，ConcurrentHashMap取消了ReentrantLock的设计，而是直接用synchronized，因为synchronized在数据量少时性能足够优秀，而且整个流程更加简单，具体可以参考谈谈ConcurrentHashMap1.7和1.8的不同实现
- ReentrantLock没有像synchronized那样对锁划分成多个等级，根据并发程度的不同采取不同的策略，由于synchronized在竞争激烈的情况下会做锁的升级，性能急剧下降。所以ReentrantLock在竞争比较激烈的时候性能是很稳定的，少量竞争或者单线程的时候可能会逊色一些。
源码分析
- ReentrantLock实现Lock接口。Lock 实现提供了比使用 synchronized 方法和语句可获得的更广泛的锁定操作，此实现允许更灵活的结构，可以具有差别很大的属性，可以支持多个相关的 Condition
对象。 - ReentrantLock内部是由Sync，NonfairSync(非公平同步)，FairSync（公平同步）三个内部类实现，且这三个内部类都实现继承自非常著名的AbstractQueuedSynchronizer，简写AQS，中文名叫队列同步器，了解这个队列同步器，基本上就完成对整个concurrent包下的锁完全了解了。很多人不了解为何设计成内部类，我记得有一句话讲得好，内部类就像人体的一个器官，它自己有完整的功能，也能给身体提供功能，如果不把它设计成一个内部类就会很凌乱。
- 默认构造成NonfairSync。源码如下
/**
* Creates an instance of {@code ReentrantLock}.
* This is equivalent to using {@code ReentrantLock(false)}.
*/
public ReentrantLock() {
sync = new NonfairSync();
}
- 调用Lock方法，我们先从默认非公平锁开始分析
/**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
final void lock() {
if (compareAndSetState(0, 1))
// 设置当前拥有独占访问的线程。
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
代码一开始就直接用compareAndSetState，这是典型的CAS操作，关于CAS操作可以参考java基础：CAS操作，然后就是设置当前拥有独占访问的线程，否则执行acquire(1)
非公平锁的acquire(1)实现
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
tryAcquire的底层实现
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;
}
意思就是如果没有，就设置当前拥有独占访问的线程，设置完后就new一个Node节点添加到AQS队列中去等，等获得到空闲时就会设置当前拥有独自访问的线程，完事后就调用Thread.currentThread().interrupt();中断线程一直去尝试获取。
- 公平锁Lock实现
final void lock() {
acquire(1);
}
我们发现公平锁直接就调用acquire(1)方法，与非公平锁不同的是缺少CAS操作。
- lock.unLock();实现
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;
}
不管是公平锁还是非公平锁，unLock实现都一样，基本上就是设置一些状态，然后把独占线程清空。
什么时候选择用 ReentrantLock 代替 synchronized
在早期的版本中，synchronized性能其实非常底的，但在1.8之后，对synchronized的优化已经足够好了，甚至一些情况下，synchronized性能比ReentrantLock还要好，所以在1.8版本的ConcurrentHashMap实现取消了ReetrantLock设计，直接用synchronized。这并不代表ReetrantLock就不行了，在高并发及多线程环境下，ReetrantLock的性能依旧是最优选择。
总结
了解ReentrantLock其实最主要的两点，一是CAS操作，二是AQS，当然AQS是一切并发包下基础，我们只有了解其中的原理，就很容易了解这些锁的调用关系，其实都是AQS的一些应用，比如公平锁与非公平锁的区别就是是否获得锁时是否有CAS操作，有的是非公平锁，没有的是公平锁。因为ReentrantLock是对像，synchronized的一些用法都可以用ReentrantLock实现，而一些时间锁等候、可中断锁等候、无块结构锁、多个条件变量或者锁投票是synchronized不具备的，而ReentrantLock的性能在多线程环境中优势相当明显，所以理解ReentrantLock是对多线程和大并发环境的编程多了一种技术选型。
