• 【并发编程】ReentrantLock的lockInterruptibly()方法源码分析


    目录

    1 lockInterruptibly()

    2 lock()

    3 总结


    ReentrantLock.lockInterruptibly():允许在尝试获取锁时由其它线程调用尝试获取锁的线程的Thread.interrupt方法来中断线程而直接返回,这时不用获取到锁,而会直接抛出一个InterruptedException。

    • ReentrantLock.lock():方法不允许Thread.interrupt中断,即使检测到Thread.isInterrupted,一样会继续尝试获取锁,获取失败则阻塞等待。只是在最后获取锁成功后再把当前线程置为interrupted状态。

    总的来说,lockInterruptibly()支持线程中断,它与lock()方法的主要区别在于lockInterruptibly()获取锁的时候如果线程中断了,会抛出一个异常,而lock()不会管线程是否中断都会一直尝试获取锁,获取锁之后把自己标记为已中断,继续执行自己的逻辑,后面也会正常释放锁。我们就记住:

    1. 使用lockInterruptibly时:当前线程可以被其他线程直接中止结束,并且在其他线程中抛出异常信息;(优先考虑响应中断)
    2. 使用lock时:当前线程也可以响应其他线程的中断命令,但不会抛出异常信息,不会直接中止,而是会在成功获取到锁时将自己的中断标志设置true;(优先考虑获取锁)

    具体实现以及与lock()方法的对比如下:

    1 lockInterruptibly()

    1. // ReentrantLock.lockInterruptibly()
    2. // 相当于ReentrantLock.lock()
    3. public void lockInterruptibly() throws InterruptedException {
    4. // 这里调用的sync的acquireInterruptibly()方法,该方法是sync继承自AbstractQueuedSynchronizer的方法,由抽象类AbstractQueuedSynchronizer实现
    5. sync.acquireInterruptibly(1);
    6. }
    7. // AbstractQueuedSynchronizer.acquireInterruptibly()
    8. // 相当于acquire(int arg)方法
    9. public final void acquireInterruptibly(int arg) throws InterruptedException {
    10. // 在第一次调用acquireInterruptibly时,如果发现当前线程已经被中断了,则直接抛出中断异常,响应中断
    11. if (Thread.interrupted())
    12. throw new InterruptedException();
    13. // 尝试获取锁
    14. // 这里调用的sync的tryAcquire()方法,它的具体实现是根据当前ReentrantLock是公平锁还是非公平锁来决定的
    15. // 如果当前sync是公平锁tryAcquire()方法就是使用的FairSync实现类中的tryAcquire()实现方法,如果当前是非公平锁,则使用的是NonfairSync实现类中的tryAcquire()方法,也就是nonfairTryAcquire()方法
    16. if (!tryAcquire(arg))
    17. // 尝试获取所失败之后
    18. doAcquireInterruptibly(arg);
    19. }

    doAcquireInterruptibly()方法与acquireQueue()差别在于方法的返回途径有两种,一种是for循环结束,正常获取到锁;另一种是线程被唤醒后检测到中断请求,则立即抛出中断异常,该操作导致方法结束

    1. // AbstractQueuedSynchronizer.doAcquireInterruptibly()
    2. // 相当于acquireQueued(addWaiter(Node.EXCLUSIVE), arg)),将获取锁失败的线程添加到等待队列并阻塞
    3. private void doAcquireInterruptibly(int arg) throws InterruptedException {
    4. // 为当前线程创建Node线程节点,并将其入队
    5. final Node node = addWaiter(Node.EXCLUSIVE);
    6. // 入队之后,开始对线程进行阻塞
    7. // 阻塞线程是否失败
    8. boolean failed = true;
    9. try {
    10. // 自旋
    11. for (;;) {
    12. // 获取当前节点的前一个节点
    13. final Node p = node.predecessor();
    14. // 如果当前节点是等待队列中的第一个线程节点,则调用tryAcquire()尝试获取锁
    15. if (p == head && tryAcquire(arg)) {
    16. // 尝试获取锁成功,下面就需要将当前节点的node出队
    17. // 将head指针节点指向node,并且将node节点的前驱节点和代表的线程属性都设置为null
    18. setHead(node);
    19. p.next = null; // help GC
    20. // 将阻塞标志设置为false,说明没有阻塞节点线程
    21. failed = false;
    22. // 1.这里没有中断标识,也就没有返回中断标志,而是直接返回结束方法
    23. // lock和lockInterruptibly区别就是对中断的处理方式
    24. return;
    25. }
    26. // shouldParkAfterFailedAcquire:判断线程可否安全阻塞
    27. // parkAndCheckInterrupt:挂起线程并返回当时中断标识Thread.interrupted()
    28. if (shouldParkAfterFailedAcquire(p, node) &&
    29. parkAndCheckInterrupt())
    30. // 2.当parkAndCheckInterrupt返回中断标识为true时立即抛出异常中断线程,而不是和lock()一样记录中断标志,等到获取锁成功之后再响应中断
    31. throw new InterruptedException();
    32. }
    33. // finally的执行一定会在throw new InterruptedException();抛出异常之前执行。finally代码块中的代码不管什么情况下,一定会被执行的
    34. } finally {
    35. /**
    36. * failed标识当前线程的阻塞有没有失败
    37. * doAcquireInterruptibly()最初始把failed设置为true,只有进入到成功获取到锁的分支中,才会将failed设置为false。
    38. * 所以除了成功获取锁return导致try{}执行结束以外,其他任何情况导致try{}执行结束都会使failed仍然等于true,也就是没有成功将线程阻塞过
    39. *
    40. * waitStatus = CANCELLED = 1,表示线程已被取消(等待超时或者被中断),需要废弃结束。
    41. * 说的就是这种情况,当一个线程在doAcquireInterruptibly()方法中因为被中断(响应中断的方法lockInterruptibly()在识别到终端信号之后会直接抛出异常就会将try{}代码块执行结束掉)或等待超时等原因而提前结束,就需要将该线程node节点生命状态设置为CANCELLED
    42. * 在未来该节点的后继节点进入到shouldParkAfterFailedAcquire()方法时,就会将该节点给移出队列
    43. */
    44. // 如果阻塞线程失败了
    45. if (failed)
    46. // 取消获取锁,标注当前节点的生命状态为canceld信号量,这种状态的节点应该剔除
    47. cancelAcquire(node);
    48. }
    49. }

    除以上代码,其他的方法源码都和lock()一致。

    2 lock()

    lock()会先尝试获取锁,失败后再将线程入队并阻塞等待,会在获取锁成功之后调用selfInterrupt()来将线程的中断标志设置true来响应中断:

    1. public final void acquire(int arg) {
    2. if (!tryAcquire(arg) &&
    3. acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
    4. // 获取锁成功后,中断当前线程。默认处理中断方式
    5. selfInterrupt();
    6. }

    addWaiter封装Node节点插入到队列尾部,acquireQueued负责队列的挂起、出队、是否中断。acquireQueued方法只有一种返回途径,就是通过for循正常返回时,必定是成功获取到了锁

    1. final boolean acquireQueued(final Node node, int arg) {
    2. boolean failed = true;
    3. try {
    4. boolean interrupted = false;
    5. for (;;) {
    6. final Node p = node.predecessor();
    7. if (p == head && tryAcquire(arg)) {
    8. setHead(node);
    9. p.next = null; // help GC
    10. failed = false;
    11. // 1.在独占锁后,才返回中断标识
    12. return interrupted;
    13. }
    14. //shouldParkAfterFailedAcquire:判断线程可否安全挂起
    15. //parkAndCheckInterrupt:挂起线程并返回当时中断标识Thread.interrupted()
    16. if (shouldParkAfterFailedAcquire(p, node) &&
    17. parkAndCheckInterrupt())
    18. // 2.当parkAndCheckInterrupt返回中断标识为true时修改interrupted
    19. interrupted = true;
    20. }
    21. } finally {
    22. if (failed)
    23. cancelAcquire(node);
    24. }
    25. }

    3 总结

    ReentrantLock的lockInterruptibly(中断)和lock(非中断加锁模式)的区别在于:线程尝试获取锁操作失败后,在等待过程中,如果该线程被其他线程中断了,它是如何响应中断请求的。lock方法会忽略中断请求,继续获取锁直到成功;而lockInterruptibly则直接抛出中断异常来立即响应中断,由上层调用者处理中断。

    那么,为什么要分为这两种模式呢?这两种加锁方式分别适用于什么场合呢?根据它们的实现语义来理解,lock()适用于锁获取操作不受中断影响的情况,此时可以忽略中断请求正常执行加锁操作,因为该操作仅仅记录了中断状态(通过Thread.currentThread().interrupt()操作,只是恢复了中断状态为true,并没有对中断进行响应)。如果要求被中断线程不能参与锁的竞争操作,则此时应该使用lockInterruptibly方法,一旦检测到中断请求,立即返回不再参与锁的竞争并且取消锁获取操作(即finally中的cancelAcquire操作)


       相关文章: 【并发基础】CAS(Compare And Swap)操作的底层原理以及应用详解
                        【并发基础】AQS(Abstract Queued Synchronizer)框架的使用和实现原理详解
                        【并发编程】Lock接口
                        【并发编程】Condition条件锁源码详解
                        【并发编程】ReentrantLock的lock()方法源码分析

  • 相关阅读:
    AVX图像算法优化系列一: 初步接触AVX。
    Java中的JVM是什么?如何调优JVM的性能?
    mysql使用--分组查询
    不会编程工作室
    SVA断言总结
    数字孪生技术如何提高化工生产安全性?
    【JavaScript】解构
    羚数智能入选 IDC关于中国制造执行系统(MES)的市场2021年度份额报告
    动态规划算法(4)01背包问题
    OFDM 十六讲9 How to Avoid ISI in Digital Communications
  • 原文地址:https://blog.csdn.net/cy973071263/article/details/126126630