并发编程:synchronized 锁升级过程的验证
关于synchronized关键字以及偏向锁、轻量级锁、重量级锁的介绍广大网友已经给出了太多文章和例子,这里就不再重复了,也可点击链接来回顾一下。在这里来实战操作一把,验证JVM是怎么一步一步对锁进行升级的,这其中有很多值得思考的地方。
需要关注的点:
JDK8偏向锁默认是开启的,不过JVM启动后有4秒钟的延迟,所以在这4秒钟内对家加锁都直接是轻量级锁,可用-XX:BiasedLockingStartupDelay=0 关闭该特性
测试用的JDK是64位的,所以获取对象头的时候是用unsafe.getLong,来获取对象头Markword的8个字节,如果你是32位则用unsafe.getInt替换即可
hashCode方法会对偏向锁造成影响(这里的hashCode特指identity hashcode,如果锁对象重载过hashCode方法则不会影响)
剩下的,我们直接代码里来相见:
public class SynchronizedTest {
public static void main(String[] args) throws Exception {
// 直接休眠5秒,或者用-XX:BiasedLockingStartupDelay=0关闭偏向锁延迟
Thread.sleep(5000);
// 反射获取sun.misc的Unsafe对象,用来查看锁的对象头的信息
Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
theUnsafe.setAccessible(true);
final Unsafe unsafe = (Unsafe) theUnsafe.get(null);
// 锁对象
final Object lock = new Object();
// TODO 64位JDK对象头为 64bit = 8Byte,如果是32位JDK则需要换成unsafe.getInt
printf("1_无锁状态:" + getLongBinaryString(unsafe.getLong(lock, 0L)));
// 如果不执行hashCode方法,则对象头的中的hashCode为0,
// 但是如果执行了hashCode(identity hashcode,重载过的hashCode方法则不受影响),会导致偏向锁的标识位变为0(不可偏向状态),
// 且后续的加锁不会走偏向锁而是直接到轻量级锁(被hash的对象不可被用作偏向锁)
// lock.hashCode();
// printf("锁对象hash:" + getLongBinaryString(lock.hashCode()));
printf("2_无锁状态:" + getLongBinaryString(unsafe.getLong(lock, 0L)));
printf("主线程hash:" +getLongBinaryString(Thread.currentThread().hashCode()));
printf("主线程ID:" +getLongBinaryString(Thread.currentThread().getId()) + "\n");
// 无锁 --> 偏向锁
new Thread(() -> {
synchronized (lock) {
printf("3_偏向锁:" +getLongBinaryString(unsafe.getLong(lock, 0L)));
printf("偏向线程hash:" +getLongBinaryString(Thread.currentThread().hashCode()));
printf("偏向线程ID:" +getLongBinaryString(Thread.currentThread().getId()) + "\n");
// 如果锁对象已经进入了偏向状态,再调用hashCode(),会导致锁直接膨胀为重量级锁
// lock.hashCode();
}
// 再次进入同步快,lock锁还是偏向当前线程
synchronized (lock) {
printf("4_偏向锁:" +getLongBinaryString(unsafe.getLong(lock, 0L)));
printf("偏向线程hash:" +getLongBinaryString(Thread.currentThread().hashCode()));
printf("偏向线程ID:" +getLongBinaryString(Thread.currentThread().getId()) + "\n");
}
}).start();
Thread.sleep(1000);
// 可以看到就算偏向的线程结束,锁对象的偏向锁也不会自动撤销
printf("5_偏向线程结束:" +getLongBinaryString(unsafe.getLong(lock, 0L)) + "\n");
// 偏向锁 --> 轻量级锁
synchronized (lock) {
// 对象头为:指向线程栈中的锁记录指针
printf("6_轻量级锁:" + getLongBinaryString(unsafe.getLong(lock, 0L)));
// 这里获得轻量级锁的线程是主线程
printf("轻量级线程hash:" +getLongBinaryString(Thread.currentThread().hashCode()));
printf("轻量级线程ID:" +getLongBinaryString(Thread.currentThread().getId()) + "\n");
}
new Thread(() -> {
synchronized (lock) {
printf("7_轻量级锁:" +getLongBinaryString(unsafe.getLong(lock, 0L)));
printf("轻量级线程hash:" +getLongBinaryString(Thread.currentThread().hashCode()));
printf("轻量级线程ID:" +getLongBinaryString(Thread.currentThread().getId()) + "\n");
}
}).start();
Thread.sleep(1000);
// 轻量级锁 --> 重量级锁
synchronized (lock) {
int i = 123;
// 注意:6_轻量级锁 和 8_轻量级锁 的对象头是一样的,证明线程释放锁后,栈帧中的锁记录并未清除,如果方法返回,锁记录是否保留还是清除?
printf("8_轻量级锁:" + getLongBinaryString(unsafe.getLong(lock, 0L)));
// 在锁已经获取了lock的轻量级锁的情况下,子线程来获取锁,则锁会膨胀为重量级锁
new Thread(() -> {
synchronized (lock) {
printf("9_重量级锁:" +getLongBinaryString(unsafe.getLong(lock, 0L)));
printf("重量级线程hash:" +getLongBinaryString(Thread.currentThread().hashCode()));
printf("重量级线程ID:" +getLongBinaryString(Thread.currentThread().getId()) + "\n");
}
}).start();
// 同步块中睡眠1秒,不会释放锁,等待子线程请求锁失败导致锁膨胀(见轻量级加锁过程)
Thread.sleep(1000);
}
Thread.sleep(500);
}
private static String getLongBinaryString(long num) {
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 64; i++) {
if ((num & 1) == 1) {
sb.append(1);
} else {
sb.append(0);
}
num = num >> 1;
}
return sb.reverse().toString();
}
private static void printf(String str) {
System.out.printf("%s%n", str);
}
}
运行结果如下:
1_无锁状态:0000000000000000000000000000000000000000000000000000000000000101
2_无锁状态:0000000000000000000000000000000000000000000000000000000000000101
主线程hash:0000000000000000000000000000000001001010010101110100011110010101
主线程ID:0000000000000000000000000000000000000000000000000000000000000001
3_偏向锁:0000000000000000000000000000000000011110001001011110100000000101
偏向线程hash:0000000000000000000000000000000001001011010110110100011011111101
偏向线程ID:0000000000000000000000000000000000000000000000000000000000001010
4_偏向锁:0000000000000000000000000000000000011110001001011110100000000101
偏向线程hash:0000000000000000000000000000000001001011010110110100011011111101
偏向线程ID:0000000000000000000000000000000000000000000000000000000000001010
5_偏向线程结束:0000000000000000000000000000000000011110001001011110100000000101
6_轻量级锁:0000000000000000000000000000000000000011000110101111010010110000
轻量级线程hash:0000000000000000000000000000000001001010010101110100011110010101
轻量级线程ID:0000000000000000000000000000000000000000000000000000000000000001
7_轻量级锁:0000000000000000000000000000000000011110101101101111010010001000
轻量级线程hash:0000000000000000000000000000000000011000010110111010100010100100
轻量级线程ID:0000000000000000000000000000000000000000000000000000000000001011
8_轻量级锁:0000000000000000000000000000000000000011000110101111010010110000
9_重量级锁:0000000000000000000000000000000000000011010010101110000100011010
重量级线程hash:0000000000000000000000000000000000111101101111111101111111000111
重量级线程ID:0000000000000000000000000000000000000000000000000000000000001100
现在依此来看下各个状态:
1_无锁状态:通过结果可以看到:对象的hashCode为0,gc分代年龄也是0,偏向锁标志位为1(表示可偏向状态),锁标志位为01
2_无锁状态:如果不执行hashCode方法,则跟1_无锁状态一致,否则为:0000000000000000000000000100101001010111010001111001010100000001
偏向锁标志位为0,表示不可偏向状态,这里网友们大多有误解,实际应该为:偏向锁标志位表示的是当前锁是否可偏向3_偏向锁:子线程首次获取锁,则锁偏向子线程
4_偏向锁:子线程是否锁后再次获取锁,JVM检测到锁是偏向子线程的,所以直接获取
5_偏向线程结束:偏向的线程结束后,锁对象的对象头没有改变,所以偏向锁也不会自动撤销(这里JDK团队是否可以做优化呢?还是说线程根本就没记录哪些锁偏向了自己,所以退出的时候也没法一一撤销)
6_轻量级锁:如果锁已经偏向了一个线程,则其他现在来获取锁,则需要升级为轻量级锁
7_轻量级锁:只要没有多个线程同一时刻来竞争锁,则多个线程可以轮流使用这把轻量级锁(使用完后会及时释放,CAS替换Markword)
8_轻量级锁、9_重量级锁:主线程先获取轻量级锁,在持有锁的同时,创建一个子线程来获取同一把锁,这时候有了锁的竞争,则会升级为重量级锁
注意:
如果把代码里的第一行或者第二行lock.hashCode();注释掉的话,则执行的结果完全就不同了,也可从结果验证上文提到的hashCode对偏向锁的影响。
还剩一个问题:
网上经常能看到的一张对象头布局图,其中偏向锁状态时Markword存储的是:线程ID + Epoch + 分代年龄 + 1 + 01
但是,我在程序中验证了,锁对象处于偏向锁的状态时,Markword存储的内容既不是线程ID也不是线程对象的hashCode,这个问题很奇怪,目前还没找到原因所在。
并发编程:synchronized 锁升级过程的验证的更多相关文章
- 详细了解 synchronized 锁升级过程
前言 首先,synchronized 是什么?我们需要明确的给个定义--同步锁,没错,它就是把锁. 可以用来干嘛?锁,当然当然是用于线程间的同步,以及保护临界区内的资源.我们知道,锁是个非常笼统的概念 ...
- 关于Synchronized的偏向锁,轻量级锁,重量级锁,锁升级过程,自旋优化,你该了解这些
前言 相信大部分开发人员,或多或少都看过或写过并发编程的代码.并发关键字除了Synchronized(如有不懂请移至传送门,关于Synchronized的偏向锁,轻量级锁,重量级锁,锁升级过程,自旋优 ...
- Synchronized锁升级原理与过程深入剖析
Synchronized锁升级原理与过程深入剖析 前言 在上篇文章深入学习Synchronized各种使用方法当中我们仔细介绍了在各种情况下该如何使用synchronized关键字.因为在我们写的程序 ...
- synchronized锁升级详细过程
java对象头由3部分组成: 1.Mark Word 2.指向类对象(对象的class对象)的指针 3.数组长度(数组类型才有) 重点是 Mark Word结构,下面以32位HotSpot为例: 一. ...
- 再谈synchronized锁升级
在图文详解Java对象内存布局这篇文章中,在研究对象头时我们了解了synchronized锁升级的过程,由于篇幅有限,对锁升级的过程介绍的比较简略,本文在上一篇的基础上,来详细研究一下锁升级的过程以及 ...
- Java并发编程:锁的释放
Java并发编程:锁的释放 */--> code {color: #FF0000} pre.src {background-color: #002b36; color: #839496;} Ja ...
- 5.并发编程-synchronized 细节说明
并发编程-synchronized 细节说明 1. synchronized-锁重入 & 异常释放锁 说明 * 关键字synchronized 拥有锁重入的功能,也就是在使用synchroni ...
- Synchronized锁升级
Synchronized锁升级 锁的4中状态:无锁状态.偏向锁状态.轻量级锁状态.重量级锁状态(级别从低到高) 为什么要引入偏向锁? 因为经过HotSpot的作者大量的研究发现,大多数时候是不存在锁竞 ...
- 深入并发锁,解析Synchronized锁升级
这篇文章分为六个部分,不同特性的锁分类,并发锁的不同设计,Synchronized中的锁升级,ReentrantLock和ReadWriteLock的应用,帮助你梳理 Java 并发锁及相关的操作. ...
随机推荐
- AJAX经常遇到的那些问题
本文主要介绍了AJAX工作原理以及在面试题经常会遇到的问题,目录如下: 什么是Ajax 为什么要使用Ajax? Ajax特点? AJAX优缺点? Ajax流程? XMLhttprequest对象 AJ ...
- Http协议以及模拟http请求发送数据
1 为什么要使用http协议 假设我现在有两个客户端浏览器,一个是google,一个是IE浏览器:我现在有两个服务器,一个是tomcat,一个是JBoss;在最初的情况下是:如果google要往tom ...
- ubuntu中解决/usr/bin/ld: cannot find -lxxx
解决/usr/bin/ld: cannot find -lxxx 在linux环境编译应用程式或lib的source code时常常会出现如下的错误讯息:/usr/bin/ld: cannot fin ...
- cygwin主要命令
基本操作命令: ---------------------------------------------------------------------- --------------------- ...
- git branch简单使用
1,branch的建立及使用git clone user@192.168.0.136:/media/projiect/omap4/nexttab/kernel kernel/android3.0/ ...
- Error creating form bean of class com.onlinebookstore.presentation.CatalogBean
Error creating form bean of class com.onlinebookstore.presentation.CatalogBean 可能是action form未编译 这个问 ...
- C# 写 LeetCode easy #28 Implement strStr()
28.Implement strStr() Implement strStr(). Return the index of the first occurrence of needle in hays ...
- RDS mysql 与ECS自建mysql做主从备份
由于公司要组建一个数据中心,简而言之就是把各个地方的数据都同步到一个地方,做BI建模和数据分析. 一般来说这种需求是由hadoop来实现的,但由于预算不够..所以,来个low点的办法吧 以下主要是讲r ...
- Syslog+Fluentd+InfluxDB日志收集系统搭建
环境配置 节点 配置 类型 操作系统 Sched 2G 2CPU 50GB ens3=>192.168.200.11 KVM虚拟机 CentOS 7 Nova 4G 2CPU 50GB ens3 ...
- Python中配置文件解析模块-ConfigParser
Python中有ConfigParser类,可以很方便的从配置文件中读取数据(如DB的配置,路径的配置).配置文件的格式是: []包含的叫section, section 下有option=value ...