AQS底层源码解析-Lock锁源码探究

已于 2023-03-09 16:18:58 修改
阅读量537 收藏
点赞数
分类专栏： JUC 文章标签： jvm juc java 高并发
于 2023-03-06 21:25:47 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_61784000/article/details/129335218
版权

目录

AQS底层源码解析-Lock锁源码探究

ReentrantLock底层原理

 为什么把获取锁失败的线程加入到阻塞队列中，而不是采取其它方法？

总结：三大核心原理

CAS是啥？

代码模拟一个CAS：

 公平锁与非公平锁

可重入锁的应用场景：

AQS底层源码分析[重点，难点]

类图展示：

AQS类属性分析：

AQS类中Node内部节点类：

一：获取锁 lock()

概念：

源码深度剖析：

二：释放锁 unlock()

概念：

源码深度剖析：

三：中断interrupt() 与LockSupport.park()，LockSupport.park(Object obj)的关系【重点】

首先要明白以下三个API：

其次要明白：

提出问题：为什么需要中断方法interrupt()的调用？

代码示例1：原生park()和unpark()的使用

代码示例2：原生park()和unpark() 结合 interrupt相关的API 的使用

代码示例三：在代码示例二的基础上加上一个interrupted方法

重点： LockSupport.park(Object obj)结合AQS底层源码剖析：

得出结论：

四：lockInterruptibly()深度剖析

概念：

源码深度剖析：

总结：lock()与lockInterruptibly()里面中断(interrupt)信号的实际应用场景【重点】

lock()：

lockInterruptibly()：

AQS底层源码解析-Lock锁源码探究

ReentrantLock底层原理

 为什么把获取锁失败的线程加入到阻塞队列中，而不是采取其它方法？

1.sleep休眠不可取：因为获取锁的线程，执行业务多久是不确定的，所以获取锁失败的线程的休眠时间是不确定的。

2.让出CPU资源不可取：让给谁？

3.直接挂起不可取：直接挂起，等于说性能相当于重量级锁，把对未获取锁线程的管理的任务交给了操作系统，操作系统需要进行切换状态(从用户态切换回内核态)，是极其耗费性能的。

所以，我们把未获取锁成功的线程加入到一个阻塞队列中，等到获取锁的线程执行完任务后可以去唤醒这些阻塞的线程。

总结：三大核心原理

自旋，LockSuport，CAS(高并发也可以保证原子性)

【 queue队列存储进入的线程，实现公平锁机制。】

分析：自旋就是一直while循环尝试获取锁。

LockSupport就是阻塞线程与唤醒线程，阻塞是为了降低自旋，以此降低CPU所消耗的性能。

CAS就是在多线程同时操作时，保证操作的原子性，同时一刻只能有一个线程修改主内存的数据成功。

CAS是啥？

代码模拟一个CAS：

/**
 * @Description: TODO
 * @Author: etcEriksen
 * @Date: 2023/3/5
 **/
@SuppressWarnings({"all"})
@Slf4j
public class Juc04_Thread_Cas {

    /**
     * state标识当前加锁状态，记录加锁的次数
     * 默认加锁次数为0
     */
    private volatile int state = 0 ;

    private static CyclicBarrier cyclicBarrier = new CyclicBarrier(5) ;

    private static Juc04_Thread_Cas cas = new Juc04_Thread_Cas() ;

    static class Worker implements Runnable {

        @Override
        public void run() {
            log.info("请求:{}到达预定点,准备开始抢state:)",Thread.currentThread().getName());
            try {
                //阻塞所有的线程到这里，然后一起执行后面的逻辑操作
                cyclicBarrier.await();
                if (cas.compareAndSwapState(0,1)) {
                    log.info("当前请求:{},抢到锁!",Thread.currentThread().getName());
                }else{
                    log.info("当前请求:{},抢锁失败!",Thread.currentThread().getName());
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
        }


    }

    public final boolean compareAndSwapState(int oldValue,int newValue) {
        /**
         * 比较stateOffset的值和oldValue值是否一致，若不一致，那么不可修改 。如果一致，那么修改值为：newValue。
         */
        return unsafe.compareAndSwapInt(this,stateOffset,oldValue,newValue);
    }

    private static final Unsafe unsafe = UnsafeInstance.reflectGetUnsafe();

    private static final long stateOffset;

    static {
        try {
            stateOffset = unsafe.objectFieldOffset(Juc04_Thread_Cas.class.getDeclaredField("state"));
        } catch (Exception e) {
            throw new Error();
        }
    }
}

public class UnsafeInstance {
    public static Unsafe reflectGetUnsafe() {
        try {
            Field field = Unsafe.class.getDeclaredField("theUnsafe");
            field.setAccessible(true);
            return (Unsafe) field.get(null);
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }

    public static void main(String[] args) {
        int j=1;
        reflectGetUnsafe().loadFence();
        int i= 0;
    }
}

 公平锁与非公平锁

t-0正在CAS执行任务逻辑，当执行完的那一刻，t-4正好进入了，那么如果是非公平锁，那么t-4不用到阻塞队列的最后去排队，而是直接去抢t-0线程执行完任务后进行释放的锁对象。如果是公平锁，那么t-4就会进入阻塞队列，老老实实的排到队尾等待。

可重入锁的应用场景：

AQS底层源码分析[重点，难点]

类图展示：

AQS类属性分析：

注释：state为锁的状态器。eg：无锁状态时，state=0。同一线程每成功获取该锁一次，则state+1，同一线程每释放该锁对象一次，则state-1。

exclusiveOwnerThread: 表示当前持有锁对象的线程为谁

head和tail就是在维护一个双端队列，后面该队列用来存储获取锁失败的线程。

AQS类中Node内部节点类：

注释：prev和next：分别表示当前Node节点的前驱和后继节点

waitStatus：Node节点的生命状态，信号量。表示Node节点在不同生命状态下所呈现出的不同性质，有五种，如下：

       SIGNAL = -1 //可被唤醒
        CANCELLED = 1 //代表出现异常，中断引起的，需要废弃结束
        CONDITION = -2 // 条件等待
        PROPAGATE = -3 // 传播
        0 - 初始状态Init状态

thread：由于我们是使用多个Node节点组成一个双端阻塞队列，队列中的每一个元素都是一个Node，每一个Node对应维护一个线程对象，所以我们需要在Node节点类中维护一个Thread类属性：thread 。

一：获取锁 lock()

概念：

这种lock()获取锁对象的方式必须等持有锁对象的线程做完事情，其他等待的线程才可以做事情。而且中途不能退出，会一直阻塞存储在CLH双端队列中。

说详细点就是：当一个节点对象加入到CLH双端阻塞队列中后，在被持有锁对象唤醒之前，它中途就不能退出该队列，即使阻塞队列中节点对应的线程对象被中断，也不可以退出！那么对队列中节点对应线程的中断有啥作用呢？最后的总结lock()和lockInterruptibly()会举例细说

源码深度剖析：

1.

如果锁未被另一个线程持有，则获取锁并立即返回，将锁保持计数设置为 1。
如果当前线程已持有锁，则保留计数将递增 1，并且该方法会立即返回。
如果锁由另一个线程持有，则当前线程将出于线程调度目的而被禁用，并处于休眠状态，直到获取锁为止，此时锁保持计数设置为 1。

2.

 3.

4.

接下来会详细分析tryAcquire和acquireQueued这两个方法：

 tryAcquire方法解析：

tryAcquire方法中调用的hasQueuePredecessors方法的解析：

acquireQueued方法解析：

acquireQueued调用的addWaiter方法解析：

addWaiter调用的enq()方法解析：

 提出一个疑问和思考：

当队列初始化完毕时，为什么在addWaiter方法中已经做了插入新Node到队列中的操作，然而又在addWaiter调用的enq方法中又重复做了一次插入新Node节点到队列中的操作呢？？？

答案：因为并发多线程环境！

acquireQueued方法解析：

acquireQueued方法调用的shouldParkAfterFailedAcquire方法解析:

acquireQueued方法调用的parkAndCheckInterrupt方法解析：

为什么要把第一个真实节点的状态设置在虚拟头节点的waitStatus上？为什么不设计在自己节点所维护的waitStatus呢？

首先你应该明白一个点：我们是公平锁，所谓公平锁就是先来的先可以获取到锁对象，后来的只能在后面排队等。

所以我们构建出了一个有序的阻塞队列，后来的线程插在最后面，第一个真实节点(虚拟节点的下一个节点)就是下一次锁对象的持有者。

当锁对象释放后，每次都是把锁对象分配给第一个真实节点(即虚拟头节点的下一个节点)，这就是保证了公平。

第一个真实节点获取到锁对象后，会转变为虚拟头节点(此时waitStatus==0)，原来的虚拟头节点会被GC回收掉。此时只需把新虚拟节点的waitStatus改为-1即可，因为waitStatus维护的是Node节点的性质，所以最好维护在虚拟头节点。

为什么要费尽心思搞出一个waitStatus并且设置为-1？

因为waitStatus==-1就是代表一个Node节点的状态量，代表的是可以进行被唤醒，那么在释放锁的时候，我们只需进行检验该waitStatus是否为-1，为-1，那么才可以去释放锁 才可以去唤醒该线程对应的Node节点。

二：释放锁 unlock()

概念：

就是当前锁持有者对应的线程执行锁对象的释放并且通知唤醒阻塞队列中的第一个真实节点对应的线程对象(即虚拟头节点Head的下一个节点)。

在公平锁的实现下，释放的锁对象肯定是被排在阻塞队列中的第一个节点对应的线程获取。但是在非公平锁的实现下，释放的锁对象可能会被刚刚进入的线程竞争获取到，导致阻塞队列第一个节点对应的线程对象获取锁对象失败。

源码深度剖析：

1.

2.

3.release方法解析：

release方法调用的tryRelease方法解析：

release方法调用的unparkSuccessor方法解析：

unparkSuccessor方法执行唤醒线程的操作后，会唤醒加锁过程中调用的parkAndCheckInterrupt方法中阻塞的线程：

parkAndCheckInterrupt阻塞的线程被唤醒后，说明parkAndCheckInterrupt阻塞完毕 即执行完毕，那么再一次循环向上，如图分析：

为什么要在 unparkSuccessor 方法中把Head虚拟头节点的waitStatus从-1改为0？？

其实也说的很清楚了。

重复一遍释放锁唤醒线程的逻辑：t1线程执行完业务后进行释放锁并且通知唤醒阻塞队列中阻塞着的t2线程，在唤醒之前，需要把阻塞队列虚拟头节点Head的waitStatus由-1改为0。

但是在非公平锁的情况下，可能阻塞队列的第一个Node对应的t2线程在获取锁的时候 有其它线程进入跟它竞争锁，可能t2线程获取锁失败。获取锁成功，那好说。

如果t2线程获取锁失败，t2线程会进行两次循环【第二次循环是逻辑关键，阻塞前最后一次尝试获取锁，若成功那么就无需阻塞啦，极大的节省性能】：

第一次循环：由于t2线程获取锁失败，那么执行的acquireQueued方法中执行调用tryAcquire方法返回false。t2线程会再一次进入到shouldParkAfterFailedAcquire方法中，由于Head的waitStatus被t1线程在释放锁的时候改为了0，所以shouldParkAfterFailedAcquire方法中会执行逻辑把waitStatus改为-1，并且返回false。

第二次循环：会在阻塞前再一次的进行尝试获取锁(tryAcquire)，因为阻塞是重型操作，需要切换状态，所以阻塞之前再一次进行尝试获取锁(做最后一次尝试)，如果获取锁还是失败，那么就进行阻塞，循环结束。

假设说，t1线程释放锁后，在唤醒t2之前，不把阻塞队列虚拟头节点Head的waitStatus由-1改为0。那么t2线程只会进行一次循环，那么就不可能完成"阻塞前最后一次tryAcquire尝试获取锁"的功能啦

三：中断interrupt() 与LockSupport.park()，LockSupport.park(Object obj)的关系【重点】

对于第三点，我们依旧结合AQS底层源码进行分析，前面一(获取锁)和二(释放锁)这两大方面分别代表了AQS源码的逻辑主线，第三点算是对前面两点中涉及到interrupt中断源码的分析与补充。

首先要明白以下三个API：

1.Thread.currentThread().interrupt()，表示为当前线程打一个中断标记，中断当前线程。

2.Thread.interrupted()，表示清除中断标记，如果当前线程被中断了，返回true。否则返回false

3.Thread.currentThread().isInterrupted()表示查看当前线程的状态是否中断，不清除中断标记

其次要明白：

对于AQS底层，我们调用unlock()方法的底层就是调用LockSupport.park(Object obj)的，

LockSupport.park()与LockSupport.park(Object obj)这两个方法还有所不同的。

LockSupport.park()方法：在执行park()方法之前先进行检验当前线程t1是否有中断标识，如果没有，那么标识着当前t1线程要被阻塞住，不能向下执行。

所谓中断标识就是：如果在其它线程中执行t1.interrupt()中断阻塞着的park方法，那么就会给当前线程t1分配一个中断标识，就会停止阻塞，向下继续执行。

但是当我们执行Thread.currentThread().interrupted()后就会消除该中断标识，那么当下一次park()执行前进行检验中断标识时 ，发现没有！那么就会继续阻塞住。

LockSupport.park(Object obj)方法：它与LockSupport.park()方法相同，obj标识阻塞等待的对象

提出问题：为什么需要中断方法interrupt()的调用？

分析：

interrupt方法为中断线程的方法api，可以中断线程的阻塞。即是中断LockSupport.park()对线程的阻塞，也可以中断Lock.park(Object obj)对线程的阻塞。

之前是如何中断线程的？使用的是底层的stop方法，就好比linux系统下的kill -9 操作，无论是jdk提供的stop还是linux的kill，都是极其的暴力的，会立刻杀死当前线程(线程是进程的组成部分)，假设业务执行一半被强制杀死了，那么就是十分危险的。

所以我们寻求一种柔和的中断方式，可以给我们判断的机会来自定义何时进行退出，以此保证业务的安全退出与执行，因此引出interrupt方法+isInterrupted方法来保证自定义退出逻辑：

首先：使用interrupt()方法进行中断阻塞后，会给中断阻塞的线程一个中断标识，标识该线程已经中断啦。

然后：我们就可以结合Thread.currentThread().isInterrupted()方法进行查看当前线程是否已经中断，如果别处已经把该线程中断(即调用interrupt()方法)，那么我们就要执行退出。如果判断出该线程未中断，那么继续执行业务。

代码示例1：原生park()和unpark()的使用

/**
 * @Description: TODO
 * @Author: etcEriksen
 * @Date: 2023/3/6
 **/
@SuppressWarnings({"all"})
@Slf4j
public class demo2 {


    public static void main(String[] args) {

        Thread t1 = new Thread(() -> {
            while (true) {
                log.info("开始阻塞");
                LockSupport.park();
                log.info("阻塞结束");
                
                log.info("若不中断，unpark执行完，那么执行业务逻辑");
            }
        });
        t1.start();

        try {
            Thread.sleep(2000);
            log.info("中断线程");
            
            LockSupport.unpark(t1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        log.info("main线程执行结束");
    }


}

代码分析：

 比对运行结果，与分析一致：

代码示例2：原生park()和unpark() 结合 interrupt相关的API 的使用

记住两个点：

(1) interrupt()方法是给线程一个标记：你这个线程已经被附上一个阻断标识了啊，你再park()阻塞也没用，不会阻塞的哈！

(2) interrupt()进行中断后，会给线程做一个中断标识，我们可以调用isInterrupted这个方法去自定义自己的逻辑：中断后去做啥逻辑，退出？还是执行其它业务？这些都由你自己决定！再一次验证了前面的结论：这是一个自定义的，是柔和的中断。

/**
 * @Description: TODO
 * @Author: etcEriksen
 * @Date: 2023/3/6
 **/
@SuppressWarnings({"all"})
@Slf4j
public class demo2 {


    public static void main(String[] args) {

        Thread t1 = new Thread(() -> {
            while (true) {
                log.info("开始阻塞");
                LockSupport.park();
                log.info("阻塞结束");
                if (Thread.currentThread().isInterrupted()) {
                    //再一次执行park()是为了表明：只要该线程被标识了中断标记，那么park()执行多少次也不会阻塞的！
                    LockSupport.park();
                    log.info("中断退出，不执行后面的业务逻辑");
                }
                log.info("若不中断，unpark执行完，那么执行业务逻辑");
            }
        });
        t1.start();

        try {
            Thread.sleep(2000);
            log.info("中断线程");
            t1.interrupt();
            //LockSupport.unpark(t1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        log.info("main线程执行结束");
    }


}

代码分析：

 代码运行结果：一直死循环打印输出，没有尽头

17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 若不中断，unpark执行完，那么执行业务逻辑
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 开始阻塞
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 阻塞结束
17:19:15.853 [Thread-0] INFO com.messi.leo.AQS.lock.demo2 - 中断退出，不执行后面的业务逻辑

 

代码示例三：在代码示例二的基础上加上一个interrupted方法
 

记住一个点：
 

interrupted方法就是消除当前调用方法的线程对象的中断标识。那么当线程的中断标识被消除成功时，我们再一次park()，线程就会被阻塞掉
 

返回值为布尔类型，若当前线程有中断标识，那么返回true。否则返回false
 

代码演示：
 

/**
 * @Description: TODO
 * @Author: etcEriksen
 * @Date: 2023/3/6
 **/
@SuppressWarnings({"all"})
@Slf4j
public class demo2 {


    public static void main(String[] args) {

        Thread t1 = new Thread(() -> {
            while (true) {
                log.info("开始阻塞");
                LockSupport.park();
                log.info("阻塞结束");
                if (Thread.currentThread().isInterrupted()) {
                    boolean isInterrupted = Thread.currentThread().interrupted();
                    if (isInterrupted) {
                        log.info("线程的中断标识被消除成功，再一次park()执行时 线程就会被阻塞掉");
                    }
                  
                    LockSupport.park();
                    log.info("中断退出，不执行后面的业务逻辑");
                }
                log.info("若不中断，unpark执行完，那么执行业务逻辑");
            }
        });
        t1.start();

        try {
            Thread.sleep(2000);
            log.info("中断线程");
            t1.interrupt();
            //LockSupport.unpark(t1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        log.info("main线程执行结束");
    }


}
 

代码分析：
 

 

 代码输出：
 

 

重点： LockSupport.park(Object obj)结合AQS底层源码剖析：
 

ReentrantLock类对应的加锁流程：
 

1.
 

 

2.
 

 

 3.
 

 

4.
 

 

 

 5.
 

 

 
 

6.
 

 

 

 7.
 

 

ReentrantLock类对应的释放锁流程：
 

1.
 

 

2.
 

 

 
 

 

 

得出结论：
 

unpark和interrupt方法都可以进行停止park方法的线程阻塞。
 

但是interrupt不同之处在于，它给线程对象分配了一个中断标识，当下一次进行park时判断出当前线程对象存在该中断标识，那么就不会park阻塞！！！因此我们可以使用interrupted方法进行消除线程对象的中断标识！
 

四：lockInterruptibly()深度剖析
 

概念：
 

lockInterruptibly()方法和lock方法一致，也必须是等待持有锁对象的线程做完事情，其他线程才能做事情，但中途可以进行退出。
 

说详细点就是：当节点(线程封装在节点中)加入到阻塞队列中后，若线程执行interrupt中断方法，会抛出中断异常，中途会从阻塞队列中进行退出，表示获取锁失败，waitStatus标记为1，表示出现异常导致退出！
 

源码深度剖析：
 

1.
 

 

 2.
 

 

 3.
 

 

4.
 

 

doAcquireInterruptibly方法调用的shouldParkAfterFailedAcquire方法解析：与lock()底层的shouldParkAfterFailedAcquire方法一致，不再详细赘述
 

 

doAcquireInterruptibly方法调用的 parkAndCheckInterrupt方法 解析：
 

 

5.
 

 

6.cacelAcquire方法解析：
 

 

 至于这个方法的具体实现，总结一句话就是对阻塞队列中出现异常的节点要进行从阻塞队列中移除，并且抛出中断异常，并且要进行修改节点对应waitStatus的值。具体怎么实现的，画一张图，一步步对照着走即可，easy！
 

 

 

总结：lock()与lockInterruptibly()里面中断(interrupt)信号的实际应用场景【重点】
 

lock()：
 

概念回顾
 

这种lock()获取锁对象的方式必须等持有锁对象的线程做完事情，其他等待的线程才可以做事情。而且中途不能退出，会一直阻塞存储在CLH双端队列中。
 

说详细点就是：当一个节点对象加入到CLH双端阻塞队列中后，在被持有锁对象唤醒之前，它中途就不能退出该队列，即使阻塞队列中节点对应的线程对象被中断，也不可以退出！
 

lockI()底层的CLH阻塞队列中Node节点对应的线程对应的中断信号有啥用？
 

实际案例证明:还是追源码，中间省略了很多easy代码，只保留了关键处
 

 

 

 

 selfInterrupt方法对当前线程的中断有啥用？我在搞笑吗？？？
 

回到API调用的应用层：
 

如下图：画红圈就是作用，我们可以跳过interrupted()方法得到中断的信号去自定义业务逻辑！！！！很重要的一个点！
 

 

lockInterruptibly()：
 

概念回顾：
 

方法和lock方法一致，也必须是等待持有锁对象的线程做完事情，其他线程才能做事情，但中途可以进行退出。
 

说详细点就是：当节点(线程封装在节点中)加入到阻塞队列中后，若线程执行interrupt中断方法，会抛出中断异常，中途会从阻塞队列中进行退出，表示获取锁失败，waitStatus标记为1，表示出现异常导致退出！
 

lockInterruptibly()底层的CLH阻塞队列中Node节点对应的线程对应的中断信号有啥用？
 

实际案例证明:还是追源码，中间省略了很多easy代码，只保留了关键处：
 

 

 
 

 回到API调用的应用层：
 

 

 

 

 

初次学习AQS底层源码，可能理解不深刻。若有不对，期待指正。
 

 

 

 

 


                

        

        

    




    

      

        

            

              
                
                  etcEriksen
                
              
            

            

                关注
              
            

        

        

          
    
            
  • 
              
                
                
                
                
                      0
                
              
              
    点赞
    
            
    • 
            
  • 
              
                
                
                
              
              
    踩
    
            
    • 
            
  • 
              
                
                
                
                
                    0
                
              
              
    
                
    
                  
                    收藏
                  
                
    
              
    
              
    
                
    
                  觉得还不错?
                  
                    一键收藏
                  
                 
                
    
              
    
            
    • 
          
  • 
            
    
              
              
            
    
              
              
              
                    0
              
            
            
    评论
    
          
    • 
          
  • 
          
    • 
          
  • 
            
              
            
              
    
            
              
                
            
    
          
    • 
        

      

      

            

                专栏目录
          










                



	

		

			

				
					
带你看看Java-AQS同步器 源码解读四 条件队列Condition上

				
			

			

				

					12-21
				

			

		

		

			
				
Java-AQS同步器 源码解读-条件队列Condition前文为什么需要条件队列Conditon Queue举个小例子分析怎么使用条件队列写个小DemoJDK中是怎么使用的Lock和ConditionLockConditionSync-Queue和Conditian-QueueAQS Condition的实现条件队列-await源码分析条件队列-signal源码分析总结
Java-AQS同步器 源码解读1-独占锁加锁
Java-AQS同步器 源码解读2-独占锁解锁
Java-AQS同步器 源码解读3-共享锁
Java-AQS同步器 源码解读4-条件队列上
前文
AQS的源码分析已经写了篇了，

			
		

	



                

              
                



	

		

			

				
					
Java并发 结合源码分析AQS原理

				
			

			

				

					08-25
				

			

		

		

			
				
主要介绍了Java并发 结合源码分析AQS原理,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下

			
		

	



                


  
              

                


	

		

			

				
					
深入分析AQS原理-王雷-v1.pptx

				
			

			

				

					08-11
				

			

		

		

			
				
深入分析AQS原理-王雷-v1.pptx

			
		

	





	

		

			

				
					
AQS源码分析 (1).pdf

				
			

			

				

					01-22
				

			

		

		

			
				
java锁底层实现，AQS源码分析。我在公司内部分享写的，如果想进一步了解，可以私聊

			
		

	



		

			
		



	

		

			

				
					
JUC(一)-AQS源码分析

				
			

			

				

					01-21
				

			

		

		

			
				
AQS源码分析一、锁的介绍1.1 乐观锁/悲观锁1.2 共享锁/独占锁1.3 公平锁/非公平锁1.4 小结二、AQS框架结构介绍2.1 类图2.2 AQS数据结构三、源码详解3.1 acquire源码详解3.2 release源码详解四、从ReentranLock看公平锁和非公平锁的实现区别4.1 公平锁4.2 非公平锁4.3 小结五、实战
为了学习JUC，AQS是基础中的基础，所以我们首先深入了解下AQS。
一、锁的介绍
为了了解AQS的源码，我们需要先大概下锁中的一些功能
1.1 乐观锁/悲观锁
乐观锁与悲观锁是一种广义上的概念，体现了看待线程同步的不同角度，在java和数据库中都有应用。

			
		

	





	

		

			

				
					
JUC中的AQS底层详细超详解

				
			

			

				

					华为云官方博客
				

				

					10-25
					
					779
					
				

			

		

		

			
				
当你使用java实现一个线程同步的对象时，一定会包含一个问题：你该如何保证多个线程访问该对象时，正确地进行阻塞等待，正确地被唤醒？

			
		

	





	

		

			

				
					
ReentrantLock的lock(), tryLock(), tryLock(long timeout, TimeUnit unit), lockInterruptibly() 及使用场景示例

					
热门推荐

				
			

			

				

					michaelgo的博客
				

				

					08-07
					
					2万+
					
				

			

		

		

			
				
一直在用concurrent包里的东西，最近想研究一下个中细节，先从ReentrantLock提供的集中获取锁的方式开始吧。

1.ReentrantLock简要介绍

简单介绍一下ReentrantLock，可重入锁，互斥锁，提供了fair和unfair两种模式的锁。默认构造函数是unfair的锁，如果初始化时传入true的参数则会返回fair锁。所谓不公平就是在锁可获取时，不用考虑该锁队列是否...

			
		

	





	

		

			

				
					
tryLock尝试获取锁

				
			

			

				

					Leon_Jinhai_Sun的博客
				

				

					05-16
					
					1400
					
				

			

		

		

			
				
package lock.lock;

import java.util.Random;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

/**
 * 描述：     用tryLock来避免死锁
 */
p.

			
		

	





	

		

			

				
					
Java JUC 2 -AQS

				
			

			

				

					phn555的博客
				

				

					08-31
					
					363
					
				

			

		

		

			
				
AQS


理解AQS
AbstractQueuedSynchronizer，它提供了一种实现阻塞锁和一系列依赖FIFO等待队列的同步器的框架，ReentrantLock、Semaphore、CountDownLatch、CyclicBarrier等并发类均是基于AQS来实现的，具体用法是通过继承AQS实现其模板方法，然后将子类作为同步组件的内部类。


AQS基本框架如下图所示：

AQS维护了一个volatile的共享变量state和一个FIFO线程等待队列。当state>0时表示已经获取了锁，当

			
		

	





	

		

			

				
					
Java高并发(五)——Lock优化，提高性能

				
			

			

				

					学会改变自己——才能突破
				

				

					12-06
					
					3115
					
				

			

		

		

			
				
       前边我们讲了，多线程的世界，多线程的基础操作，多线程协作，多线程管理——线程池。其中多线程为什么麻烦，就因为线程并行操作，对共享资源的争夺，会出现线程安全问题。而我们解决线程安全问题的方案是同步（锁资源，串行使用），串行就会出现性能问题。举个例子：大家在大道上并行前进的几列人（多线程并发），突然遇到河流，只有一个独木桥，大家只能一个个过（锁共享资源，串行使用）。显而易见，时间更多的消...

			
		

	





	

		

			

				
					
lock ，tryLock  lockInterruptibly 区别

				
			

			

				

					浩子的博客
				

				

					03-29
					
					1917
					
				

			

		

		

			
				
ReentrantLock 锁有好几种，除了常用的lock ，tryLock ，其中有个lockInterruptibly 。
先把API粘贴上来

lock
public void lock()
获取锁。
如果该锁没有被另一个线程保持，则获取该锁并立即返回，将锁的保持计数设置为 1。
如果当前线程已经保持该锁，则将保持计数加 1，并且该方法立即返回。
如果该锁被另一个线程保持，则出于线程调

			
		

	





	

		

			

				
					
AQS(AbstractQueuedSynchronizer)源码深度解析(2)—Lock接口以及自定义锁的实现

				
			

			

				

					终生学习践行者
				

				

					09-03
					
					2273
					
				

			

		

		

			
				
Lock接口的介绍以及自定义锁的实现。

			
		

	





	

		

			

				
					
Java高并发编程实战6，通过AQS源码分析lock()锁机制

				
			

			

				

					学Java，找哪吒
				

				

					10-11
					
					4641
					
				

			

		

		

			
				
Java高并发编程实战系列，打造精品专栏。

			
		

	





	

		

			

				
					
AQS源码解析2.内部核心结构与lock过程

				
			

			

				

					KKK
				

				

					12-02
					
					272
					
				

			

		

		

			
				
AQS内部核心结构与lock过程

			
		

	





	

		

			

				
					
AQS源码解析 3.lock() & unlock() 加锁解锁过程

				
			

			

				

					How many ten years in the life time?
				

				

					11-22
					
					598
					
				

			

		

		

			
				
AQS 是 Java 中几乎所有锁和同步器的一个基础框架，这里说的是“几乎”，因为有极个别确实没有通过 AQS 来实现；AQS 是结合 ReentrantLock 一起看的，因为里面的公平锁和非公平锁，是使用 AQS 的实现；AQS 中维护了一个队列，这个队列使用双链表实现，用于保存等待锁排队的线程；AQS 中维护了一个状态变量 state，在多线程并发场景下，通过控制状态变量 state 就可以实现加锁解锁操作了；判断当前持有锁的线程是否已经释放了锁，使得没有拿到锁的线程进入队列等待。

			
		

	





	

		

			

				
					
lockInterruptibly 和lock的区别

				
			

			

				

					yixiao3660的专栏
				

				

					05-23
					
					329
					
				

			

		

		

			
				
lockInterruptibly 与 lock比较区别在于 
lockInterruptibly 优先考虑响应中断，而不是响应锁定的普通获取或重入获取 



Java代码  



package test;  
  
import java.util.concurrent.TimeUnit;  
import java.util.concurrent.locks.Lo

			
		

	





	

		

			

				
					
java线程安全队列以及lock、tryLock和lockInterruptibly的差別

				
			

			

				

					赶路人儿
				

				

					05-24
					
					2190
					
				

			

		

		

			
				
Java提供的线程安全的Queue可以分为阻塞队列和非阻塞队列，其中阻塞队列的典型例子是BlockingQueue，非阻塞队列的典型例子是ConcurrentLinkedQueue，在实际应用中要根据实际需要选用阻塞队列或者非阻塞队列。线程安全就是说多线程访问同一代码，不会产生不确定的结果。1、BlockingQueue提供的常用方法： 可能报异常返回布尔值可能阻塞设定等待时间 入队add(e)o...

			
		

	





	

		

			

				
					
JAVA多线程高并发之ReentrantLock讲解lockInterruptibly方法

				
			

			

				

					饶艳辉
				

				

					08-10
					
					1306
					
				

			

		

		

			
				
JAVA中多线程高并发场景下保证线程安全通常都会考虑加锁。但是在特殊场景下我们也可以采用java.util.concurrent包提供的线程安全的对象，避免加锁从而达到高效的目的。

但是，这些线程安全的对象仅仅指的是针对于原子性操作是线程安全的，如果多个方法同时调用无法保证线程安全，只能考虑加锁。这里我们举个列子：假设我们在多线程高并发场景下使用java.util.concurrent.Conc...

			
		

	





	

		

			

				
					
Java中Lock，tryLock，lockInterruptibly区别和使用，及synchronized关键字

				
			

			

				

					qq_25100219的博客
				

				

					05-02
					
					413
					
				

			

		

		

			
				
首先，讲讲synchronized关键字，java的内置特性。在java中synchronized作为关键字可以修饰代码块或者方法，当使用它修饰代码块或者方法时，表示被修饰的代码块或者方法，同一时刻只能被一个线程执行或调用，其他线程会处于等待状态，当占用锁的进程执行完成后，jvm会自动释放锁及线程执行所分配的线程空间，这时其他线程才可以继续获取锁。

例如：

同时起两个线程A和B，run方法中的...

			
		

	





	

		

			

				
					
通过aqs源码分析lock()锁机制

					
最新发布

				
			

			

				

					05-02
				

			

		

		

			
				
Java中的AQS（AbstractQueuedSynchronizer）是实现锁和同步器的一种重要工具。在AQS中，一个节点表示一个线程，依次排列在一个双向队列中，同时使用CAS原子操作来保证线程安全。当多个线程对于同一资源竞争时，一个...

			
		

	



              



  
“相关推荐”对你有帮助么？

  

      
    
          
  • 
              
    
                  
                  
              
    
              
    非常没帮助
    
          
    • 
          
  • 
              
    
                  
                  
              
    
              
    没帮助
    
          
    • 
          
  • 
              
    
                  
                  
              
    
              
    一般
    
          
    • 
          
  • 
              
    
                  
                  
              
    
              
    有帮助
    
          
    • 
          
  • 
              
    
                  
                  
              
    
              
    非常有帮助
    
          
    • 
      

      

      

          
          提交
      

      

  




          




        



    





    



      

      

        
      

      





	

		评论	
	

	
	




  

    

      添加红包
      
    

    

      

        
        

          
          
        

        
请填写红包祝福语或标题

      

      

        
        

          
          个
        

        
红包个数最小为10个

      

      

        
        

          
          元
        

        
红包金额最低5元

      

      

        
        

          当前余额3.43元
          前往充值 >
        

      

      

        

          需支付：10.00元
        

        
        
      

    

  





  

    
    
  

  

    
    
  








  

    

      

        

          

            
            
成就一亿技术人!

          

          

        

        

          

          

            领取后你会自动成为博主和红包主的粉丝
            规则
          

        

      

      

        

          

            
              
            
            

              
hope_wisdom
 发出的红包
            

          

        

        

          

          

          

        

      

    

    

  



      
      

      
实付元

      
使用余额支付

      

        

          

            
            点击重新获取
          

        

        
扫码支付

      

      

        
          
            
          
          
        
      

      

        
        钱包余额
          0
          

            
            

              

                
抵扣说明：

                
 1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

              

            

          

      

      余额充值