并发编程中的ReentrantLock 原理篇（源码分析)

1. 为什么会用到ReentrantLock锁？

锁是用来做什么的？

有哪些常见锁？

java语言的ReentrantLock和内置锁synchronized一样，都是为了实现并发编程中的多线程同步执行，保证线程的安全和业务数据的准确性；如果不上锁，线程间是异步执行的，而当多线程访问共同资源的时候，这就有了上锁的必要来保证资源同步执行，实现业务的逻辑运作。

多线程同步的方式中，常见锁有：wait 和 notify， synchronized, reentrantlock等。

2. java中关键字synchronized和ReentrantLock有什么区别，为什么有了前者，还有后者呢？

ReentrantLock是JDK1.6 才有的多线程同步, 在此之前，都用的是synchronized。所以是先有synchronized, 后有ReentrantLock.

synchronized 是重量级锁，会调用操作系统函数里面有很多native方法（java自带的C语言方法）比如： private native void start0(); //调用的就是openjdk中一个c语言文件中的操作系统函数启动线程；换言之，JVM 起一个线程Thread t，等同于在os操作系统中起线程服务且他们是一一对应的关系。那么，从操作系统来看，线程在挂起或者阻塞的时候，CPU会反复从内核态切换至用户态，导致sync锁变成了重量级意义层面上的锁。

所以JDK1.6之前，线程的同步和阻塞，是借助操作系统来完成, 而Reentrantlock是轻量级锁，只在JVM完成线程的同步，参考java package JUC(java.util.concurrent.locks)，一个大神开发了整个线程同步的包，牛的一批！～脱离了操作系统内核态权限的访问和状态的切换，线程同步也变得越来越快了！～～～后来sync作为java的内置锁，SUN公司也在JDK1.7之后进行了多次改进和优化，现在sync和reentrantlock基本上性能差不多，甚至sync更优秀一丢丢？基本呈齐头并进之势; 比如，哈希数据结构用来保证线程安全的ConcurentHashMap实现高并发性能读写，采用锁分段技术segment，segment彼此之间互不影响。借用的就是synchronized加锁机制。

要知道一点，synchronized是没有源码的，至少我们看到的都是c++实现的，而Reentrantlock源码可见，容易理解

3. ReentrantLock 是不是公平锁？

默认ReentrantLock不是公平锁（非公平锁）

参考源码：

ReentrantLock lock = new ReentrantLock(); //点进去看；

public ReentrantLock() {

sync = new NonfairSync(); //看到了吧，默认：new 一个非公平锁

}

改成true，则可以变成公平锁，参考代码：

ReentrantLock lock = new ReentrantLock(true); //点进去看；

public ReentrantLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync();}

（三目运算符，if true， new 公平锁，非true，则new 一个NonFairSync()）

Reentrantlock 公平锁源码分析：（参考我写的中文注释吧）

公平锁加锁过程，入口是acquire(1)请求独占锁；而acquire（）点进去调用的是tryAcquire（），所以tryAcquire是获取公平锁核心的调用方法。请参考具体代码注释

fairSync

Reentrantlock 非公平锁源码分析：（参考我写的中文注释吧）

整体思想：用CAS（compareAndSetState）判断线程数量，如果state是0，表示当前没有持有锁的线程，这样就可以设置为exclusiveOwnerThread（current），当前线程独占且持有锁；否则，state非0，大于0时候，那么重复acquire（1）获取锁

NonfairSync

小结：

1. JDK1.6之前， synchronized 机制都是os级别，性能不如java级别Reentrantlock ; 1.6之后，sync也在更新方法和性能，二者持平！～

2. 高并发执行的时候，有时候线程间是串行的有先后顺序，有时候是交替执行可能存在竞争的关系,比如同一时间段内，百万级用户先后在运行访问，（你访问，我也在访问，我还没访问完，可能他也开始了运行访问）；可是也会存在另外一个时段内，不存在多线程的情况，比如：凌晨00:00的时候，个位数用户级别在运行或者1个用户访问。当多线程访问共同资源的时候，我们需要上锁，但是此时如果统一使用synchnorized锁，会导致锁的性能表现很差（这是对JDK1.6之前而言）。因为在低数量级用户量面前，我们没有必要在用重量级锁造成资源的浪费。所以1.6 JDK之后，这也是为什么SUN公司对synchronized关键字做了后期的优化和改进的原因。但是因为synchronized的源码是C++而且市面上基本上看不到相关的准确分析。

而Reentrantlock，从来没有在操作系统层面内核态做任何操作，一直都是在java层面，对线程间获取锁，执行完毕释放锁给其他线程。所以Reentrantlock性能是稳定的状态。

3. Reentrantlock的应用在api表现上面，更为丰富，比如: lock, trylock(2中方法，带参数和不带参数), lockInterruptibly， unlock， condition 等。都是应用层面的表现。