Introduction：可重入锁，靠state参数来记录重入次数，靠waitStatus参数来监控线程状态，靠双向链表维护等待锁的线程队列，靠waitStatus来判断是否存在需要唤醒的park状态的线程
ReentrantLock基础用法
执行过程
执行结果
ReentrantLock类结构
四、Realization
构造方法
以非公平锁为例：
lock()
lock()调用顺序
reentrantLock对象调用lock()，实际是调用自己sync属性对象的lock()，sync实际是NonfairSync对象，最终调用NonfairSync类里的lock()。
NonfairSync类里的lock()
FairSync里的lock();
若直接修改成功，前提条件自然是锁的状态为0，则直接将线程的Owner修改为当前线程，这是一种理想情况，否则调用acquire(1)。
AbstractQueuedSynchronizer里的aquire(int arg)
NonfairSync里的tryAcquire(int acquires)
Sync里的nonfairTryAcquire(int acquires)
FairSync里的tryAcquire(int acquires)
1、首先获取这个锁的状态，如果状态为0，则尝试设置状态为传入的参数（这里就是1）
若设置成功就代表自己获取到了锁，返回true了。状态为0设置1的动作在外部就有做过一次，内部再一次做只是提升概率，而且这样的操作相对锁来讲不占开销。 如果状态不是0，则判定当前线程是否为排它锁的Owner，如果是Owner则尝试将状态增加acquires（也就是增加1）
2、如果这个状态值越界，则会抛出异常提示，若没有越界，将状态设置进去后返回true。
3、如果状态不是0，且自身不是owner，则返回false。
AbstractQueuedSynchronizer里的addWaiter(Node mode)
创建了一个Node的对象，将当前线程和传入的Node.EXCLUSIVE传入，Node节点理论上包含了这两项信息。
tail是AQS的一个属性，刚开始的时候肯定是为null，也就是不会进入第一层if判定的区域，而直接会进入enq(node)的代码
AbstractQueuedSynchronizer里的enq(final Node node)
首先这是个死循环，而且本身没有锁，因此可以有多个线程进来。
假如某个线程进入方法，此时head、tail都是null，进入if(t == null)所在的代码区域，创建一个空的Node，
传入的Node对象首先被它的next引用所指向，此时传入的node和某一个线程创建的h对象如下图所示:
插入多个节点的时候，以此类推，总之节点都是在链表尾部写入的，而且是线程安全的
AbstractQueuedSynchronizer里的acquireQueued(final Node node, int arg)
这里也是一个死循环，除非进入if(p == head && tryAcquire(arg))这个判定条件，而p为node.predcessor()返回node节点的前一个节点
前一个节点是head的时候，尝试通过tryAcquire(arg)来尝试加锁。
tryAcquire(arg)成立的条件为：锁的状态为0且通过CAS尝试设置状态成功或线程的持有者本身是当前线程才会返回true
如果这个条件判定成功：
（1）首先调用setHead(Node)的操作，这个操作内部会将传入的node节点作为AQS的head所指向的节点。线程属性设置为null，prev引用赋值为null。
（2） 将前一个节点的next引用赋值为null。
在这样修改后，队列的结构就变成了下图，这样就可以让执行完的节点释放掉内存区域，而不是无限制增长队列：
如果这个判定条件失败
（1）首先判定shouldParkAfterFailedAcquire(p , node)
这个方法内部会判定前一个节点的状态是否为：“Node.SIGNAL”，若是则返回true，若不是都会返回false判定节点的状态是否大于0，若大于0则认为被“CANCELLED”，因此会向前逐步循环找到一个没有被“CANCELLED”节点，然后与这个节点的next、prev的引用相互指向；如果前一个节点的状态不是大于0的，则通过CAS尝试将状态修改为“Node.SIGNAL”，下一轮循环的时候会返回值应该会返回true。
（2）如果这个方法返回了true，则执行parkAndCheckInterrupt()方法，它是通过LockSupport.park(this)将当前线程挂起到WATING状态，等待一个中断、unpark()方法来唤醒它
AbstractQueuedSynchronizer里的shouldParkAfterFailedAcquire(Node pred, Node node)
waitStatus取值
lockInterruptibly()：允许在等待时由其它线程调用等待线程的Thread.interrupt方法来中断等待线程的等待而直接返回，这时不用获取锁，抛出一个InterruptedException。
lock方法不允许Thread.interrupt中断,即使检测到Thread.isInterrupted,一样会继续尝试获取锁，失败则继续休眠。只是在最后获取锁成功后再把当前线程置为interrupted状态,然后再中断线程
tryLock()：尝试获得锁，仅在调用时锁未被线程占用，获得锁
tryLock(long timeout TimeUnit unit)：如果锁在给定等待时间内没有被另一个线程保持，则获取该锁
unlock()
ReentrantLock类里的unlock()
release()
tryRealease()
唤醒后继节点
getHoldCount()：查询当前线程保持此锁的次数，也就是state的值，不是自己持有返回0
isHeldByCurrentThread()：是否是当前线程持有锁
isLocked()：当前线程是否保持锁锁定，state!=0
isFair()：该锁是否公平锁,sync instanceof FairSync
getOwner()：返回此时持有锁的线程：getState() == 0 ? null : getExclusiveOwnerThread();
hasQueuedThreads()：是否有线程等待此锁：head != tail
hasQueuedThread(Thread thread)
查询给定线程是否等待获取此锁
getQueueLength()
返回正等待获取此锁的线程估计数
网友评论