文章目录
偏向锁原理及其实战
偏向锁主要用来解决
无竞争下锁性能问题，在实际场景中，如果一个同步代码块（方法）没有多个线程竞争，而且总是有一个线程多次重入获取锁，并且线程每次还有阻塞线程，更改线程状态为运行状态等操作，那么此时相对于CPU是一种资源浪费，为了解决这个问题，就引入了偏向锁
1.偏向锁原理
偏向锁原理：
-
当一个线程获取了一个对象的锁时，JVM会将该对象的锁标记位设置为01，偏向位设置为1，表示该对象进入了偏向锁状态。
-
JVM会使用CAS（Compare and Swap）操作将获取锁的线程ID记录在对象的Mark Word中，如果CAS操作失败，说明有其他线程竞争获取锁。
-
当其他线程尝试获取该对象的锁时，JVM会检查对象的锁标记位和偏向位。如果锁标记位为01且偏向位为1，表示对象处于偏向锁状态，并且有线程ID记录在Mark Word中。
-
如果尝试获取偏向锁的线程ID与Mark Word中记录的线程ID相同，说明该线程仍然是获取锁的线程，可以直接进入同步代码块，无需使用CAS操作。
-
如果尝试获取偏向锁的线程ID与Mark Word中记录的线程ID不同，说明有其他线程竞争锁，此时偏向锁会自动升级为轻量级锁状态。
偏向锁的引入主要是为了优化无竞争情况下的锁性能。在无竞争的情况下，偏向锁可以避免多余的同步操作，从而提高程序的性能。然而，由于偏向锁需要记录线程ID并使用CAS操作，会引入一定的额外开销。因此，JVM会延迟启用偏向锁，只对一定时间后创建的对象进行偏向锁的开启。
虽然JVM默认开启偏向锁，但是延时 4s 开启，程序创建对象的时候并不会开启偏向锁， 4s后创建的对象才会开启偏向锁。
需要注意的是，偏向锁并不适用于具有竞争的情况，当存在多个线程竞争同一个对象的锁时，偏向锁会自动升级为轻量级锁或重量级锁，以保证线程的互斥访问和数据一致性。
2.偏向锁案例代码演示
2.1.偏向锁案例代码
注意 新版的JDK可能默认是禁用偏向锁的 ，所以需要再JVM启动参数上添加 开启偏向锁的相关代码
-XX:+UseBiasedLocking
/**
* 偏向锁
*/
public class BiasedLockDemo {
private static final Logger log = LoggerFactory.getLogger(BiasedLockDemo.class);
@Test
@DisplayName("偏向锁测试")
public void test() {
log.error("JVM详细信息: {}", VM.current().details());
// 休眠5s
SleepUtil.sleepMillis(5000);
// 创建对象
MyObjectLock myObjectLock = new MyObjectLock();
log.error("无锁情况下，lock的状态！");
myObjectLock.printLockStatus();
SleepUtil.sleepMillis(5000);
CountDownLatch latch = new CountDownLatch(1);
Runnable runnable = ()->{
// 模拟同一个线程多次进入同步代码块
for (int i = 0; i < 1000; i++) {
synchronized (myObjectLock){
myObjectLock.increase();
if (i == 1000 / 2){
log.error("占有锁情况下！lock状态！");
myObjectLock.printLockStatus();
}
}
SleepUtil.sleepMillis(10);
}
latch.countDown();
};
new Thread(runnable,"biased-thread").start();
// 等待所有枷锁线程执行完毕
try {
latch.await();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
// 等待5s 查看锁的状态
SleepUtil.sleepMillis(5000);
log.error("释放锁后锁的状态！");
myObjectLock.printLockStatus();
}
}
class MyObjectLock{
private static final Logger log = LoggerFactory.getLogger(MyObjectLock.class);
private int count = 0;
/**
* 打印当前对象的一个状态
*/
public void printLockStatus(){
log.error(ClassLayout.parseInstance(this).toPrintable());
}
/**
* 将当前共享变量自增
*/
public void increase(){
this.count++;
}
}
这里 我们分为三个部分进行说明
2.2.1.无锁情况下状态
- 对象头部分的第一个4字节（OFFSET 0）表示对象的标记字（Mark Word）。在这个结果中，标记字的十六进制表示为
05 00 00 00，对应的二进制为00000101 00000000 00000000 00000000。其中，第一个位为偏向锁标志位，为1表示启用了偏向锁。在这个结果中，偏向锁标志位为1，说明该对象启用了偏向锁。 其中 d8 f9 09 01 (11011000 11111001 00001001 00000001) (17431000)为其Class Pointer(类对象指针)- 对象头部分的第二个4字节（OFFSET 4）和第三个4字节（OFFSET 8）也是对象头信息。在这个结果中，这两个字节的值都为0，没有包含其他重要的标志位信息。
- 接下来的4字节（OFFSET 12）表示
MyObjectLock对象中的一个整型字段count。在这个结果中，count字段的值为0。 - 最后，结果显示了对象的实例大小为16字节，并且没有内部或外部的空间损失。
2.1.2.偏向锁状态
在输出MyObjectLock实例结构后，等待5s，然后启动一个线程占用偏向锁，因为输出的内容比较多，所以这里选择了到中间值的时候进行输出结构。
- 对象头部分的第一个4字节（OFFSET 0）表示对象的标记字（Mark Word）。在这个结果中，标记字的十六进制表示为
05 80 e6 c1，对应的二进制为00000101 10000000 11100110 11000001。其中，第一个位为偏向锁标志位，为1表示启用了偏向锁。在这个结果中，偏向锁标志位为1，说明该对象启用了偏向锁。 - 对象头部分的第二个4字节（OFFSET 4）和第三个4字节（OFFSET 8）也是对象头信息。在这个结果中，这两个字节的值分别为
c0 02 00 00和d8 f9 09 01。 - 接下来的4字节（OFFSET 12）表示
MyObjectLock对象中的一个整型字段count。在这个结果中，count字段的值为501。 - 最后，结果显示了对象的实例大小为16字节，并且没有内部或外部的空间损失。
2.1.3.释放锁后的状态
- 对象头部分的第一个4字节（OFFSET 0）表示对象的标记字（Mark Word）。在这个结果中，标记字的十六进制表示为
05 80 e6 c1，对应的二进制为00000101 10000000 11100110 11000001。其中，第一个位为偏向锁标志位，为1表示启用了偏向锁。在这个结果中，偏向锁标志位为1，说明该对象启用了偏向锁。 - 对象头部分的第二个4字节（OFFSET 4）和第三个4字节（OFFSET 8）也是对象头信息。在这个结果中，这两个字节的值分别为
c0 02 00 00和d8 f9 09 01。 - 接下来的4字节（OFFSET 12）表示
MyObjectLock对象中的一个整型字段count。在这个结果中，count字段的值为1000。 - 最后，结果显示了对象的实例大小为16字节，并且没有内部或外部的空间损失。
2.2.偏向锁的膨胀和撤销
假如有多个线程来竞争偏向锁，此对象锁就不会有所偏向了，其他线程发现偏向锁并不是偏向自己，就说明存在了竞争，会尝试撤销偏向锁，然后膨胀到轻量级锁。
2.2.1.偏向锁撤销的条件
- 多个线程存在竞争
- 调用偏向锁对象的obj的obj.hashCode或者System.indentityHsahCode()方法计算对象的hash码，偏向锁将会被撤销。
- 因为一个对象的哈希码只会生成一次，并且保存在Mark Word中，偏向锁的Mark Word 已经保存了线程ID,没有其他地方在保存哈希码了，所以只能撤销偏向锁
- 轻量级锁会在栈帧的Lock Record（锁记录）中记录哈希码
- 重量级锁会在监视器中记录哈希码
2.2.2.偏向锁的撤销
偏向锁的撤销的开销花费是挺大的，其大概过程如下
- JVM需要等待一个全局安全点，当JVM到达全局安全点后，所有的用户线程都是暂停的，当前持有偏向锁的用户线程也是暂停的。
- 遍历线程的栈帧，检查是否存在锁记录，如果存在锁记录，那么就清空锁记录，使其变成无锁的状态，并修复锁记录指向的线程ID，清除其线程ID
- 将当前锁升级（或碰撞）成轻量级锁，少数场景直接升级为重量级锁
- 唤醒当前线程
2.2.3.偏向锁的膨胀
如果偏向锁被占据，那么第二个线程争抢这个对象，因为偏向锁不会主动释放，所以第二个线程可以看到内置锁的偏向状态，这时JVM会检查原来持有该偏向锁线程是否存活，如果挂了，那么将该对象变为无锁状态，重新偏向，如果没挂，就发生竞争，进行膨胀。
- 当一个线程尝试获取一个偏向锁时，如果该锁的标记字（Mark Word）指向的线程ID与当前线程ID不一致，表示存在竞争，此时偏向锁需要膨胀。
- JVM会将对象的标记字从偏向锁状态修改为轻量级锁状态。这个过程称为锁的膨胀。
- 膨胀为轻量级锁的过程包括以下步骤：
- JVM会尝试使用CAS（Compare and Swap）操作将对象的标记字修改为指向锁记录的指针，同时更新锁记录中的线程ID为当前线程ID。
- 如果CAS操作成功，表示膨胀为轻量级锁成功。
- 如果CAS操作失败，说明存在竞争，此时会进一步膨胀为重量级锁。
- 膨胀为重量级锁的过程包括以下步骤：
- JVM会在堆中分配一个监视器（Monitor）对象，用于管理锁的状态。
- 将对象的标记字指向该监视器对象，并将锁记录中的线程ID修改为0。
- 此时，锁的状态变为重量级锁。
2.3.全局安全点原理和偏向锁撤销性能问题
2.3.1.全局安全点介绍
在Java虚拟机（JVM）中，全局安全点（Global Safepoint）是一个重要的概念，用于确保在某个特定的时间点，所有的线程都处于安全状态，可以被安全地中断。全局安全点的引入是为了支持一些关键操作，例如线程停止、垃圾回收等。
实现全局安全点的核心思想是在代码的特定位置插入安全点检查。安全点检查是一段特殊的机器码指令，用于判断当前线程是否到达安全点。当一个线程到达安全点时，它会被停止，并且进一步的操作需要等待其他线程也到达安全点。只有当所有线程都到达安全点时，JVM才能执行需要线程处于安全状态的操作。
全局安全点的引入是为了解决并发线程访问共享数据的一致性问题。在偏向锁撤销的过程中，JVM需要等待全局安全点的到来，以确保所有的线程都被暂停，包括持有偏向锁的线程。只有当所有线程都暂停时，JVM才能安全地撤销偏向锁，并进行相应的操作。
全局安全点的实现机制主要包括以下几个方面：
- 安全点的选定：
JVM会选择一些合适的位置作为安全点，通常是在方法调用、循环跳转等代码块的末尾。这些位置被认为是安全点，因为在这些位置上线程处于安全状态，可以被安全地中断。安全点的选定通常是通过静态分析和动态检测相结合的方式来确定的。 - 安全点的设置：
JVM会在代码中插入安全点检查的指令，用于检查当前线程是否到达安全点。这些指令通常是无操作（NOP）指令或轻量级的计算指令，不会对程序的语义产生影响。当线程执行到安全点检查指令时，会检查当前线程是否到达安全点，如果没有到达则会等待其他线程也到达安全点。 - 安全点的等待：
当一个线程到达安全点时，它会被停止，并且进一步的操作需要等待其他线程也到达安全点。只有当所有线程都到达安全点时，JVM才能执行需要线程处于安全状态的操作。线程的等待是通过自旋等待或挂起等待的方式来实现的。 - 安全点的恢复：
当所有线程都到达安全点后，JVM可以执行需要线程处于安全状态的操作。完成操作后，JVM会恢复线程的执行，使其继续执行下去。恢复线程的执行可以通过唤醒等待线程或者设置标记等方式来实现。
2.3.1 偏向锁撤销性能问题
偏向锁撤销的过程相对于偏向锁的获取和释放而言，具有较高的开销。这是因为偏向锁撤销需要等待全局安全点，并进行一系列的操作来撤销偏向锁。这些额外的操作会增加系统开销，影响性能。
偏向锁撤销的性能问题主要体现在以下几个方面：
- 全局安全点的等待时间：在偏向锁撤销过程中，JVM需要等待全局安全点的到来。这会导致线程在等待期间无法执行其他有用的工作，从而造成性能损失。
- 线程栈帧的遍历和修改：在偏向锁撤销过程中，JVM需要遍历线程的栈帧，检查是否存在锁记录，并对锁记录进行修改。这涉及到线程状态的切换和寻址操作，会增加额外的开销。
- 锁的状态转换：偏向锁撤销后，锁需要进行状态转换，通常是升级为轻量级锁或重量级锁。这种状态转换涉及到锁的标记字和锁记录的修改，可能需要进行CAS（Compare and Swap）操作，增加了额外的开销。
为了减少偏向锁撤销的性能开销，可以采取一些优化措施，例如调整全局安全点的触发频率、优化线程栈帧的遍历算法，以及采用延迟偏向锁撤销等策略。这些优化措施可以提高偏向锁的性能并减少性能损失。然而，需要注意的是，在特定的应用场景下，偏向锁的撤销可能仍然会带来一定的性能开销。因此，在设计和使用偏向锁时需要综合考虑性能与应用需求之间的平衡。
对于高并发应用来说，一般建议关闭偏向锁(JDK9之后，偏向锁默认是关闭的)
-XX:-UseBiasedLocking
4078
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
