关于java:开发宝典Java并发系列教程

作者：京东批发 刘跃明

Monitor 概念

Java 对象的内存布局

对象除了咱们自定义的一些属性外，还有其它数据，在内存中能够分为三个区域：对象头、实例数据、对齐填充，这三个区域组成起来才是一个残缺的对象。

对象头：在 JVM 中须要大量存储对象，存储时为了实现一些额定的性能，须要在对象中增加一些标记字段用于加强对象性能，这些标记字段组成了对象头。

实例数据：寄存类的属性数据信息，包含父类的属性信息。

对齐填充：因为虚拟机要求对象其实地址必须是 8 字节的整数倍，须要存在填充区域以满足 8 字节的整数倍，填充数据不是必须存在的，仅仅是为了字节对齐。





图 1

Java 对象头

JVM 中对象头的形式有以下两种（以 32 位虚拟机为例）：

一般对象

数组对象

Mark Word

这部分次要用来存储对象本身的运行数据，如 hashcode、gc 分带年龄等，Mark Word 的位长度为 JVM 的一个 Word 大小，也就是说 32 位 JVM 的 Mark Word 为 32 位，64 位 JVM 为 64 位。为了让一个字大小存储更多的信息，JVM 将字的最低两个位设置为标记位，不同标记位下的 Mark Word 示意如下：

其中各局部的含意如下：

lock： 2 位的锁状态标记位，该标记的值不同，整个 Mark Word 示意的含意不同。

biased_lock： 对象是否启用偏差锁标记，只占 1 个二进制位，为 1 时示意对象启用偏差锁，为 0 时示意对象没有偏差锁。

age： 4 位的 Java 对象年龄，在 GC 中，如果对象再 Survivor 区复制一次，年龄减少 1，当对象达到设定的阈值时，将会降职到老年代，默认状况下，并行 GC 的年龄阈值为 15，并发 GC 的年龄阈值为 6，因为 age 只有 4 位，所以最大值为 15，这就是 -XX:MaxTenuringThreshold 选项最大值为 15 的起因。

identity_hashcode： 25 位的对象示意 Hash 码，采纳提早加载技术，调用办法 System.idenHashcode()计算，并会将后果写到该对象头中，当对象被锁定时，该值会挪动到管程 Monitor 中。

thread： 持有偏差锁的线程 ID。

epoch： 偏差工夫戳。

ptr_to_lock_record： 指向栈中锁记录的指针。

ptr_to_heavyweight_monitor： 指向管程 Monitor 的指针。

Klass Word

这一部分用于存储对象的类型指针，该指针指向它的类元数据，JVM 通过这个指针确定对象是哪个类的实例，该指针的位长度为 JVM 的一个字大小，即 32 位的 JVM 为 32 位，64 位的 JVM 为 64 位。

array length

如果对象是一个数组，那么对象头还须要有额定的空间用于存储数组的长度，这部分数据的长度也随着 JVM 架构的不同而不同：32 位的 JVM 长度为 32 位，64 位 JVM 则为 64 位。

Monitor 原理

Monitor 被翻译为 监视器 或管程

每个 Java 对象都能够关联一个 Monitor 对象，如果应用 synchronized 给对象上锁（重量级）之后，该对象头的 Mark Word 中就被设置指向 Monitor 对象的指针。

Monitor 构造如下：





图 2

•刚开始 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

•Thread- 2 执行完同步代码块的内容，而后唤醒 EntryList 中期待的线程来竞争锁，竞争是非偏心的，也就是先进并非先获取锁

•图 2 中 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 main([Ljava/lang/String;)V

TRYCATCHBLOCK L0 L1 L2 null

TRYCATCHBLOCK L2 L3 L2 null

L4

LINENUMBER 6 L4

GETSTATIC MyClass03.lock : Ljava/lang/Object;

DUP

ASTORE 1

MONITORENTER //正文 1

L0

LINENUMBER 7 L0

GETSTATIC MyClass03.counter : I

ICONST_1

IADD

PUTSTATIC MyClass03.counter : I

L5

LINENUMBER 8 L5

ALOAD 1

MONITOREXIT //正文 2

L1

GOTO L6

L2

FRAME FULL [[Ljava/lang/String; java/lang/Object]

ASTORE 2

ALOAD 1

MONITOREXIT //正文 3

L3

ALOAD 2

ATHROW

L6

LINENUMBER 9 L6

FRAME CHOP 1

RETURN

L7

LOCALVARIABLE args [Ljava/lang/String; L4 L7 0

MAXSTACK = 2

MAXLOCALS = 3

正文 1

MONITORENTER 的意思为：每个对象都有一个监督锁（Monitor），当 Monitor 被占用时就会处于锁定状态，线程执行 MONITORENTER 指令时尝试获取 Monitor 的所有权，过程如下：

•如果 Monitor 的进入数为 0，则该线程进入 Monitor，并将进入数设置为 1，该线程即为 Monitor 的所有者（Owner）

•如果该线程曾经占用 Monitor，只是从新进入 Monitor，则进入 Monitor 的进入数加 1

•如果其它线程曾经占用 Monitor，则该线程进入阻塞状态，直到 Monitor 进入数为 0，再从新尝试获取 Monitor 的所有权

正文 2

MONITOREXIT 的意思为：执行指令时，Monitor 的进入数减 1，如果减 1 后进入数为 0，该线程退出 Monitor，不再是这个 Monitor 的所有者，其它被 Monitor 阻塞的线程从新尝试获取 Monitor 的所有权。

总结

通过正文 1 和正文 2 可知，synchronized 的实现原理，底层是通过 Monitor 的对象来实现，其实 wait 和 notify 等办法也依赖 Monitor，这就是为什么 wait 和 notify 办法必须要在同步办法内调用，否则会抛出 java.lang.IllegalMonitorStateException 的起因。

如果程序失常执行则按上述形容即可实现，如果程序在同步办法内产生异样，代码则会走正文 3，在正文 3 能够看到 MONITOREXIT 指令，也就是 synchronized 曾经解决异常情况下的退出。

注：办法级别的 synchronized 不会在字节码指令中有所体现，而是在常量池中减少了 ACC_SYNCHRONIZED 标识符，JVM 就是通过该标识符来实现同步的，办法调用时，JVM 会判断办法的 ACC_SYNCHRONIZED 是否被设置，如果被设置，线程执行办法前会先获取 Monitor 所有权，执行完办法后再开释 Monitor 所有权，实质是一样的。

synchronized 原理进阶

轻量级锁

轻量级锁的应用场景：如果一个对象尽管有多线程要加锁，但加锁的工夫是错开的（也就是没有竞争），那么能够应用轻量级锁来优化。

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

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

static final Object obj = new Object();

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

public static void method2() {synchronized (obj) {// 同步块 B}
}

创立锁记录（Lock Record）对象，每个线程的栈帧都会蕴含一个锁记录的构造，外部能够存储锁定对象的 Mark Word





图 3

让锁记录中 Object reference 指向锁对象，并尝试用 cas 替换 Object 的 Mark Word，将 Mark Word 的值存入锁记录





图 4

如果 cas 替换胜利，对象头中存储了 锁记录地址和状态 00，示意由该线程给对象加锁，这是图示如下





图 5

如果 cas 失败，有两种状况

•如果是其它线程曾经持有了该 Object 的轻量级锁，这是表明有竞争，进入锁收缩过程

•如果是本人线程执行了 synchronized 锁重入，那么再增加一条 Lock Record 作为重入的技术





图 6

当退出 synchronized 代码块（解锁时），如果有取值为 null 的锁记录，示意由重入，这是重置锁记录，示意重入技术减一





图 7

当退出 synchronized 代码块（解锁时），锁记录的值不为 null，这时应用 cas 将 Mark Word 的值回复给对象头

•胜利，则解锁胜利

•失败，阐明轻量级锁进行了锁收缩或曾经降级为重量级锁，进入重量级锁解锁流程

锁收缩

如果在尝试加轻量级锁的过程中，CAS 操作无奈胜利，这是一种状况就是有其它线程为此对象加上了轻量级锁（有竞争），这是须要进行锁收缩，将轻量级锁变为重量级锁。

当 Thread- 1 进行轻量级加锁时，Thread- 0 曾经对该对象加了轻量级锁





图 8

这是 Thread- 1 加轻量级锁失败，进入锁收缩流程

•即为 Object 对象申请 Monitor 锁，让 Object 指向重量级锁地址

•而后本人进入 Monitor 的 EntryList BLOCKED





图 9

当 Thread- 0 退出同步块解锁时，应用 cas 将 Mark Word 的值复原给对象头，失败，这是会进入重量级解锁流程，即依照 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 BLOCKED 线程

自旋优化

重量级锁竞争的时候，还能够应用自旋来进行优化，如果以后线程自旋胜利（即这时候持锁线程曾经退出了同步，开释了锁），这是以后线程就能够防止阻塞。

自旋重试胜利的状况

自旋重试失败的状况

•自旋会占用 CPU 工夫，单核 CPU 自旋就是节约，多核 CPU 自旋能力发挥优势。

•在 Java 6 之后自旋锁是自适应的，比方对象刚刚的一次自旋操作胜利过，那么认为这次自旋胜利的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比拟智能。

•Java 7 之后不能管制是否开启自旋性能。

偏差锁

轻量级锁在没有竞争时（就本人这个线程），每次重入依然须要执行 CAS 操作。

Java 6 中引入了偏差锁做进一步优化：只有第一次应用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是本人的就示意没有竞争，不必从新 CAS，当前只有不产生竞争，这个对象就归该线程所有。

注：

Java 15 之后废除偏差锁，默认是敞开，如果想应用偏差锁，配置 -XX:+UseBiasedLocking 启动参数。

启动偏差锁之后，偏差锁有一个提早失效的机制，这是因为 JVM 启动时会进行一系列的简单流动，比方装载配置，零碎类初始化等等。在这个过程中会应用大量 synchronized 关键字对对象加锁，且这些锁大多数都不是偏差锁。为了缩小初始化工夫，JVM 默认延时加载偏差锁。这个延时的工夫大略为 4s 左右，具体工夫因机器而异。当然咱们也能够设置 JVM 参数 -XX:BiasedLockingStartupDelay=0 来勾销延时加载偏差锁。

例如：

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) {}}

如果敞开偏差锁，应用轻量锁状况：





图 10

开启偏差锁，应用偏差锁状况：





图 11

偏差状态

回顾一下对象头格局

一个对象创立时：

•如果开启了偏差锁（默认开启），那么对象创立后，Mark Word 值为 0x05, 也就是最初是 3 位为 101，这是它的 thread、epoch、age 都为 0

•如果没有开启偏差锁，那么对象创立后，Mark Word 值为 0x01，也就是最初 3 位为 001，这时它的 hashcode、age 都为 0，第一次用到 hashcode 时才会赋值

咱们来验证下，应用 jol 第三方工具，以及对工具打印对象头做了一个解决，让对象头开起来更简便：

测试代码

public synchronized static void main(String[] args){log.info("{}", toSimplePrintable(object));
}

开启偏差锁的状况下

打印的数据如下（因为 Java15 之后偏差锁废除，因而关上偏差锁打印会正告）

17:15:17 [main] c.MyClass03 – 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101

最初为 101，其余都为 0，验证了上述第一条。

可能你又要问了，我这也没应用 synchronized 关键字呀，那不也应该是无锁么？怎么会是偏差锁呢？

认真看一下偏差锁的组成，对照输入后果红色划线地位，你会发现占用 thread 和 epoch 的 地位的均为 0，阐明以后偏差锁并没有偏差任何线程。此时这个偏差锁正处于可偏差状态，筹备好进行偏差了！你也能够了解为此时的偏差锁是一个 非凡状态的无锁。

敞开偏差锁的状况下

打印的数据如下

17:18:32 [main] c.MyClass03 – 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

最初为 001，其它都是 0，验证了上述第二条。

接下来验证加锁的状况，代码如下：

private static Object object = new Object();
public synchronized static void main(String[] args){new Thread(()->{log.info("{}", "synchronized 前");
        log.info("{}", toSimplePrintable(object));
        synchronized (object){log.info("{}", "synchronized 中");
            log.info("{}", toSimplePrintable(object));
        }
        log.info("{}", "synchronized 后");
        log.info("{}", toSimplePrintable(object));
    },"t1").start();}

开启偏差锁的状况，打印数据如下

17:24:05 [t1] c.MyClass03 – synchronized 前

17:24:05 [t1] c.MyClass03 – 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101

17:24:05 [t1] c.MyClass03 – synchronized 中

17:24:05 [t1] c.MyClass03 – 00000000 00000000 00000000 00000001 00001110 00000111 01001000 00000101

17:24:05 [t1] c.MyClass03 – synchronized 后

17:24:05 [t1] c.MyClass03 – 00000000 00000000 00000000 00000001 00001110 00000111 01001000 00000101

应用了偏差锁，并记录了线程的值（101 后面的一串数字），然而处于偏差锁的对象解锁后，线程 id 仍存储于对象头中。

敞开偏差锁的状况，打印数据如下

17:28:24 [t1] c.MyClass03 – synchronized 前

17:28:24 [t1] c.MyClass03 – 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

17:28:24 [t1] c.MyClass03 – synchronized 中

17:28:24 [t1] c.MyClass03 – 00000000 00000000 00000000 00000001 01110000 00100100 10101001 01100000

17:28:24 [t1] c.MyClass03 – synchronized 后

17:28:24 [t1] c.MyClass03 – 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

应用轻量锁（最初为 000），并且记录了占中存储的锁信息地址（000 后面一串数字），同步块完结后复原到原先状态（因为没有应用 hashcode，所以 hashcode 值为 0）。

偏差锁撤销

在真正解说偏差撤销之前，须要和大家明确一个概念——偏差锁撤销和偏差锁开释是两码事。

•撤销：抽象的说就是多个线程竞争导致不能再应用偏差模式的时候，次要是告知这个锁对象不能再用偏差模式

•开释：和你的惯例了解一样，对应的就是 synchronized 办法的退出或 synchronized 块的完结

何为偏差撤销？

从偏差状态撤回原有的状态，也就是将 MarkWord 的第 3 位（是否偏差撤销）的值，从 1 变回 0

如果只是一个线程获取锁，再加上「偏心」的机制，是没有理由撤销偏差的，所以偏差的撤销只能产生在有竞争的状况下

撤销 -hashcode 调用

调用了对象的 hashcode 会导致偏差锁被撤销：

•轻量级锁会在锁记录中记录 hashcode

•重量级锁会在 Monitor 中记录 hashcode

测试代码如下

private static Object object = new Object();
public synchronized static void main(String[] args){object.hashCode();// 调用 hashcode
    new Thread(()->{log.info("{}", "synchronized 前");
        log.info("{}", toSimplePrintable(object));
        synchronized (object){log.info("{}", "synchronized 中");
            log.info("{}", toSimplePrintable(object));
        }
        log.info("{}", "synchronized 后");
        log.info("{}", toSimplePrintable(object));
    },"t1").start();}

打印如下：

17:36:05 [t1] c.MyClass03 – synchronized 前

17:36:06 [t1] c.MyClass03 – 00000000 00000000 00000000 01011111 00100001 00001000 10110101 00000001

17:36:06 [t1] c.MyClass03 – synchronized 中

17:36:06 [t1] c.MyClass03 – 00000000 00000000 00000000 00000001 01101110 00010011 11101001 01100000

17:36:06 [t1] c.MyClass03 – synchronized 后

17:36:06 [t1] c.MyClass03 – 00000000 00000000 00000000 01011111 00100001 00001000 10110101 00000001

撤销 - 其它线程应用对象

当有其它线程应用偏差锁对象时，会将偏差锁降级为轻量级锁。

测试代码如下

private static void test2() {Thread t1 = new Thread(() -> {synchronized (object) {log.info("{}", toSimplePrintable(object));
        }
        synchronized (MyClass03.class) {MyClass03.class.notify();//t1 执行完之后才告诉 t2 执行
        }
    }, "t1");
    t1.start();
    Thread t2 = new Thread(() -> {synchronized (MyClass03.class) {
            try {MyClass03.class.wait();
            } catch (InterruptedException e) {e.printStackTrace();
            }
        }
        log.info("{}", toSimplePrintable(object));
        synchronized (object) {log.info("{}", toSimplePrintable(object));
        }
        log.info("{}", toSimplePrintable(object));
    }, "t2");
    t2.start();}

打印数据如下

17:51:38 [t1] c.MyClass03 – 00000000 00000000 00000000 00000001 01000111 00000000 11101000 00000101

17:51:38 [t2] c.MyClass03 – 00000000 00000000 00000000 00000001 01000111 00000000 11101000 00000101

17:51:38 [t2] c.MyClass03 – 00000000 00000000 00000000 00000001 01111000 00100000 01101001 01010000

17:51:38 [t2] c.MyClass03 – 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

能够看到线程 t1 是应用偏差锁，线程 t2 应用锁之前是一样的，然而一旦应用了锁，便降级为轻量级锁，执行完同步代码之后，复原成撤销偏差锁的状态。

撤销 - 调用 wait/notify

代码如下

private static void test3(){Thread t1 = new Thread(() -> {log.info("{}", toSimplePrintable(object));
        synchronized (object) {log.info("{}", toSimplePrintable(object));
            try {object.wait();
            } catch (InterruptedException e) {e.printStackTrace();
            }
            log.info("{}", toSimplePrintable(object));
        }
    }, "t1");
    t1.start();
    new Thread(() -> {
        try {Thread.sleep(6000);
        } catch (InterruptedException e) {e.printStackTrace();
        }
        synchronized (object) {log.debug("notify");
            object.notify();}
    }, "t2").start();}

打印数据如下

17:57:57 [t1] c.MyClass03 – 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101

17:57:57 [t1] c.MyClass03 – 00000000 00000000 00000000 00000001 00001111 00001100 11010000 00000101

17:58:02 [t2] c.MyClass03 – notify

17:58:02 [t1] c.MyClass03 – 00000000 00000000 01100000 00000000 00000011 11000001 10000010 01110010

调用 wait 和 notify 得是用 Monitor，所以会从偏差锁降级为重量级锁。

批量重偏差

如果对象尽管被多个线程拜访，但没有竞争，这是偏差了线程 t1 的对象依然有机会从新偏差 t2，重偏差会重置对象的 Thread ID。

当撤销偏差锁阈值超过 20 次后，JVM 会这样感觉，我是不是偏差错了呢，于是会在给这些对象加锁时从新偏差至加锁线程。

代码如下

public static class Dog{}

private static void test4() {Vector<Dog> list = new Vector<>();
    Thread t1 = new Thread(() -> {for (int i = 0; i < 30; i++) {Dog d = new Dog();
            list.add(d);
            synchronized (d) {log.info("{}", i+"\t"+toSimplePrintable(d));
            }
        }
        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 d = list.get(i);
            log.info("{}", i+"\t"+toSimplePrintable(d));
            synchronized (d) {log.info("{}", i+"\t"+toSimplePrintable(d));
            }
            log.info("{}", i+"\t"+toSimplePrintable(d));
        }
    }, "t2");
    t2.start();}

打印如下





图 12

另外我在测试的是否发现一个线程，当对象是一般类（如 Dog）时，重偏差的阈值就是 20，也就是第 21 次开启了偏差锁，然而如果把一般类替换成 Object 时，重偏差的阈值就是 9，也就是第 10 次开启了偏差锁并重偏差（如图 13），这是怎么回事儿，有理解的同学能够评论交换下。





图 13

批量撤销

当撤销偏差锁阈值超过 40 次后，JVM 会这样感觉，本人的确偏差错了，基本不该偏差，于是整个类的所有对象都会变为不可偏差的，新建的对象也是不可偏差的。

代码如下

static Thread t1, t2, t3;

private static void test6() throws InterruptedException {Vector<Dog> list = new Vector<>();
    int loopNumber = 40;
    t1 = new Thread(() -> {for (int i = 0; i < loopNumber; i++) {Dog d = new Dog();
            list.add(d);
            synchronized (d) {log.info("{}", i + "\t" + toSimplePrintable(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.info("{}", i + "\t" + toSimplePrintable(d));
            synchronized (d) {log.info("{}", i + "\t" + toSimplePrintable(d));
            }
            log.info("{}", i + "\t" + toSimplePrintable(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.info("{}", i + "\t" + toSimplePrintable(d));
            synchronized (d) {log.info("{}", i + "\t" + toSimplePrintable(d));
            }
            log.info("{}", i + "\t" + toSimplePrintable(d));
        }
    }, "t3");
    t3.start();
    t3.join();
    log.info("{}", toSimplePrintable(new Dog()));
}

打印如下





图 14