Java | synchronized 不同情况下的对象头测试

synchronized 不同情况下的对象头测试

测试环境

JDK：Oracle JDK 1.8.0_144

代码依赖：

• junit-jupiter-engine：5.8.1
• slf4j-simple：1.7.32
• jol-core：0.16

测试代码

import java.util.concurrent.TimeUnit;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.openjdk.jol.info.ClassLayout;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

class LockObject {}

class SyncTest {

	private static final Logger log = LoggerFactory.getLogger(SyncTest.class);

	@Test
  void testSynchronizedLock() throws InterruptedException {
    Object lock = new Object();
    syncLock(lock);
    Assertions.assertTrue(true);
  }

  void syncLock(Object lock) {
    log.info("加锁前 {}", ClassLayout.parseInstance(lock).toPrintable());
    synchronized (lock) {
    	log.info("加锁中 {}", ClassLayout.parseInstance(lock).toPrintable());
    }
    log.info("加锁后 {}", ClassLayout.parseInstance(lock).toPrintable());
  }
}

测试情况

这里通过改动 testSynchronizedLock 方法代码进行测试，下面的测试情况只说明改动后的 testSynchronizedLock的代码，其余代码不再说明。因为只关注对象头的变化，其余的值也省略了。

情况一：同线程直接调用

void testSynchronizedLock() throws InterruptedException {
    Object lock = new Object();
    syncLock(lock);
    Assertions.assertTrue(true);
}

执行结果为：

加锁前 0x0000000000000001 (non-biasable; age: 0)
加锁中 0x0000700007830f10 (thin lock: 0x0000700007830f10)
加锁后 0x0000000000000001 (non-biasable; age: 0)

通过结果可以看到，加锁前的对象头是 0x0000000000000001，加锁中是 0x0000700007830f10，加锁后是 0x0000000000000001。看着可能不太明白，这里简单说下 64 位 jvm 的对象头的分布情况

|--------------------------------------------------------------------------------------------------------------|
|                                              Object Header (128 bits)                                        |
|--------------------------------------------------------------------------------------------------------------|
|                        Mark Word (64 bits)                                    |      Klass Word (64 bits)    |       
|--------------------------------------------------------------------------------------------------------------|
|  unused:25 | identity_hashcode:31 | unused:1 | age:4 | biased_lock:1 | lock:2 |     OOP to metadata object   |  无锁
|----------------------------------------------------------------------|--------|------------------------------|
|  thread:54 |         epoch:2      | unused:1 | age:4 | biased_lock:1 | lock:2 |     OOP to metadata object   |  偏向锁
|----------------------------------------------------------------------|--------|------------------------------|
|                     ptr_to_lock_record:62                            | lock:2 |     OOP to metadata object   |  轻量锁
|----------------------------------------------------------------------|--------|------------------------------|
|                     ptr_to_heavyweight_monitor:62                    | lock:2 |     OOP to metadata object   |  重量锁
|----------------------------------------------------------------------|--------|------------------------------|
|                                                                      | lock:2 |     OOP to metadata object   |  GC
|--------------------------------------------------------------------------------------------------------------|

lock: 锁状态标记位，该标记的值不同，整个mark word表示的含义不同。

biased_lock：偏向锁标记，为1时表示对象启用偏向锁，为0时表示对象没有偏向锁。

从分布可以得出，看锁标记，直接看后 3 位即可

biased_lock	lock	16进制	状态
0	01	1	无锁
1	01	5	偏向
0	00	0	轻量
0	10	2	重量
0	11	3	GC

加锁前的对象头是 0x0000000000000001，加锁中是 0x0000700007830f10，加锁后是 0x0000000000000001

从这种情况可以看出：加锁前对象处于无锁状态，加锁中处于轻量锁状态，释放锁后处于无锁状态

这种现象和我们想象的可能不太一样，在网上找了资料如下：

JVM启动时会进行一系列的复杂活动，比如装载配置，系统类初始化等等。在这个过程中会使用大量 synchronized 关键字对对象加锁，且这些锁大多数都不是偏向锁。为了减少初始化时间，JVM默认延时加载偏向锁。这个延时的时间大概为 4s 左右，具体时间因机器而异。当然我们也可以设置 JVM 参数 -XX:BiasedLockingStartupDelay=0 来取消延时加载偏向锁。

从上面可以看出，JVM默认延时加载偏向锁，时间大于 4s，为了更好的验证，下面的代码直接按 10s 处理。

情况二：先获取一次锁，然后延迟 10s 再次获取

这个主要为了验证一下上面的结论

void testSynchronizedLock() throws InterruptedException {
    Object lock = new Object();
    syncLock(lock);
    TimeUnit.SECONDS.sleep(10);
    syncLock(lock);
    Assertions.assertTrue(true);
}

日志输出如下：

加锁前 0x0000000000000001 (non-biasable; age: 0)
加锁中 0x00007000028aaf10 (thin lock: 0x00007000028aaf10)
加锁后 0x0000000000000001 (non-biasable; age: 0)

加锁前 0x0000000000000001 (non-biasable; age: 0)
加锁中 0x00007000028aaf10 (thin lock: 0x00007000028aaf10)
加锁后 0x0000000000000001 (non-biasable; age: 0)

两次获取锁都使用的轻量级锁

情况三：延迟 10s 后在创建锁对象后调用

void testSynchronizedLock() throws InterruptedException {
    TimeUnit.SECONDS.sleep(10);
    Object lock = new Object();
    syncLock(lock);
    Assertions.assertTrue(true);
}

日志如下：

加锁前 0x0000000000000005 (biasable; age: 0)
加锁中 0x00007fb114010805 (biased: 0x0000001fec450042; epoch: 0; age: 0)
加锁后 0x00007fb114010805 (biased: 0x0000001fec450042; epoch: 0; age: 0)

从这种情况可以看出：加锁前对象处于偏向锁状态，加锁中处于偏向锁状态，释放锁后处于偏向锁状态，不过在加锁前，并没有偏向任何线程

情况四：增加 BiasedLockingStartupDelay=0 参数

void testSynchronizedLock() throws InterruptedException {
  Object lock = new Object();
  syncLock(lock);
  Assertions.assertTrue(true);
}

日志

加锁前 0x0000000000000005 (biasable; age: 0)
加锁中 0x00007fd650009005 (biased: 0x0000001ff5940024; epoch: 0; age: 0)
加锁后 0x00007fd650009005 (biased: 0x0000001ff5940024; epoch: 0; age: 0)

从这种情况可以看出：加锁前对象处于偏向锁状态，加锁中处于偏向锁状态，释放锁后处于偏向锁状态，不过在加锁前，并没有偏向任何线程

从上述四种情况可以得出：

默认情况 JVM 会延迟启动偏向锁功能，在 JVM 启用偏向锁功能前创建的锁对象，直接使用轻量级锁开始获取锁，而不会通过轻量级锁阶段。如果关闭延迟功能，可以使用 -XX:BiasedLockingStartupDelay=0 参数

后面的测试情况使用 TimeUnit.SECONDS.sleep(10); 来实现和 -XX:BiasedLockingStartupDelay=0 的效果

情况五：同线程多次调用

void testSynchronizedLock() throws InterruptedException {
    TimeUnit.SECONDS.sleep(10);
    Object lock = new Object();
    syncLock(lock);
    syncLock(lock);
    Assertions.assertTrue(true);
}

日志如下：

加锁前 0x0000000000000005 (biasable; age: 0)
加锁中 0x0000023099602005 (biased: 0x000000008c265808; epoch: 0; age: 0)
加锁后 0x0000023099602005 (biased: 0x000000008c265808; epoch: 0; age: 0)

加锁前 0x0000023099602005 (biased: 0x000000008c265808; epoch: 0; age: 0)
加锁中  0x0000023099602005 (biased: 0x000000008c265808; epoch: 0; age: 0)
加锁后 0x0000023099602005 (biased: 0x000000008c265808; epoch: 0; age: 0)

从日志可以看出，第一次加锁时，使用的偏向锁，加锁后偏向于 0x000000008c265808 第二次加锁时，因为还在同一线程内，偏向锁指向还是一样，则直接获取锁，不进行锁升级。

情况六：多线程无竞争两次调用

void testSynchronizedLock() throws InterruptedException {
    TimeUnit.SECONDS.sleep(10);
    Object lock = new Object();
    syncLock(lock);
    Thread thread = new Thread(() -> syncLock(lock));
    thread.start();
    thread.join();
    Assertions.assertTrue(true);
}

日志如下：

加锁前 0x0000000000000005 (biasable; age: 0)
加锁中 0x00000264e4573005 (biased: 0x00000000993915cc; epoch: 0; age: 0)
加锁后  0x00000264e4573005 (biased: 0x00000000993915cc; epoch: 0; age: 0)

加锁前 0x00000264e4573005 (biased: 0x00000000993915cc; epoch: 0; age: 0)
加锁中 0x000000d0c6dff748 (thin lock: 0x000000d0c6dff748)
加锁后 0x0000000000000001 (non-biasable; age: 0)

从日志可以看出，第一次加锁时，使用的偏向锁，第二次加锁时使用的轻量级锁（8的二进制时 1000），从中可以得出，即使没有竞争关系，只要有一个线程加过锁，那另一个线程再加锁就会变成轻量级锁，从最后一次日志可以看出，最终又变成了无锁状态

情况七：多线程无竞争很多次调用

void testSynchronizedLock() throws InterruptedException {
    TimeUnit.SECONDS.sleep(10);
    Object lock = new Object();
    syncLock(lock);
    Thread thread = new Thread(() -> syncLock(lock));
    thread.start();
    thread.join();
    syncLock(lock);
    thread = new Thread(() -> syncLock(lock));
    thread.start();
    thread.join();
    Assertions.assertTrue(true);
}

日志

加锁前 0x0000000000000005 (biasable; age: 0)
加锁中  0x0000028212c72005 (biased: 0x00000000a084b1c8; epoch: 0; age: 0)
加锁后 0x0000028212c72005 (biased: 0x00000000a084b1c8; epoch: 0; age: 0)

加锁前 0x0000028212c72005 (biased: 0x00000000a084b1c8; epoch: 0; age: 0)
加锁中 0x000000ca803fefd8 (thin lock: 0x000000ca803fefd8)
加锁后 0x0000000000000001 (non-biasable; age: 0)

加锁前 0x0000000000000001 (non-biasable; age: 0)
加锁中 0x000000cafeefc8a0 (thin lock: 0x000000cafeefc8a0)
加锁后 0x0000000000000001 (non-biasable; age: 0)

加锁前 0x0000000000000001 (non-biasable; age: 0)
加锁中  0x000000ca803ff308 (thin lock: 0x000000ca803ff308)
加锁后 0x0000000000000001 (non-biasable; age: 0)

结果就是验证了，轻量级锁是可以转换成无锁的

情况八：多线程有竞争调用

void testSynchronizedLock() throws InterruptedException {
    TimeUnit.SECONDS.sleep(10);
    Object lock = new Object();
    syncLock(lock);
    Thread thread = new Thread(() -> syncLock(lock));
    Thread thread2 = new Thread(() -> syncLock(lock));
    thread.start();
    thread2.start();

    thread.join();
    thread2.join();
    Assertions.assertTrue(true);
}

void syncLock(Object lock) {
    log.info("currentThread {}", Thread.currentThread().getId());
    log.info("加锁前 {}", ClassLayout.parseInstance(lock).toPrintable());
    synchronized (lock) {
        try {
            TimeUnit.SECONDS.sleep(10);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        log.info("加锁中 {}", ClassLayout.parseInstance(lock).toPrintable());
    }
    log.info("加锁后 {}", ClassLayout.parseInstance(lock).toPrintable());
}

日志如下：

加锁前 0x0000000000000005 (biasable; age: 0)
加锁中 0x000001b16e421005 (biased: 0x000000006c5b9084; epoch: 0; age: 0)
加锁后  0x000001b16e421005 (biased: 0x000000006c5b9084; epoch: 0; age: 0)

加锁前 0x000001b16e421005 (biased: 0x000000006c5b9084; epoch: 0; age: 0)
加锁前 0x000001b16e421005 (biased: 0x000000006c5b9084; epoch: 0; age: 0)
加锁中 0x000001b10b4f0fba (fat lock: 0x000001b10b4f0fba)
加锁后 0x000001b10b4f0fba (fat lock: 0x000001b10b4f0fba)
加锁中 0x000001b10b4f0fba (fat lock: 0x000001b10b4f0fba)
加锁后 0x000001b10b4f0fba (fat lock: 0x000001b10b4f0fba)

从日志可以看出，显示偏向，然后是重量级锁，最后没有变成无锁