ReentrantLock原理

ReentrantLock，顾名思义，可重入锁

首先看下源码

实现了Lock类，先基本看下Lock类

lock：获取锁，锁被其他线程占用，那么会等待，直到获取锁

lockInterruptibly：获取锁，但是假如当前线程在等待锁的时候被中断，抛出中断异常

tryLock：尝试获取锁，并立即返回

tryLock：在一定时间范围类尝试获取锁

unLock：释放锁

newCondition：新建一个绑定在当前Lock上的Condition对象，condition表示一个等待状态，获得锁的线程需要一个等待时间或者是等待条件完成后，那么它可以通过await方法注册在Condition对象上进行等待，然后通过condition对象的signal方法唤醒，有点类似Object的wait和notify方法，但不同的是，一个Lock对象可以绑定多个Condition，多个线程可以被绑定在不同的Condition上，这样就可以分组唤醒。

属性Sync的类型就是内部类Sync，Sync继承了AQS，Sync被abstract修饰，需要子类来实现。

Sync中lock方法是abstract方法，说明FairSync和NonfairSync实现lock方法是不同的。

Sync中还有readObject方法，用于反序列化自身

Sync除了以上两个方法，其余都被final修饰，不可修改的，因为本身Sync继承了AQS且重写了比较完善的方法，希望直接被外部调用，而不被修改

下面来看Sync的其他方法

nonfairTryAcquire----非公平的尝试获取锁

1、首先获取state状态，state==0时，锁状态为空闲，那么就进行CAS进行获取锁，如果获取成功，并将当前线程设置为独占线程，并返回true，否则返回false。

2、再来看if(current == getExclusiveOwnerThread())，如果当前线程是该独占线程，这一步判断有点疑惑，为什么呢？

这里是对可重入的实现，也就是单个线程执行时重新进入同一个子程序仍然时线程安全的。

如果不是当前线程直接返回false，是的话那就state值+1，记录可重入次数，因为释放的时候要释放n次。

那么if（nextc < 0），int可能为负数嘛，当然可能，当超过int最大值时，就会溢出变为负。

tryRelease

这个方法返回的是布尔值，一般看了这个方法会觉得释放成功返回true，失败返回false，错❌

这里表达的是是否完全被释放，而不是上述那样

由于Sync内部类是抽象类，还必须需要看子类NonfairSync、FairSync

公平锁：按照请求锁的顺序分配锁

非公平锁：不按照顺序分配，但是性能可能比公平锁要高

那么非公平锁不需要排队，按道理排队比哄抢的方式效率更高，而且非公平有可能导致某个线程一直拿不到锁一直阻塞着，这样的设计有什么好处呢？

非公平锁意味着后请求的线程可能在前面休眠线程唤醒前拿到锁，这样就可能提高并发性能

唤醒一个挂起的线程，线程间的状态切换会发生短暂的延时，非公平锁就能见缝插针利用这段时间获取到锁

NonfairSync

lock：上来就是一个CAS获取锁的操作，这里可以看出不管前面有没有等待的线程，直接获取，说明是非公平的。

成功--设置当前线程为独占线程；失败---尝试调用AQS的acquire方法 ，可查看AQS机制

lock方法用了两次获取锁的尝试，两次都失败的话那就只能等待。

tryAcquire：进行一次插队尝试，上层可以循环调用该方法尝试非公平插入获取锁，体现了非公平锁的特性。

FairSync

lock方法不用过多解释了；

tryAcquire：

首先获取state值，如果锁空闲，直接进入hasQueuedPredecessors（），FIFO队列中没有排在当前线程之前的线程，那么允许获取，成功返回true；

其他基本都是解释过

ReentrantLock中的锁

tryLock方法

也就是说无论公平锁还是非公平锁，tryLock都是非公平的，这也是为什么Sync当中为什么直接定义了nonfairTryAcquire而不是在NonfairLock当中定义

lock方法就不看了，先来看lockInterruptibly方法，调用了AQS的acquireInterruptibly方法，该方法主要实现为，线程在等待锁过程中，如果被调用了interrupt，会直接抛出异常