《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile

已于 2022-07-13 19:19:16 修改
阅读量371 收藏 3
点赞数 7
分类专栏： JUC并发编程 文章标签： java 并发
于 2022-06-13 16:22:08 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/LXYDSF/article/details/125262286
版权

📒博客首页：热爱编程的大李子 📒

🌞文章目的：《JUC并发编程 - 原理篇》Monitor 原理 | synchronized 原理 🌞

🍄参考视频：深入学习Java并发编程🍄

🙏博主在学习阶段，如若发现问题，请告知，非常感谢🙏

💙同时也非常感谢各位小伙伴们的支持💙

🌈每日一语：未经一番寒彻骨，哪得梅花扑鼻香！🌈

💗感谢： 我只是站在巨人们的肩膀上整理本篇文章，感谢走在前路的大佬们💗

🌟最后，祝大家每天进步亿点点！ 欢迎大家点赞👍➕收藏⭐️➕评论💬支持博主🤞！🌟

在这里插入图片描述

文章目录

一、Monitor 原理

Monitor 被翻译为监视器或管程
每个 Java 对象都可以关联一个 Monitor 对象（可以将Monitor对象看成锁对象），如果使用 synchronized 给对象上锁（重量级）之后，该对象头的Mark Word 中就被设置指向 Monitor 对象的指针。如图所示：

image-20220613113145843

多线程执行时，Monitor 结构变化如下：

image-20220613103851025

  • 刚开始 Monitor 中 Owner（主人） 为 null
  • 当 Thread-2 执行 synchronized(obj) 就会将 Monitor 的所有者 Owner 置为 Thread-2，Monitor中只能有一个 Owner
  • 在 Thread-2 上锁的过程中，如果 Thread-3，Thread-4，Thread-5 也来执行 synchronized(obj)，就会进入EntryList (阻塞/等待队列) , 线程状态变为 BLOCKED. (执行synchronized(obj)前,会先检查monitor是否有owner,如果有了,则该线程进入EntryList)
  • Thread-2 执行完同步代码块的内容，然后唤醒 EntryList 中等待的线程来竞争锁，竞争的时是非公平的
  • 图中 WaitSet 中的 Thread-0，Thread-1 是之前获得过锁，但条件不满足进入 WAITING 状态的线程，后面讲wait-notify 时会分析

注意：

  • synchronized 必须是进入同一个对象的 monitor 才有上述的效果
  • 不加 synchronized 的对象不会关联监视器，不遵从以上规则

二、synchronized 原理(字节码角度)

static final Object lock = new Object();
static int counter = 0;

public static void main(String[] args) {
    synchronized (lock) {
        counter++;
    }
}

对应的字节码为：

public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
        stack=2, locals=3, args_size=1
        0: getstatic #2 //获得lock引用 （synchronized开始）; 
        3: dup          // 将lock引用复制一份
        4: astore_1 // lock引用 -> slot 1; 将lock引用赋给 局部变量表的slot[1]
        5: monitorenter // 将 lock对象 MarkWord 置为 Monitor 指针
        //以下四行是counter++的操作;
        6: getstatic #3 //  获取counter的值
        9: iconst_1 // 准备常数 ,保存counter
       10: iadd //  常数进行+1
       11: putstatic #3 // 将常数写回counter中
       14: aload_1 // 获得lock引用,进行解锁
       15: monitorexit // 将 lock对象的 MarkWord 重置, 唤醒 EntryList (退出Monitor)
       16: goto 24 // 跳转到24 退出
       19: astore_2 // e -> slot 2  将异常对象保存到slot[2]中
       20: aload_1 // 获得lock引用,进行解锁
       21: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList(退出Monitor)
       22: aload_2 // <- slot 2 (e)  加载异常对象
       23: athrow // throw e  抛出异常
       24: return //退出程序
    Exception table:
        from    to    target    type
          6     16      19       any //静态代码块内部的区域,可能抛出异常
         19     22 		19 		 any
    LineNumberTable:
      line 8: 0
      line 9: 6
      line 10: 14
      line 11: 24
    LocalVariableTable:
        Start   Length   Slot   Name   Signature
          0       25       0    args   [Ljava/lang/String;
    StackMapTable: number_of_entries = 2
      frame_type = 255 /* full_frame */
        offset_delta = 19
        locals = [ class "[Ljava/lang/String;", class java/lang/Object ]
        stack = [ class java/lang/Throwable ]
      frame_type = 250 /* chop */
        offset_delta = 4

可以看出，无论是否出现异常，都会进行解锁操作，不会出现死锁现象

**注意：**方法级别的 synchronized 不会在字节码指令中有所体现

三、synchronized 原理进阶

0. 小故事

  • 故事角色
  • 老王 - JVM
  • 小南 - 线程
  • 小女 - 线程
  • 房间 - 对象
  • 房间门上 - 防盗锁 - Monitor
  • 房间门上 - 小南书包 - 轻量级锁
  • 房间门上 - 刻上小南大名 - 偏向锁
  • 批量重刻名 - 一个类的偏向锁撤销到达 20 阈值
  • 不能刻名字 - 批量撤销该类对象的偏向锁，设置该类不可偏向

小南要使用房间保证计算不被其它人干扰（原子性），最初，他用的是防盗锁（Monitor），当上下文切换时，锁住门。这样，即使他离开了，别人也进不了门，他的工作就是安全的。— 重量级锁

但是，很多情况下没人跟他来竞争房间的使用权。小女是要用房间，但使用的时间上是错开的，小南白天用，小女晚上用。每次上锁太麻烦了，有没有更简单的办法呢？— 挂书包（轻量级锁）

小南和小女商量了一下，约定不锁门了，而是谁用房间，谁把自己的书包挂在门口，但他们的书包样式都一样，因此每次进门前得翻翻书包，看课本是谁的，如果是自己的，那么就可以进门，这样省的上锁解锁了。万一书包不是自己的，那么就在门外等，并通知对方下次用锁门的方式（存在竞争时，锁升级，轻量级 --> 重量级）。

后来，小女回老家了，很长一段时间都不会用这个房间。小南每次还是挂书包，翻书包，虽然比锁门省事了，但仍然觉得麻烦。

于是，小南干脆在门上刻上了自己的名字：【小南专属房间，其它人勿用】，（偏向锁）下次来用房间时，只要名字还在，那么说明没人打扰，还是可以安全地使用房间。如果这期间有其它人要用这个房间，那么由使用者将小南刻的名字擦掉，升级为挂书包的方式。（存在竞争时，锁升级，偏向锁 --> 轻量级锁）

同学们都放假回老家了，小南就膨胀了，在 20 个房间刻上了自己的名字，想进哪个进哪个。后来他自己放假回老家了，这时小女回来了（她也要用这些房间），结果就是得一个个地擦掉小南刻的名字，升级为挂书包的方式。老王(JVM)觉得这成本有点高，提出了一种批量重刻名的方法，他让小女不用挂书包了，可以直接在门上刻上自己的名字(批量重偏向)

后来，刻名的现象越来越频繁，老王受不了了：算了，这些房间都不能刻名了，只能挂书包(不可偏向)

1. 轻量级锁

==轻量级锁的使用场景：==如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化。 (如果后续加锁失败了，则换用 重量级锁加锁)

轻量级锁对使用者是透明的，即语法仍然是 synchronized

假设有两个方法同步块，利用同一个对象加锁

static final Object obj = new Object();

public static void method1() {
    synchronized( obj ) {
        // 同步块 A
        method2();
    }
}

public static void method2() {
    synchronized( obj ) {
    // 同步块 B
    }
}
  • 创建锁记录（Lock Record）对象，每个线程的栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的MarkWord (对应着lock recode)

image-20220613130714560

  • 让锁记录中 Object reference 指向锁对象，并尝试用 cas（反转替换操作） 替换 Object 的 Mark Word，将 Mark Word 的值存入锁记录

image-20220613130928573

  • 如果 cas 替换成功，对象头中存储了锁记录地址和状态 00 ，表示由该线程给对象加锁，这时图示如下

image-20220613131155477

  • 如果 cas 失败，有两种情况
    • 如果是其它线程已经持有了该 Object 的轻量级锁（锁对象对应着 00 ），这时表明有竞争，进入锁膨胀过程
    • 如果是自己执行了 synchronized 锁重入，那么再添加一条 Lock Record 作为重入的计数 （Lock Record有几个，对应着有几层锁）。例：上面代码中method1中调用method2

image-20220613131246399

  • 当退出 synchronized 代码块（解锁时）如果有取值为 null 的锁记录，表示有重入，这时重置锁记录，表示重入计数减一

image-20220613131435645

  • 当退出 synchronized 代码块（解锁时）锁记录的值不为 null，这时使用 cas 将 Mark Word 的值恢复给对象头
    • 成功，则解锁成功
    • 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

2. 锁膨胀

如果在尝试加轻量级锁的过程中，CAS 操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。

static Object obj = new Object();

public static void method1() {
    synchronized( obj ) {
    // 同步块
    }
}
  • 当Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁

image-20220613133929431

  • 这时 Thread-1 加轻量级锁失败，进入锁膨胀流程
    • 即为 Object 对象申请 Monitor 锁，让 Object 指向重量级锁地址
    • 然后自己进入 Monitor 的 EntryList ，状态变为BLOCKED

image-20220613133954298

**注意：**因为线程优先是加轻量级锁的，但是锁对象已经被Thread-0 加上了轻量级锁，Thread-1 再次加锁失败。轻量级锁没有等待序列，所以进入锁膨胀，创建重量级锁，Thread-1 进入等待序列。

  • 当 Thread-0 退出同步块解锁时，使用 cas 将 Mark Word 的值恢复给对象头，失败 ( 因为锁对象此时加的是重量级锁)。这时会进入重量级解锁流程，即按照 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 的 BLOCKED 线程。让这些线程进行非公平竞争。

3. 自旋优化

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。

优点：子旋优化 不会马上让当前线程进入等待状态，而是进行自旋重试操作，如果自旋成功，就不需要进行上下文切换，优化了性能

自旋重试成功的情况

线程 1（core 1 上）对象 Mark线程 2（core 2 上）
-10（重量锁）-
访问同步块，获取 monitor10（重量锁）重量锁指针-
成功（加锁）10（重量锁）重量锁指针-
执行同步块10（重量锁）重量锁指针-
执行同步块10（重量锁）重量锁指针访问同步块，获取 monitor
执行同步块10（重量锁）重量锁指针自旋重试
执行完毕10（重量锁）重量锁指针自旋重试
成功解锁01（无锁）自旋重试
-10（重量锁）重量锁指针成功（加锁）
-10（重量锁）重量锁指针执行同步块
-……

自旋重试失败的情况

线程 1（core 1 上）对象 Mark线程 2（core 2 上）
-10（重量锁）-
访问同步块，获取 monitor10（重量锁）重量锁指针-
成功（加锁）10（重量锁）重量锁指针-
执行同步块10（重量锁）重量锁指针-
执行同步块10（重量锁）重量锁指针访问同步块，获取 monitor
执行同步块10（重量锁）重量锁指针自旋重试
执行同步块10（重量锁）重量锁指针自旋重试
执行同步块10（重量锁）重量锁指针自旋重试
执行同步块10（重量锁）重量锁指针阻塞
-……
  • 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
  • 在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会
    高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。
  • Java 7 之后不能控制是否开启自旋功能

4. 偏向锁

轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。(锁重入：当前线程对同一对象多次加锁)

Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现
这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有

例如：

static final Object obj = new Object();
public static void m1() {
    synchronized( obj ) {
        // 同步块 A
        m2();
    }
}

public static void m2() {
    synchronized( obj ) {
        // 同步块 B
        m3();
    }
}

public static void m3() {
    synchronized( obj ) {
        // 同步块 C
    }
}
  • 如果使用轻量级锁，第一次会让锁记录 替换锁对象的 makeword字段。之后每一次锁重入时，都会用锁记录尝试替换锁对象的makeword，但是这些cas替换都会失败 。从而造成资源浪费和性能损耗!

image-20220613153900214

  • 使用偏向锁优化：第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。

image-20220613153915256

4.1 偏向状态

回忆一下对象头格式

|--------------------------------------------------------------------|--------------------|
|                         Mark Word (64 bits)                        |        State       |
|--------------------------------------------------------------------|--------------------|
|  unused:25 | hashcode:31 | unused:1 | age:4 | biased_lock:0 |  01  |       Normal       |
|--------------------------------------------------------------------|--------------------|
|  thread:54 |   epoch:2   | unused:1 | age:4 | biased_lock:1 |  01  |       Biased       |
|--------------------------------------------------------------------|--------------------|
| 	 		   		 	 ptr_to_lock_record:62          	  |  00  | Lightweight Locked |
|--------------------------------------------------------------------|--------------------|
| 	 		   		 ptr_to_heavyweight_monitor:62      	  |  10  | Heavyweight Locked |
|--------------------------------------------------------------------|--------------------|
| 						                                      |  11  |    Marked for GC   |
|--------------------------------------------------------------------|--------------------|
  • thread：线程ID
  • age：分代年龄
  • epoch：用于偏向重定向和偏向撤销

一个对象创建时：

  • 如果开启了偏向锁（默认开启），那么对象创建后，markword 值为 0x05 即最后 3 位为 101，这时它的
    thread、epoch、age 都为 0
  • 偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数 - XX:BiasedLockingStartupDelay=0 来禁用延迟
  • 如果没有开启偏向锁，那么对象创建后，markword 值为 0x01 即最后 3 位为 001，这时它的 hashcode、
    age 都为 0，第一次用到 hashcode 时才会赋值

1） 测试延迟特性

@Slf4j(topic = "c.TestBiased")
public class TestBiased {
    public static void main(String[] args) throws InterruptedException {
        Dog dog = new Dog();
        log.debug(JolUtils.toPrintableSimple(dog));

        Thread.sleep(4000);//代码进行延时，可以通过VM参数禁用延时
        log.debug(JolUtils.toPrintableSimple(new Dog()));
    }
}

class Dog{

}

image-20220618193927220

2） 测试偏向锁

//利用 jol 第三方工具来查看对象头信息（注意这里我使用工具类扩展了 jol 让它输出更为简洁）
//添加虚拟机参数 -XX:BiasedLockingStartupDelay=0
@Slf4j(topic = "c.TestBiased")
public class TestBiased {
    public static void main(String[] args) throws InterruptedException {
        Dog dog = new Dog();
        log.debug(JolUtils.toPrintableSimple(dog));//打印锁对象头的Makeword信息

        synchronized (dog){
            log.debug(JolUtils.toPrintableSimple(dog));
        }
        
        log.debug(JolUtils.toPrintableSimple(dog));
    }
}

image-20220618204735425

3）测试禁用
在上面测试代码运行时在添加 VM 参数 -XX:-UseBiasedLocking 禁用偏向锁。进行测试：
image-20220618205312616

4) 测试 hashCode

image-20220618210906822

运行结果：

image-20220618210930127

思考：为啥调用hashCode（）方法后，偏向锁会被禁用呢？

当调用hashCode后，需要Makeword存放31位的hashCode值，但是偏向锁状态下的threadID占54位，导致没有空间再存hashCode，所以就从Biased -> Normal。

4.2 撤销（偏向锁）

1. 调用对象 hashCode()

调用了对象的 hashCode，但偏向锁的对象 MarkWord 中存储的是线程 id，所以调用 hashCode 会导致偏向锁被撤销

  • 轻量级锁会在锁记录中记录 hashCode
  • 重量级锁会在 Monitor 中记录 hashCode

**注意：**在调用 hashCode 后使用偏向锁，记得去掉 -XX:-UseBiasedLocking

2. 其它线程使用对象
当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁

//轻量级锁应用场景：如果一个对象虽然有多线程要加锁，但加锁的时间是错开的。
public static void test02(){
    Dog dog = new Dog();

    new Thread(()->{
        log.debug(JolUtils.toPrintableSimple(dog));//打印锁对象头的Makeword信息

        synchronized (dog){
            log.debug(JolUtils.toPrintableSimple(dog));
        }
        synchronized (TestBiased.class){//t1唤醒t2
            TestBiased.class.notify();
        }
        log.debug(JolUtils.toPrintableSimple(dog));
    },"t1").start();

    new Thread(()->{

        synchronized (TestBiased.class){
            try {
                TestBiased.class.wait();//t2先等t1执行完，再继续往下执行。（这样做是为了保证俩线程错开）
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }


        log.debug(JolUtils.toPrintableSimple(dog));//打印锁对象头的Makeword信息

        synchronized (dog){
            log.debug(JolUtils.toPrintableSimple(dog));
        }
        synchronized (TestBiased.class){
            TestBiased.class.notify();
        }
        log.debug(JolUtils.toPrintableSimple(dog));
    },"t2").start();
}

image-20220618220018071

3.调用 wait/notify

wait和notify只有重量级锁有

//重量级锁应用场景：当多个线程交错执行，加锁时间未错开。对应着锁对象wait/notify的使用
public static void test03(){
    Dog dog = new Dog();
    Thread t1 = new Thread(() -> {
        log.debug(JolUtils.toPrintableSimple(dog));
        synchronized (dog) {
            log.debug(JolUtils.toPrintableSimple(dog));
            try {
                dog.wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
       		log.debug(JolUtils.toPrintableSimple(dog));
        }
    }, "t1");
    t1.start();

    Thread t2 = new Thread(() -> {
        try {
            Thread.sleep(6000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        synchronized (dog){
            log.debug("notify");
            dog.notify();
        }
        log.debug(JolUtils.toPrintableSimple(dog));
    }, "t2");
    t2.start();

}

image-20220618222537373

4.3 批量重偏向

撤销：从可偏向到不可偏向。也就是一个线程对对象使用完了，不用了，另外一个线程再访问。批量冲偏向是对撤销的优化。

如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象
的 Thread ID。
当撤销偏向锁阈值超过 20 次后(指撤销类的对象总次数)，jvm 会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至加锁线程

public static void test04() throws InterruptedException {
    Vector <Dog> list = new Vector <>();
    Thread t1 = new Thread(() -> {
        for (int i = 0; i < 30; i++) {
            Dog dog = new Dog();
            list.add(dog);
            synchronized (dog) {
                log.debug(i + "\t" + JolUtils.toPrintableSimple(dog));
            }
        }
        synchronized (list) {
            list.notify();
        }
    }, "t1");
    t1.start();

    Thread t2 = new Thread(() -> {
        synchronized (list) {
            try {
                list.wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        log.debug("===============> ");
        for (int i = 0; i < 30; i++) {
            Dog dog = list.get(i);
            log.debug(i + "\t" + JolUtils.toPrintableSimple(dog));
            synchronized (dog) {
                log.debug(i + "\t" + JolUtils.toPrintableSimple(dog));
            }
            log.debug(i + "\t" + JolUtils.toPrintableSimple(dog));
        }
    }, "t2");
    t2.start();
}

运行结果:

批量重定向

4.4 批量撤销

当撤销偏向锁阈值超过 40 次后，jvm 会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象
都会变为不可偏向的，新建的对象也是不可偏向的。

注意：这是40次是类级别的计数， 而不是对象级别的

static Thread t1,t2,t3;
public static void main(String[] args) throws InterruptedException {
    test05();
}
private static void test05() throws InterruptedException {
    Vector<Dog> list = new Vector<>();

    int loopNumber = 38;
    t1 = new Thread(() -> {
        for (int i = 0; i < loopNumber; i++) {
            Dog d = new Dog();
            list.add(d);
            synchronized (d) {
                log.debug(i + "\t" + JolUtils.toPrintableSimple(d));
            }
        }
        LockSupport.unpark(t2);
    }, "t1");
    t1.start();

    t2 = new Thread(() -> {
        LockSupport.park();
        log.debug("===============> ");
        for (int i = 0; i < loopNumber; i++) {
            Dog d = list.get(i);
            log.debug(i + "\t" + JolUtils.toPrintableSimple(d));
            synchronized (d) {
                log.debug(i + "\t" + JolUtils.toPrintableSimple(d));
            }
            log.debug(i + "\t" + JolUtils.toPrintableSimple(d));
        }
        LockSupport.unpark(t3);
    }, "t2");
    t2.start();

    t3 = new Thread(() -> {
        LockSupport.park();
        log.debug("===============> ");
        for (int i = 0; i < loopNumber; i++) {
            Dog d = list.get(i);
            log.debug(i + "\t" + JolUtils.toPrintableSimple(d));
            synchronized (d) {
                log.debug(i + "\t" + JolUtils.toPrintableSimple(d));
            }
            log.debug(i + "\t" + JolUtils.toPrintableSimple(d));
        }
    }, "t3");
    t3.start();

    t3.join();
    log.debug(JolUtils.toPrintableSimple(new Dog()));
}

思考：加入t4线程后的对象状态是什么？

  • 当loopNumber = 39时，锁对象（开始已经创建的这39个）状态都为Normal，不可偏向。由于撤销次数达到40，之后新创建的对象状态为Normal
  • 当loopNumber < 39时，锁对象（开始已经创建的这loopNumber个）状态都为Normal，不可偏向。但是由于撤销次数 < 40，之后创建的新对象状态默认依旧为 偏向状态

5. 锁粗化

锁粗化就是，当多个方法重复调用锁synchronized ，比如在for 循环中，就可以相当于在synchronized中进行for循环，进行粗化

具体深入剖析待完善…

6. 锁消除

@Fork(1)
@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations=3)
@Measurement(iterations=5)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class MyBenchmark {
    static int x = 0;
    @Benchmark
    public void a() throws Exception {
        x++;
    }
    @Benchmark
    public void b() throws Exception {
        Object o = new Object();
        synchronized (o) {
            x++;
        }
    }
}

image-20220619230153060

**原因分析：**Java运行时有一个JIT即时编译器，会对字节码进行进一步优化。其中一个手段就是逃逸分析锁消除 — 看局部变量是否逃离作用范围，对于b()，其中的 o对象并不会逃离方法范围，给其加锁没有意义，JIT就会吧synchronized优化掉，相当于没有加锁。所以a()和b()性能非常相近。

其中默认 JIT逃逸分析的开关是打开的，可以通过-XX:-EliminateLocks 进行关闭

关闭后运行之：

image-20220619232033205

四、wait / notify原理

image-20220621151150378

Owner 线程发现条件不满足，调用 wait 方法，即可进入 WaitSet 变为 WAITING 状态

WAITING线程和BLOCKED线程的区别？

  • WAITING：已经获得了锁，但是条件不满足，释放锁后进入WaitSet队列；
  • BLOCKED：没有获得锁，进入EntryList中等待，状态是BLOCKED

==相同点：==都处于阻塞状态，不占用CPU时间片，将来调度时候也不会考虑。

WAITING线程和BLOCKED线程的唤醒条件？

  • WAITING 线程会在 Owner 线程调用 notify 或 notifyAll 时唤醒，但唤醒后并不意味者立刻获得锁，仍需进入EntryList 重新竞争

  • BLOCKED 线程会在 Owner 线程释放锁时唤醒

五、join 原理

join 体现的是【保护性暂停】模式，请参考之

  • 保护性暂停：一个线程等待另一个线程的结果。

  • join：一个线程等待另一个线程的结束。

六、park & unpark原理

每个线程都有自己的一个 Parker 对象，由三部分组成_counter ， _cond 和 _mutex 打个比喻，线程就像一个旅人。

  • Parker 就像他随身携带的背包，条件变量就好比背包中的帐篷。_counter 就好比背包中的备用干粮（0 为耗尽，1 为充足）

  • 调用 park 就是要看需不需要停下来歇息

    • 如果备用干粮耗尽，那么钻进帐篷歇息
    • 如果备用干粮充足，那么不需停留，继续前进

  • 调用 unpark，就好比令干粮充足

    • 如果这时线程还在帐篷，就唤醒让他继续前进
    • 如果这时线程还在运行，那么下次他调用 park 时，仅是消耗掉备用干粮，不需停留继续前进
      • 因为背包空间有限，多次调用 unpark 仅会补充一份备用干粮

image-20220626143414890

  1. 当前线程调用 Unsafe.park() 方法
  2. 检查 _counter ，本情况为 0，这时，获得 _mutex 互斥锁
  3. 线程进入阻塞队列， _cond 条件变量变为阻塞
  4. 设置 _counter = 0

image-20220626143522801

  1. 调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1
  2. 唤醒 _cond 条件变量中的 Thread_0
  3. Thread_0 恢复运行
  4. 设置 _counter 为 0

image-20220626143609816

  1. 调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1
  2. 当前线程调用 Unsafe.park() 方法
  3. 检查 _counter ，本情况为 1，这时线程无需阻塞，继续运行
  4. 设置 _counter 为 0

七、指令级并行原理

1.名词

Clock Cycle Time

主频的概念大家接触的比较多，而 CPU 的 Clock Cycle Time（时钟周期时间），等于主频的倒数，意思是 CPU 能够识别的最小时间单位，比如说 4G 主频的 CPU 的 Clock Cycle Time 就是 0.25 ns，作为对比，我们墙上挂钟的Cycle Time 是 1s

例如，运行一条加法指令一般需要一个时钟周期时间

CPI

有的指令需要更多的时钟周期时间，所以引出了 CPI （Cycles Per Instruction）指令平均时钟周期数

IPC

IPC（Instruction Per Clock Cycle） 即 CPI 的倒数，表示每个时钟周期能够运行的指令数

CPU 执行时间

程序的 CPU 执行时间，即我们前面提到的 user + system 时间，可以用下面的公式来表示

程序 CPU 执行时间 = 指令数 * CPI * Clock Cycle Time

2.鱼罐头的故事

加工一条鱼需要 50 分钟，只能一条鱼、一条鱼顺序加工…

image-20220712141711569

可以将每个鱼罐头的加工流程细分为 5 个步骤：

  • 去鳞清洗 10分钟
  • 蒸煮沥水 10分钟
  • 加注汤料 10分钟
  • 杀菌出锅 10分钟
  • 真空封罐 10分钟

image-20220712141804164

即使只有一个工人，最理想的情况是：他能够在 10 分钟内同时做好这 5 件事，因为对第一条鱼的真空装罐，不会影响对第二条鱼的杀菌出锅…

3.指令重排序优化

事实上，现代处理器会设计为一个时钟周期完成一条执行时间最长的 CPU 指令。为什么这么做呢？可以想到指令还可以再划分成一个个更小的阶段，例如，每条指令都可以分为： 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 这 5 个阶段

image-20220712142220886

术语参考：

  • instruction fetch (IF)
  • instruction decode (ID)
  • execute (EX)
  • memory access (MEM)
  • register write back (WB)

在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行，这一技术在 80’s 中叶到 90’s 中叶占据了计算架构的重要地位。

指令重排的前提是，重排指令不能影响结果，例如

// 可以重排的例子
int a = 10; // 指令1
int b = 20; // 指令2
System.out.println( a + b );

// 不能重排的例子
int a = 10; // 指令1
int b = a - 5; // 指令2

4.支持流水线的处理器

现代 CPU 支持多级指令流水线，例如支持同时执行 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 的处理器，就可以称之为五级指令流水线。这时 CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段（相当于一条执行时间最长的复杂指令），IPC = 1，本质上，流水线技术并不能缩短单条指令的执行时间，但它变相地提高了指令地吞吐率。

提示：
奔腾四（Pentium 4）支持高达 35 级流水线，但由于功耗太高被废弃

image-20220712142621284

5.SuperScalar 处理器

大多数处理器包含多个执行单元，并不是所有计算功能都集中在一起，可以再细分为整数运算单元、浮点数运算单元等，这样可以把多条指令也可以做到并行获取、译码等，CPU 可以在一个时钟周期内，执行多于一条指令，IPC > 1

image-20220712142809116

image-20220712142822149

八、CPU 缓存结构原理

1. CPU 缓存结构

image-20220712160804006

查看CPU缓存

[root@lxyStudy ~]# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    1
座：                 2
NUMA 节点：         1
厂商 ID：           AuthenticAMD
CPU 系列：          23
型号：              96
型号名称：        AMD Ryzen 5 4500U with Radeon Graphics
步进：              1
CPU MHz：             2370.548
BogoMIPS：            4741.09
超管理器厂商：  VMware
虚拟化类型：     完全
L1d 缓存：          32K
L1i 缓存：          32K
L2 缓存：           512K
L3 缓存：           8192K
NUMA 节点0 CPU：    0,1

速度比较

image-20220712161139745

查看 cpu 缓存行

[root@lxyStudy ~]# cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
64  //代表64个字节

cpu 拿到的内存地址格式是这样的

[高位组标记][低位索引][偏移量]

image-20220712161351560

2. CPU 缓存读

读取数据流程如下

  • 根据低位，计算在缓存中的索引
  • 判断是否有效
    • 0 去内存读取新数据更新缓存行
    • 1 再对比高位组标记是否一致
      • 一致，根据偏移量返回缓存数据
      • 不一致，去内存读取新数据更新缓存行

3. CPU 缓存一致性

MESI 协议

  1. E、S、M 状态的缓存行都可以满足 CPU 的读请求
  2. E 状态的缓存行，有写请求，会将状态改为 M，这时并不触发向主存的写
  3. E 状态的缓存行，必须监听该缓存行的读操作，如果有，要变为 S 状态

image-20220713190633937

  1. M 状态的缓存行，必须监听该缓存行的读操作，如果有，先将其它缓存（S 状态）中该缓存行变成 I 状态（即6.的流程），写入主存，自己变为 S 状态
  2. S 状态的缓存行，有写请求，走 4. 的流程
  3. S 状态的缓存行，必须监听该缓存行的失效操作，如果有，自己变为 I 状态
  4. I 状态的缓存行，有读请求，必须从主存读取

image-20220713190757223

4. 内存屏障

Memory Barrier（Memory Fence）

  • 可见性
    • 写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中
    • 而读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据
  • 有序性
    • 写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
    • 读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

image-20220712165222156

九、volatile 原理

volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）

  • 对 volatile 变量的写指令后会加入写屏障，在写指令包括之前的写都会被同步到主存中去
  • 对 volatile 变量的读指令前会加入读屏障，包括这条以及之后的读都是从主存中读

1.如何保证可见性

写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中

public void actor2(I_Result r) {
    num = 2;
    ready = true; // ready 是 volatile 赋值带写屏障
    // 写屏障
}

而读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据

public void actor1(I_Result r) {
	// 读屏障
	// ready 是 volatile 读取值带读屏障
    if(ready) {
        r.r1 = num + num;
    } else {
        r.r1 = 1;
    }
}

image-20220712165810022

2.如何保证有序性

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后

public void actor2(I_Result r) {
    num = 2;
    ready = true; // ready 是 volatile 赋值带写屏障
    // 写屏障
}

读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

public void actor1(I_Result r) {
    // 读屏障
    // ready 是 volatile 读取值带读屏障
    if(ready) {
    	r.r1 = num + num;
    } else {
    	r.r1 = 1;
    }
}

image-20220712171344537

注意：volatile只是保证可见性和有序性，不能解决指令交错：

  • 写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证其他线程的读跑到它前面去
    • 如：t1写入i=1可以保证 结果会被刷新到主存，但是并不能保证t2读的顺序（如图t2）
  • 而有序性的保证也只是保证了本线程内相关代码不被重排序
    • 两（多）个线程之间指令的顺序是由CPU的时间片决定的

image-20220712171600908

synchronized和volatile：前者可以保证原子性、可见性、有序性，后者只能保证可见性、有序性，但是无法保证原子性。

3.double-checked locking 问题

**引入：**double-checked的由来

以著名的 double-checked locking 单例模式为例

public final class Singleton {
    private Singleton() { }
    private static Singleton INSTANCE = null;
    public static Singleton getInstance() {
        if(INSTANCE == null) { // t2
            // 首次访问会同步，而之后的使用没有 synchronized
            synchronized(Singleton.class) {
                if (INSTANCE == null) { // t1
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

以上的实现特点是：

  • 懒惰实例化
  • 首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁
  • 有隐含的，但很关键的一点：第一个 if 使用了 INSTANCE 变量，是在同步块之外

但在多线程环境下，上面的代码是有问题的，getInstance 方法对应的字节码为：

0: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
3: ifnonnull 37
6: ldc #3 // class cn/itcast/n5/Singleton
8: dup
9: astore_0
10: monitorenter
11: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
14: ifnonnull 27
17: new #3 // class cn/itcast/n5/Singleton
20: dup
21: invokespecial #4 // Method "<init>":()V
24: putstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
27: aload_0
28: monitorexit
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
40: areturn
//注意：new 是在堆中创建了一个Singleton实例对象，dup是复制了指针引用放入栈中

其中 下面这几条指令正常情况下是会按照顺序依次执行的：

  • 17 表示创建对象，将对象引用入栈 // new Singleton
  • 20 表示复制一份对象引用 // 引用地址
  • 21 表示利用一个对象引用，// 调用构造方法
  • 24 表示利用一个对象引用，赋值给 static INSTANCE

也许 jvm 会优化为：先执行 24，再执行 21。如果两个线程 t1，t2 按如下时间序列执行：

image-20220713165715527

**分析：**先调用24行在调用21行，也就是发生了指令重排。在t1执行24行时，t2正执行执行 0行和3行代码，这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例

关键在于 0: getstatic 这行代码在 monitor 控制之外，它就像之前举例中不守规则的人，可以越过 monitor 读取INSTANCE 变量的值

解决办法：对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才会真正有效

补充：synchronized块内可以防止指令重排嘛？

  • synchronized不能防止指令重排序（ 块里的非原子操作依旧可能发生指令重排序），但是**volatile可以防止指令重排序** 。

  • 但是如果共享变量完全被synchronized所保护，那么在使用过程中是不会有原子、有序、可见性问题的。即使出现了重排序，也不会出现有序性问题的！我们的案例中instance并没有被完全保护起来，所以会导致下图中现象会发生，同时由于指令的重排序就导致了 上面分析中出现的 问题

    image-20220713175735247

  • 重排序和有序性不是一回事，synchronized的有序性是持有相同锁的两个同步块只能串行的进入，即被加锁的内容要按照顺序被多个线程执行，但是其内部的同步代码还是会发生重排序，使块与块之间有序可见。

  • 参考文章：Java synchronized 能防止指令重排序吗？

4. double-checked locking 解决

public final class Singleton {
    private Singleton() { }
    private static volatile Singleton INSTANCE = null;//可以防止指令重排序
    public static Singleton getInstance() {
		// 实例没创建，才会进入内部的 synchronized代码块
        if (INSTANCE == null) {
            synchronized (Singleton.class) { // t2
				// 也许有其它线程已经创建实例，所以再判断一次
                if (INSTANCE == null) { // t1
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

字节码上看不出来 volatile 指令的效果

// -------------------------------------> 加入对 INSTANCE 变量的读屏障 防止屏障之后的代码排到前面去
0: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
3: ifnonnull 37
6: ldc #3 // class cn/itcast/n5/Singleton
8: dup
9: astore_0
10: monitorenter -----------------------> 保证原子性、可见性
11: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
14: ifnonnull 27
17: new #3 // class cn/itcast/n5/Singleton
20: dup
21: invokespecial #4 // Method "<init>":()V
24: putstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
// -------------------------------------> 加入对 INSTANCE 变量的写屏障 防止屏障之前的代码排到后面去
27: aload_0
28: monitorexit ------------------------> 保证原子性、可见性
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
40: areturn

如上面的注释内容所示，读写 volatile 变量时会加入内存屏障（Memory Barrier（Memory Fence）），保证下面两点：

可见性

  • 写屏障（sfence）保证在该屏障之前的 t1 对共享变量的改动，都同步到主存当中
  • 而读屏障（lfence）保证在该屏障之后 t2 对共享变量的读取，加载的是主存中最新数据

有序性

  • 写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
  • 读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

更底层是读写变量时使用 lock 指令来保证多核 CPU 之间的可见性与有序性

加入volatile后执行图解

image-20220713170342900

爱编程的大李子
关注
  • 7
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 5
    评论
专栏目录
tuling-juc-final.zip
05-23
本项目"tuling-juc-final.zip"显然聚焦于Java并发编程的实践，通过一系列代码示例来演示和解释Java内存模型（JMM）、`synchronized`关键字以及`volatile`关键字的使用。下面我们将深入探讨这些核心概念。 Java内存...
1.深入JVM源码，查看如何实现wait()，notify()方法
义笔记
06-08 7176
1.深入JVM源码，查看如何实现wait() 在java中，每个对象都是Object的子类，java中每个对象都是"锁"，但是这是如何实现的呢，今天我们看看JVM层面如何实现Object.wait/notify方法的。 在讲这个之前我们需要了解一下java的对象在内存中的布局情况； 1.对象头：下面重点讲解 2.实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐 3.填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的
Java并发编程之synchronized关键字与Monitor机制
yzpbright的博客
03-03 419
调用obj的wait(), notify()方法前，必须获得obj锁，也就是必须写在synchronized(obj) 代码段内。 【转载】Java多线程（二）——Java对象的Monitor机制 synchronized、monitor、wait、notify ...
Java多线程wait/notify原理
LIUZEYU12A
01-30 910
1. 引入wait/notify 回顾：在之前的学习中，当我们创建一个对象后，synchronized给对象上锁，JVM会给对象头关联一个Monitor对象，这个Monitor由三部分组成。 一是Owner对象，里面存储的是创建该对象的线程 二是EntryList，想试图获取该对象资源的其它堵塞线程队列 三是WaitSet，存储的是放弃对象锁的线程 Owner线程中的锁对象，如果发现条件不满足，调用wait()方法，既可以进入到WaitSet变为WAITING状态 EntryList下和WaitSet下
synchronized在jvm中的实现原理、在字节码层面上的实现同步的原理
qq_41174684的博客
05-22 2456
synchtonized
Java 对象头、监视器、synchronized
haoranhaoshi的博客
09-10 683
对象头 HotSpot虚拟机的对象头包括两部分信息： MarkWord 第一部分MarkWord，用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部分数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32bit和64bit，官方称它为“MarkWord”。 Class类型指针 对象头的另外一部分是Class类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例. ...
并发编程(各种脑图资源集合).rar
06-21
并发编程是计算机科学中的一个重要领域，特别是在多核处理器和分布式系统中，它是提高程序性能和效率的关键技术。这个"并发编程(各种脑图资源集合).rar"文件包含了一系列关于并发编程的Xmind脑图，涵盖了从基础知识...
个人学习-JUC-笔记
02-25
Java并发编程是Java开发中的重要领域，而JUC（Java Util Concurrency）是Java平台提供的一套高级并发工具包，它极大地简化了多线程和并发控制的复杂性。本笔记主要围绕尚硅谷周阳老师的JUC课程展开，旨在帮助个人...
汪文君高并发编程实战视频资源下载.txt
08-08
│ 高并发编程第一阶段19讲、结合jconsole,jstack以及汇编指令认识synchronized关键字.mp4 │ 高并发编程第一阶段20讲、同步代码块以及同步方法之间的区别和关系.mp4 │ 高并发编程第一阶段21讲、通过实验分析...
java高并发源码-java-concurrent:Java高并发，JUC，相关源码。1、马士兵高并发视频源码（听课时练习）
05-24
Java并发编程是Java开发中的重要领域，特别是在大型分布式系统或高性能应用中，对并发处理的需求尤为突出。"java-concurrent"这个项目显然聚焦于Java并发编程的实践与学习，特别是通过马士兵老师的高并发视频课程的...
Synchronized 用法和底层原理
击水三千里的专栏
08-11 2292
一、对象锁和类锁 1. 对象锁 在 Java 中，每个对象都会有一个 monitor 对象，这个对象其实就是 Java 对象的锁，通常会被称为“内置锁”或“对象锁”。类的对象可以有多个，所以每个对象有其独立的对象锁，互不干扰。 2. 类锁 在 Java 中，针对每个类也有一个锁，可以称为“类锁”，类锁实际上是通过对象锁实现的，即类的 Class 对象锁。每个类只有一个 Class 对象，所...
Java之synchronized的JVM底层实现原理精简理解
weixin_44519342的博客
02-14 414
Java之synchronized的JVM底层实现原理精简理解
java monitorenter_java并发：Synchronized 原理
weixin_29149341的博客
02-19 122
指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。Synchronized的语义底层是通过一个monitor的对象来完成，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify...
Java并发编程之 synchronized
qq_43613793的博客
09-22 703
Java中的每一个对象都可以作为锁。具体表现为以下3种形式： 对于普通同步方法，锁是当前实例对象 对于静态同步方法，锁是当前类的Class对象 对于同步代码块，锁是synchonized括号里配置的对象 都对于同步代码块而言，JVM是使用monitorenter和monitorexit实现的： monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束处和异常处，JVM要保证每个monitorenter必须有对应的monitorexit与之配对。任何对象
java多线程——Monitor机制和synchronized关键字
define_us的专栏
11-13 541
synchronized的用法 指定加锁对象:对给定对象加锁，进入同步代码前需要活的给定对象的锁。 直接作用于实例方法:相当于对当前实例加锁，进入同步代码前要获得当前实例的锁。 直接作用于静态方法:相当于对当前类加锁，进入同步代码前要获得当前类（当前类内部的class对象）的锁。 内部原理 Synchronized在古老的年代被成为重量级锁。但是java1.6对其进行了优化。为了减少...
并发编程之五：synchronized底层原理、monitor、轻量级锁、偏向锁、wati/notify/notifyAll、join、状态转换
java_xxxx的博客
06-29 658
并发之共享模型之：管程synchronized底层原理Monitorjava对象头monitor(锁)synchronized原理进阶小故事轻量级锁膨胀锁wait/notify线程状态转换活跃性Lock synchronized底层原理 我们从底层原理来分析synchronized，进一步的了解它。 下面的内容会非常的枯燥和无聊，想要学习上乘武学就得耐得住枯燥、无聊和寂寞。 Monitor 学习Monitor之前我们先了解以下java对象头，后面我们会用到java对象头里的知识。 java对象头 通常我们的
JUC并发编程，如何理解并使用 park 与 unpark
as230627的博客
08-01 123
JUC并发编程，如何理解并使用 park 与 unpark
【JUC】 LockSupport类的park等待和unpark唤醒
Decade_Faiz的博客
04-06 363
LockSuppot：用于创建锁和其他同步类的基本线程阻塞原语。这个类与每个使用它的线程相关联，一个许可证（在Semaphore类的意义上）。如果许可证可用，则呼叫park将park返回，在此过程中消耗它;否则可能会阻止。致电unpark使许可证可用，如果尚不可用。（与信号量不同，许可证不能累积，最多只有一个。LockSupport类使用了一种名为Permit（许可）的概念来做到阻塞和唤醒线程的功能， 每个线程都有一个许可(permit)，permit只有两个值1和零，默认是零。
JUC并发编程——Park & Unpark
m0_56188609的博客
03-07 497
● 调用 LockSupport.unpark(目标线程) 或调用了线程 的 interrupt() ，或是等待超时，会让目标线程从TIMED_WAITING–> RUNNABLE。● 当前线程等待时间超过了 n 毫秒，或t 线程运行结束，或调用了当前线程的 interrupt() 时，当前线程从TIMED_WAITING --> RUNNABLE。● t 线程等待时间超过了 n 毫秒，或调用 obj.notify() ， obj.notifyAll() ， t.interrupt() 时。
JUC代码演示 Java多线程并发
最新发布
05-03
JUC代码演示 Java多线程并发 源于B站https://www.bilibili.com/video/BV1Kw411Z7dF/?p=32&spm_id_from=333.1007.top_right_bar_window_history.content.click课程自我项目记录。 适合有一定基础的朋友。

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

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 5
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

爱编程的大李子

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值