ReentrantLock面试涉及知识点

　　reentrant 英[riːˈɛntrənt] 美[ˌriˈɛntrənt] 先学会读。单词原意是可重入的

1. 考察显示锁的使用。可延伸知识点
   1. 独占锁 & 共享锁
      1. 独占锁 - 悲观锁（不能同时被多个线程持有 - synchronized锁 & ReentrantLock）
      2. 共享锁 - 乐观锁（ReentrantReadLock & CAS）
      3. 读共享、写排他
   2. 重入锁　　
      1. 方法进行深层次调用时，获取同一把锁能够获取到，不会死锁　　
   3. CAS原理实现乐观锁
      1. 原理 ： 在线程对数据进行修改时，需要对比现在持有的变量和原始地址中的值是否相同,若相同则替换成功，若不同替换失败
      2. 实现乐观锁 = 自旋 + CAS
      3. 问题 ：
         1. ABA问题 - jdk AtomicStampedReference  AtomicMarkableReference
         2. 自旋时间过长会导致CPU消耗过大
         3. 一次操作只能修改一个内存地址的变量 AtomicReference<V>
      4. jdk相关实现类
         1. AtomicInteger  
         2. AtomicReference<V>  多个共享变量一起操作
         3. AtomicReferenceArray  操作时是复制了原数组一份，修改后原数组的值不变
         4. AtomicMarkableReference 解决ABA问题，但只关心是否改变
         5. AtomicStampedReference 解决ABA问题，会记录改变次数.可通过getStamp()获取
   4. CHL队列锁 - 手绘图
      1. 每个线程拿锁时创建一个Node，locked状态置为true，把自己放到链表的tail,然后把myPred指向之前的tail，之后向前循环check locked状态，直到为false时自己就拿到了锁
   5. AQS - 抽象队列同步器
      1. 采用模板方法，一些方法需要继承者实现,但为什么不设计成abstract方法（抽象方法都要实现,为开发者考虑,独占式获取锁只实现独占方法，共享方式只实现共享方法）
         1. 独占式 tryAcquire、 tryRelease、isHeldExclusively
         2. 共享 tryAcquireShared、tryReleaseShared、isHeldExclusively
      2. state属性
         1. volatile int state 代表共享资源
         2. 提供三种访问方式 getState()、setState()、compareAndSetState() 
            1. setState 和 compareAndSetState 有什么区别 ？ 前者不是有安全问题吗，为什么还存在。（setState 是在已经拿到锁的情况下调用，不会有安全问题）
         3. ReentrantLock 用来标记拿锁的次数、CountDownLatch 用来标记任务的个数
      3. Node - 代表每个线程状态
         1. waitStatus　　
      4. acquire()方法
         1. addWaiter() 
            1. 如果队列不为空，CAS尝试一次将node放入队尾，成功直接返回
            2. 如果队列为空会初始化空节点作为head和tail。
         2. acquireQueued() 真正的拿锁方法 返回等待过程中是否被中断过，自旋+阻塞获取资源 
            1. 若前驱结点是head且拿到了锁的情况下，把当前节点置为head节点，并把原head节点脱离
            2. shouldParkAfterFailedAcquire(Node, Node) 返回前驱节点是否处于等待状态Node.SIGNAL。并将自己放在此节点的后置节点
            3. parkAndCheckInterrupt() 返回是否被中断过。阻塞当前线程，如果线程被唤醒，检查是被打断还是被正常唤醒
         3. 先去尝试拿锁，拿不到就将自己放在等待队列尾部，然后自旋向前寻找，直到head节点拿到锁为止。即使中间被打算，等待过程也不会中断。而是在拿到锁之后再中断自己
      5. release()方法
         1. 释放锁成功之后调用 unparkSuccessor(head) -> 将head节点状态置为0，用unpark()唤醒等待队列中最后边的那个未放弃线程
         2. 如果后继第一个节点状态是cancelled，那么就从尾部查找到正在等待的线程唤醒
      6. 共享拿锁（共享锁- 多个线程都能拿到该锁）
         
         1. 和独占式拿锁不一样的地方 - setHeadAndPropagate(node, r);
         2. if (s == null || s.isShared()) doReleaseShared(); 如果后继节点是共享锁执行释放
      7. 共享释放锁（释放后多个线程都要拿锁）
         1. 是一个自旋，会唤醒等待的节点。退出条件是已经没有等待共享锁可唤醒的线程　　　
   6. 模板方法
2. 实现
   1. ReentrantLock自身并未继承AQS，而是采用内部类Sync继承。屏蔽内部实现、外部调用者不用关心具体细节
   2. 如何实现可重入
      1. tryAcquire if(state ==0 )的else中进行当前线程锁的累加
   3. 公平锁和非公平锁有什么区别
      1. 非公平锁再获取锁的时候不按排队顺序而是随机拿锁　
      2. tryAcquire方法中!hasQueuedPredecessors() 来判定队列中是否有前驱节点在等待锁
   4. 在阻塞之前，线程都会通过shouldParkAfterFailedAcquire去修改其前驱节点的waitStatus=-1。这是为什么？为了release时unparkSuccessor(head) 唤醒后续节点
   5. unparkSuccessor时为什么会出现s==null || s.waitStatus>0的情况，这种情况下，为什么要通过prev指针反向查找Successor节点？
      1. s == null 是因为acquireQueued() 在拿到锁之后会将head.next = null .这样链表就断了，所以要从尾部节点向前找
      2. s > 0 是在cancel的时候，节点在head节点的后继节点断开。导致链表断裂。　　

 

梳理的lock包

 

 

 

参考AQS

　　https://www.cnblogs.com/waterystone/p/4920797.html　　　　

　　https://segmentfault.com/a/1190000015739343

图解 https://www.jianshu.com/p/b6efbdbdc6fa