一、Monitor概念
以 32 位虚拟机为例
普通对象
Klass Word：指向对象的类型（一个指针找到它的类对象）
一个int 类型占4个字节，而一个Integer对象占8 + 4个字节
数组对象
其中 Mark Word 结构为
age：垃圾回收时的分代年龄
biased_lock：是否为偏向锁
01/00（biased_lock后一位）：加锁状态
Normal：对象正常状态
当对对象进行相应改变，如施加轻量级锁、重量级锁，GC时，相应的Mark Word Structure会发生改变
参考资料：https://stackoverflow.com/questions/26357186/what-is-in-java-object-header
1.2 Monitor概念
Monitor被翻译为监视器或管程（通常称为“锁”）
每个Java对象都可以关联一个Monitor对象（JVM提供），如果使用synchronized给对象上锁(重量级)之后,该对象头的Mark Word中就被设置指向Monitor对象的指针
Monitor结构
Owner：锁的拥有者，唯一性，当线程尝试获得锁时若有其他线程引用，则无法获得
EntryList：阻塞（等待）队列，其他线程无法获得锁时，则一起进入阻塞队列，但是一旦线程释放锁，它们是竞争获得锁（而不是先来后到）
WaitSet：存放处于wait状态的线程队列，即调用wait()方法的线程
obj对象的MarkWord结构指向Monitor对象，当t2执行到synchronized方法时，首先判断临界区代码是否加锁。
如图t2首先判断Monitor Owner是否有线程引用，无则获得锁，执行临界区代码，其他线程t1，t3则进入阻塞队列，等待t2释放锁。
-
刚开始
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中等待的线程来竞争锁，竞争的时是非公平的 -
图中
WaitSet中的Thread-0，Thread-1是之前获得过锁，但条件不满足进入WAITING状态的线程，后面讲wait-notify时会分析
synchronized必须是进入同一个对象的monitor才有上述的效果
不加synchronized的对象不会关联监视器，不遵从以上规则
1.3 sychronized原理
代码：
static final object lock = new object(); static int counter = 0; public static void main(String[] args) { synchronized (1ock) { counter++ ; } }
反编译成对应字节码
public static void main(java.lang.String[]); descriptor: ([Ljava/lang/String;)V flags: ACC_ PUBLIC, ACC_ STATIC Code: stack=2，1ocals=3, args_ size=1 . 0: getstatic #2 // <- lock引用 (synchronized开始) 3:dup 4: astore_1 // 1ock引用 -> slot 1 5: monitorenter // 将lock对象MarkWord 置为Monitor 指针 6: getstatic #3 // <-i 9: iconst_1 // 准备常数 1 10: iadd // +1 11: putstatic #3 // ->i 14: aload_1 // <- lock引用 15: monitorexit //将lock对象MarkWord 重置，唤醌EntryList 16: goto 24 //----------------下面是异常处理时，释放锁的字节码-----------------// 19: astore_2 // e->slot2 20: aload_1 // <- lock引用 21: monitorexit // 将lock对象MarkWord 重置，唤醒EntryList 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:
2.1 小故事
前言：
-
synchronized加锁是关联monitor，monitor是由操作系统提供的，成本昂贵，对程序的性能有影响。
-
从 Java6 开始对synchronized获取锁的方式进行了改进
故事角色
-
老王 - JVM
-
小南 - 线程
-
小女 - 线程
-
房间 - 对象
-
房间门上 - 防盗锁 - Monitor
-
房间门上 - 小南书包 - 轻量级锁
-
房间门上 - 刻上小南大名 - 偏向锁
-
批量重刻名 - 一个类的偏向锁撤销到达 20 阈值
-
不能刻名字 - 批量撤销该类对象的偏向锁，设置该类不可偏向
重量级锁：小南要使用房间保证计算不被其它人干扰（原子性），最初，他用的是防盗锁，当上下文切换时，锁住门。这样，即使他离开了，别人进不了门，他的工作就是安全的。但是，很多情况下没人跟他来竞争房间的使用权。小女是要用房间，但使用的时间上是错开的，小南白天用，小女晚上用。每次上锁太麻烦了，有没有更简单的办法呢？
轻量级锁：小南和小女商量了一下，约定不锁门了，而是谁用房间，谁把自己的书包挂在门口，但他们的书包样式都一样，因此每次进门前得翻翻书包（CAS操作），看课本是谁的，如果是自己的，那么就可以进门，这样省的上锁解锁了。万一书包不是自己的，那么就在门外等，并通知对方下次用锁门的方式。
后来，小女回老家了，很长一段时间都不会用这个房间。小南每次还是挂书包，翻书包，虽然比锁门省事了，但仍然觉得麻烦。
偏向锁：于是，小南干脆在门上刻上了自己的名字：【小南专属房间，其它人勿用】，下次来用房间时，只要名字还在，那么说明没人打扰，还是可以安全地使用房间。如果这期间有其它人要用这个房间，那么由使用者将小南刻的名字擦掉，升级为挂书包的方式。
批量重刻名：同学们都放假回老家了，小南就膨胀了，在 20 个房间刻上了自己的名字，想进哪个进哪个。后来他自己放假回老家了，这时小女回来了（她也要用这些房间），结果就是得一个个地擦掉小南刻的名字，升级为挂书包的方式。老王觉得这成本有点高，提出了一种批量重刻名的方法，他让小女不用挂书包了，可以直接在门上刻上自己的名字
后来，刻名的现象越来越频繁，老王受不了了：算了，这些房间都不能刻名了，只能挂书包 。
2.2 轻量级锁
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
让锁记录中Object reference指向锁对象，并尝试用cas替换Object的Mark Word,将Mark Word的值存入锁记录
CAS（Compare and Swap）:JDK提供的非阻塞原子性操作，它通过硬件保证了比较——更新操作的原子性。
如果cas(compare and swap)替换成功，对象头中存储了锁记录地址和状态00的，表示由该线程给对象加锁，这时图示如下
如果cas失败,有两种情况
-
-
如果是其它线程已经持有了该Object的轻量级锁，这时表明有竞争，进入锁膨胀过程
-
如果是自己执行了synchronized 锁重入（自己又给自己对象加锁了，见下），那么再添加一条Lock Record作为重入的计数
-
见轻量级锁示例代码：t0执行
syn method1(obj)，获得锁之后继续调用syn method2(obj)（多出来一个栈帧，见下图），两个加锁的obj是同一个对象，因此CAS失败 -
在图中的体现：对象头
lock record 地址 00在调用method1(obj)改变了，指向的是第一个栈帧的锁记录，因此第二个栈帧会CAS失败 -
Lock Record的null记录锁重入的计数，如上为1，再调用一次++
-
当退出synchronized代码块(解锁时)如果有取值为null的锁记录，表示有重入，这时重置锁记录，表示重入计数减1
-
当退出synchronized代码块(解锁时) 锁记录的值不为null,这时使用cas将Mark Word的值恢复给对象头
-
成功，则解锁成功
-
失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程
-
-
-
2.3 锁膨胀
如果在尝试加轻量级锁的过程中，CAS操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁(有竞争)，这时需要进行锁膨胀，将轻量级锁变为重量级锁。
static Object obj = new Object(); public static void method1() { synchronized( obj ) { //同步块 } }
当Thread-1进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁
这时Thread-1加轻量级锁失败，进入锁膨胀流程
- 即为Object 对象申请Monitor锁,让Object指向重量级锁地址
- 然后自己进入Monitor的EntryList BLOCKED
当Thread-0退出同步块解锁时，使用cas将Mark Word的值恢复给对象头，失败（此时锁膨胀了）。这时会进入重量级解锁流程，即按照Monitor地址找到Monitor对象，设置Owner为null，唤醒EntryList中BLOCKED线程
2.4 自旋优化
重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞
自旋：是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。
自旋重试成功的情况
自旋需要cpu资源，所以适合多核cpu
| 线程1 (cpu1上) | 对象Mark | 线程2 (cpu2上) |
|---|---|---|
| - | 10 (重量锁) | - |
| 访问同步块，获取monitor | 10 (重量锁) 重量锁指针 | - |
| 成功（加锁） | 10 (重量锁) 重量锁指针 | - |
| 执行同步块 | 10 (重量锁) 重量锁指针 | - |
| 执行同步块 | 10 (重量锁) 重量锁指针 | 访问同步块，获取monitor |
| 执行同步块 | 10 (重量锁) 重量锁指针 | 自旋重试 |
| 执行完毕 | 10 (重量锁) 重量锁指针 | 自旋重试 |
| 成功（解锁） | 无锁 | 自旋重试 |
| - | 10 (重量锁) 重量锁指针 | 成功（加锁） |
| - | 10 (重量锁) 重量锁指针 | 执行同步块 |
| - | ... | ... |
自旋重试失败的情况
| 线程1 (cpu1上) | 对象Mark | 线程2 (cpu2上) |
|---|---|---|
| - | 10 (重量锁) | - |
| 访问同步块，获取monitor | 10 (重量锁) 重量锁指针 | - |
| 成功（加锁） | 10 (重量锁) 重量锁指针 | - |
| 执行同步块 | 10 (重量锁) 重量锁指针 | - |
| 执行同步块 | 10 (重量锁) 重量锁指针 | 访问同步块，获取monitor |
| 执行同步块 | 10 (重量锁) 重量锁指针 | 自旋重试 |
| 执行同步块 | 10 (重量锁) 重量锁指针 | 自旋重试 |
| 执行同步块 | 10 (重量锁) 重量锁指针 | 自旋重试 |
| 执行同步块 | 10 (重量锁) 重量锁指针 | 阻塞 |
| - | ... | ... |
-
在Java 6之后自旋锁是自适应的，比如对象刚刚的- -次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次;反之，就少自旋甚至不自旋，总之，比较智能。
-
自旋会占用CPU时间，单核CPU自旋就是浪费，多核CPU自旋才能发挥优势。
- Java 7之后不能控制是否开启自旋功能
2.5 偏向锁
轻量级锁在没有竞争时(就自己这个线程)，每次重入仍然需要执行 CAS操作。
Java 6中引入了偏向锁来做进一步优化：只有第一次使用CAS将线程ID设置到对象的Mark Word头，之后发现这个线程ID是自己的就表示没有竞争，不用重新CAS。以后只要不发生竞争，这个对象就归该线程所有
- 升级为轻量级锁的情况 (会进行偏向锁撤销) : 获取偏向锁的时候, 发现线程ID不是自己的, 此时通过CAS替换操作, 操作成功了, 此时该线程就获得了锁对象。( 此时是交替访问临界区, 撤销偏向锁, 升级为轻量级锁)
- 升级为重量级锁的情况 (会进行偏向锁撤销) : 获取偏向锁的时候, 发现线程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 } }
个人理解偏向锁算一种无锁，因为此时没有其他线程来竞争锁，不存在重入，也就不需要考虑线程安全
偏向状态
回忆一下对象头格式
- Normal：一般状态，没有加任何锁，前面62位保存的是对象的信息，最后2位为状态（01），倒数第三位表示是否使用偏向锁（未使用：0）
- Biased：偏向状态，使用偏向锁，前面54位保存的当前线程的ID，最后2位为状态（01），倒数第三位表示是否使用偏向锁（使用：1）
- Lightweight：使用轻量级锁，前62位保存的是锁记录的指针，最后2位为状态（00）
- Heavyweight：使用重量级锁，前62位保存的是Monitor的地址指针，最后2位为状态(10)
一个对象创建时:
- 如果开启了偏向锁(Biased默认开启)，那么对象创建后，
markword值为0x05即最后3位为101,这时它的thread、epoch、 age都为0
-
偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加VM参数
-XX:BiasedLockingStartupDelay=0来禁用延迟 -
如果没有开启偏向锁（Normal），那么对象创建后，
markword值为0x01即最后3位为001,这时它的hashcode、age都为0，第一次用到hashcode时才会赋值
1) 测试延迟特性
2) 测试偏向锁
-
利用jol第三方工具来查看对象头信息(注意这里我扩展了jol让它输出更为简洁)
//添如虚拟机参数-XX:BiasedLockingStartupDelay=0 public static void main(String[] args) throws IOException { Dog d = new Dog(); ClassLayout classLayout = ClassLayout.lparseInstance(d); new Thread(() -> { log.debug("synchronized前"); System.out.println(classLayout.toPrintableSimple(true)); synchronized (d) { log.debug("synchronized中"); System.out.println(classlayout.toPrintableSimple(true)); } log.debug(" synchraoized后"); System.out.println(classLayout.toPrintablesimple(true)); }, "t1").start(); }
输出
11:08:58.117 c. TestBiased [t1] - synchronized 前 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101 11:08:58.121 C. TestBiased [t1] - synchronized 中 00000000 00000000 00000000 00000000 00011111 11101011 11010000 00000101 11:08:58.121 C. TestBiased [t1] - synchronized 后 00000000 00000000 00000000 00000000 00011111 11101011 11010000 00000101
处于偏向锁的对象解锁后,线程 id仍存储于对象头中
3) 测试禁用
在上面测试代码运行时在添加VM参数 -XX: -UseBiasedLocking 禁用偏向锁
输出
11:13:10.018 c.TestBiased [t1] - synchronized 前 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 11:13:10.021 C. TestBiased [t1] - synchronized 中 00000000 00000000 00000000 00000000 00100000 00010100 11110011 10001000 11:13:10.021 C. TestBiased [t1] - synchronized 后
4)测试hashcode
public static void main(String[] args) throws IOException { Dog d = new Dog(); d.hashcode();//调用对象hashcode，使得偏向锁禁用 ClassLayout classLayout = ClassLayout.lparseInstance(d); new Thread(() -> { log.debug("synchronized前"); System.out.println(classLayout.toPrintableSimple(true)); synchronized (d) { log.debug("synchronized中"); System.out.println(classlayout.toPrintableSimple(true)); } log.debug(" synchraoized后"); System.out.println(classLayout.toPrintablesimple(true)); }, "t1").start(); }
观察如上的MarkWord格式，Normal下的hashcode占31位，Biased下的thread:54位，装不下hashcode。所以，可偏向对象调了hashcode()后撤销偏向状态
轻量级锁：hashcode会存到线程栈帧的锁记录(lock Record)中
重量级锁：hashcode会存到monitor对象中
撤销偏锁1-调用对象hashCode
调用了对象的hashCode，但偏向锁的对象MarkWord中存储的是线程id,如果调用hashCode会导致偏向锁被撤销
-
轻量级锁会在锁记录中记录hashCode
-
重量级锁会在Monitor中记录hashCode
在调用hashCode后使用偏向锁，记得去掉-XX: -UseBiasedLocking
输出：
11:22:10.386 c.TestBiased [main] - 调用hashCode: 1778535015 11:22:10.391 c.TestBiased [t1] - synchronized 前 00000000 00000000 00000000 01101010 00000010 01001010 01100111 00000001 11:22:10.393 C. TestBiased [t1] - synchronized 中 00000000 00000000 00000000 00000000 00100000 11000011 11110011 01101000 11:22:10.393 c.TestBiased [t1] - synchronized 后 00000000 00000000 00000000 01101010 00000010 01001010 01100111 00000001
撤销偏锁2-其它线程使用对象
小故事: 线程A门上刻了名字, 但此时线程B也要来使用房间了, 所以要将偏向锁升级为轻量级锁. (线程B要在线程A使用完房间之后
(执行完synchronized代码块),再来使用; 否则就成了竞争获取锁对象, 此时就要升级为重量级锁了)
偏向锁、轻量级锁的使用条件, 都是在于多个线程没有对同一个对象进行锁竞争的前提下, 如果有锁竞争,此时就使用重量级锁。
这里演示当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁
public class Demo10 { private static void test2() throws InterruptedException { Dog d = new Dog(); Thread t1 = new Thread(() -> { synchronized (d) { log.debug(ClassLayout.parseInstance(d).toPrintableSimple(true)); } synchronized (TestBiased.class) { TestBiased.class.notify(); } //如果不用wait/notify 使用join必须打开下面的注释 //因为: t1线程不能结束，否则底层线程可能被jvm重用作为t2线程，底层线程id是一样的 /*try { System. in.read(); . } catch (IOException e) { e. printStackTrace(); }*/ }, "t1"); t1.start(); Thread t2 = new Thread(() -> { synchronized (TestBiased.class) { try { TestBiased.class.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } log.debug(ClassLayout.parseInstance(d).toPrintableSimple(true)); synchronized (d) { log.debug(Classlayout.parseInstance(d).toPrintableSimple(true)); } log.debug(Class Layout.parseInstance(d).toPrintableSimple(true)); }, "t2"); t2.start(); } }
输出：
[t1] - 0000000 00000000 00000000 0000000 00011111 .01000001 00010000 00000101 [t2] - 00000000 00000000 0000000 0000000 00011111 01000001 00010000 00000101 [t2] - 00000000 0000000 00000000 0000000 00011111 10110101 11110000 01000000 //撤销偏向锁，改为轻量级锁，保留线程id [t2] - 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 //恢复正常
撤销偏锁3-调用wait/notify
wait/notify只有重锁才有，任何线程对象调用其时，会升级位重锁
2.6 批量重偏向
如果对象虽然被多个线程访问，但没有竞争(上面撤销偏向锁就是这种情况: 一个线程执行完, 另一个线程再来执行, 没有竞争)，这时偏向了线程T1的对象仍有机会重新偏向T2,重偏向会重置对象的Thread ID
当撤销偏向锁阈值超过20次后, jvm会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至加锁线程
状态转化：
偏向锁t1 -> t2加入竞争 ->有了竞争，不符合偏向t1了 -> 对于t2，先撤销t1偏锁，再升级轻锁，然后解锁变为不可偏向状态 ->t2连续上步，达到阈值20后 -> jvm默认只有t2了，偏向t2
代码演示
public class Demo10 { public static void test() { 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.debug(i + " " + ClassLayout.parseInstance(d).toPrintableSimple(true)); } } synchronized (list) { list.notify();//唤醒list } }, "t1"); t1.start(); Thread t2 = new Thread(() -> { synchronized (list) { try { list.wait();//阻塞list，释放锁 } catch (InterruptedException e) { e.printStackTrace(); } } log.debug("===========> "); for (int i = 0; i < 30; i++) { Dog d = list.get(i); log.debug(i + " " + ClassLayout.parseInstance(d).toPrintablesimple(true)); synchronized (d) { log.debug(i + " " + ClassLayout.parseInstance(d).toPrintablesimple(true)); log.debug(i + " " + ClassLayout.parseInstance(d).toPrintableSimple(true)); } } }, "t2"); t2.start(); } }
输出
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 线程id 线程id 线程id 加锁状态 [t1] - 0 00000000 00000000 00000000 00000000 00011111 11101011 01000000 00000101 [t1] - 1 00000000 00000000 00000000 00000000 00011111 11101011 01000000 00000101 [t1] - 2 00000000 00000000 00000000 00000000 00011111 11101011 01000000 00000101 [t1] - 3 00000000 00000000 00000000 00000000 00011111 11101011 01000000 00000101 [t1] - 4 00000000 00000000 00000000 00000000 00011111 11101011 01000000 00000101 [t1] - 5 00000000 00000000 00000000 00000000 00011111 11101011 01000000 00000101 ...t1 从1到29都是加的线程id（00011111 11101011）偏向锁，状态看最后101 [t2] - ============> [t2] - 0 00000000 00000000 00000000 00000000 00011111 11101011 01000000 00000101 //原始t1的偏向锁状态 [t2] - 0 00000000 00000000 00000000 00000000 00100000 01111010 11110110 01110000 //撤销偏向锁，升级轻量级锁 [t2] - 0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001//解锁后，变为不可偏向状态 [t2] - 1 00000000 00000000 00000000 00000000 00011111 11101011 01000000 00000101 [t2] - 1 00000000 00000000 00000000 00000000 00100000 01111010 11110110 01110000 [t2] - 1 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 ... //我们发现，到了第20个的时候（从0算第1个），又变成了偏向锁状态，但是偏向的id变成了t2了 //之后所有的对象都是直接偏向的状态，而不是先撤销t1偏锁，再升级轻锁 => 批量重偏向 [t2] - 19 00000000 00000000 00000000 00000000 00011111 11101011 01000000 00000101 [t2] - 19 00000000 00000000 00000000 00000000 00011111 11101011 01010001 00000101 [t2] - 19 00000000 00000000 00000000 00000000 00011111 11101011 01010001 00000101
批量撤销
当撤销偏向锁阈值超过40次后，jvm 会这样觉得，自己确实偏向错了, 根本就不该偏向。于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的
public class Demo11 { static Thread t1, t2, t3; public static void test() { Vector<Dog> list = new Vector<>(); int loopNumber = 39; t1 = new Thread(() -> { for (int i = 0; i < loopNumber; i++) { Dog d = new Dog(); list.add(d); //39个对象加上偏向锁，偏向t1线程 synchronized (d) { log.debug(i + " " + ClassLayout.parseInstance(d).toPrintableSimple(true)); } //39个对象加完锁唤醒t2(park，unpark方式) 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);//拿出list对象 Log.debug(i + " " + ClassLayout.parseInstance(d).toPrintableSimple(true)); //对象加上偏向锁，偏向t2线程 //前19个对象是撤销t1偏向锁，之后对象是批量重偏向 synchronized (d) { Log.debug(i + " " + ClassLayout.parseInstance(d).toPrintablesimple(true)); } Log.debug(i + " " + ClassLayout.parseInstance(d).toPrintableSimple(true)); } //此时已经重偏向了20次 LockSupport.unpark(t3);//唤醒t3 }, "t2"); t2.start(); t3 = new Thread(() -> { LockSupport.park();//先阻塞自己 log.debug("============> "); for (int i = 0; i < loopNumber; i++) { Dog d = list.get(i);//拿出list对象 Log.debug(i + " " + ClassLayout.parseInstance(d).toPrintableSimple(true)); //对象加上偏向锁，偏向t3线程 //前19个对象是撤销t2偏向锁，注意：之后对象也是撤销t2偏锁，没那么多机会重偏向锁了 synchronized (d) { Log.debug(i + " " + ClassLayout.parseInstance(d).toPrintablesimple(true)); } Log.debug(i + " " + ClassLayout.parseInstance(d).toPrintableSimple(true)); } //最后撤销偏向锁达到39次 }, "t3"); t3.start(); t3.join(); /* 当撤销偏向锁阈值超过40次后，jvm会这样觉得，自己确实偏向错了，根本就不该偏向。 于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的，所以new Dog()是不可偏向的 */ Log.debug(ClassLayout.parseInstance(new Dog()).toPrintableSimple(true)); } }
批量重偏向与撤销是针对类的优化与对象无关
锁消除
- 线程同步的代价是相当高的，同步的后果是降低并发性和性能。
- 在动态编译同步块的时候，JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。
- 如果没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除。
案例：
@Fork(1) @BenchmarkMode(Mode.AverageTime) @Warmup(iterations = 3) @Measurement(iterations = 5) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class Demo12 { static int x = 0; @Benchmark public void a() throws Exception { x++; } @Benchmark //JIT 即时编译器 //对热点代码(如循环)，超过一定阈值，对代码进行优化 public void b () throws Exception { object o = new object();//o对象是b()的局部变量，没有竞争 //加锁和不加锁都一样，所以实际执行时JIT就把锁消除了 synchronized (o) { x++; } } }
java -jar benchmarks.jar（打包执行）
Benchmark Mode Samples Score Score error Units c.i. MyBenchmark. a avgt 5 1.542 0.056 ns/op c.i. MyBenchmark. b avgt 5 1.518 0.091 ns/op //score值，方法执行时间，越小性能越高，可以看出差不多的
java -XX:-EliminateLocks -jar benchmarks.jar 关闭锁消除
Benchmark Mode Samples Score Score error Units c.i. MyBenchmark. a avgt 5 1.542 0.018 ns/op c.i. MyBenchmark. b avgt 5 16.976 1.572 ns/op
2.7 总结
- synchronized锁原来只有重量级锁，依赖操作系统的mutex指令，需要用户态和内核态切换，性能损耗十分明显
- 重量级锁 要用到monitor对象，而偏向锁则在Mark Word记录线程ID进行对比，重量级锁则是拷贝Mark Word到Lock Record，用CAS +自旋的方式获取。
- 引用了偏向锁和轻量级锁，就是为了在不同的使用场景使用不同的锁，进而提高效率。
- 锁只有升级，没有降级
- 只有一个线程进入临界区，偏向锁
- 多个线程交替进入临界区，轻量级锁
- 多个线程同时进入临界区，重量级锁