Java juc系列2 —— synchronized关键字
JDK1.5后的synchronized
Java多线程 synchronized关键字的用法
我们都知道synchronized时Java中的一种锁,他可以锁对象,锁方法,锁代码块。
下面是个简单的例子。
public class Test {
public static void main(String[] args) {
test1();
test2();
test3();
}
public synchronized static void test1() {
doSomething();
}
public static void test2() {
synchronized (Test.class) {
doSomething();
}
}
public static void test3() {
synchronized (new A()) {
doSomething();
}
}
public static void doSomething() {}
static class A {}
}
JAVA对象组成结构
在说synchronized关键字之前,我们先来说说一个对象在JVM中的简单构成。
首先介绍一个工具:
我们使用这个类可以看到一个Java对象的完整布局。
具体使用图下:
public class Test {
public static class User {
String Name;
boolean sex;
}
public static void main(String[] args) {
User user = new User();
System.out.println("hashCode: "+Integer.toHexString(user.hashCode()));
System.out.println(ClassLayout.parseInstance(user).toPrintable());
}
}
我们定义了一个User对象,它有两个成员变量:String和boolean。
接下来直接运行:控制台的输出如下
hashCode: 15db9742
com.example.Test$User object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 42 97 db (00000001 01000010 10010111 11011011) (-610844159)
4 4 (object header) 15 00 00 00 (00010101 00000000 00000000 00000000) (21)
8 4 (object header) 43 c0 00 f8 (01000011 11000000 00000000 11111000) (-134168509)
12 1 boolean User.sex false
13 3 (alignment/padding gap)
16 4 java.lang.String User.Name null
20 4 (loss due to the next object alignment)
Instance size: 24 bytes
Space losses: 3 bytes internal + 4 bytes external = 7 bytes total
这里暂时我们只需要看前面两行的(object header).
有人会说,为什么这里我们User对象的对象头只有12个字节?
首先我们这里讨论的是win X64JVM,X86的结构不同是很正常的
win X64JVM默认开启了指针压缩,你可以使用JVM运行参数-XX:-UseCompressedOops来禁用指针压缩
如果你禁用了指针压缩,控制台的输出如下:
hashCode: 15db9742
com.example.Test$User object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 42 97 db (00000001 01000010 10010111 11011011) (-610844159)
4 4 (object header) 15 00 00 00 (00010101 00000000 00000000 00000000) (21)
8 4 (object header) 80 0a 39 1c (10000000 00001010 00111001 00011100) (473500288)
12 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
16 1 boolean User.sex false
17 7 (alignment/padding gap)
24 8 java.lang.String User.Name null
Instance size: 32 bytes
Space losses: 7 bytes internal + 0 bytes external = 7 bytes total
这样就变成你熟悉的对象头16字节了。
为什么我们这里只讨论前面的两行(即前64位),我们掏出hotspot虚拟机源码:markOop.hpp来看,这里我们选取一部分代码:
// The markOop describes the header of an object.
//
// Note that the mark is not a real oop but just a word.
// It is placed in the oop hierarchy for historical reasons.
//
// Bit-format of an object header (most significant first, big endian layout below):
//
// 32 bits:
// --------
// hash:25 ------------>| age:4 biased_lock:1 lock:2 (normal object)
// JavaThread*:23 epoch:2 age:4 biased_lock:1 lock:2 (biased object)
// size:32 ------------------------------------------>| (CMS free block)
// PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object)
//
// 64 bits:
// --------
// unused:25 hash:31 -->| unused:1 age:4 biased_lock:1 lock:2 (normal object)
// JavaThread*:54 epoch:2 unused:1 age:4 biased_lock:1 lock:2 (biased object)
// PromotedObject*:61 --------------------->| promo_bits:3 ----->| (CMS promoted object)
// size:64 ----------------------------------------------------->| (CMS free block)
//
// unused:25 hash:31 -->| cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && normal object)
// JavaThread*:54 epoch:2 cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && biased object)
// narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ----->| (COOPs && CMS promoted object)
// unused:21 size:35 -->| cms_free:1 unused:7 ------------------>| (COOPs && CMS free block)
在这里我们可以直接看到hotspot虚拟机在64位和32位系统上对象头的区别。
其中64bits (normal object,普通对象)写的很明白:
- 低2位表示lock(锁标志位)
- 低3位表示biased_lock(偏向锁标志位)
- 低4位到低7位表示age(分代年龄)
- 低8位unused(未使用)
- 低9位以上的31位,即到39位表示hash(存放hashcode)
- 剩余25位unused(未使用)
这里我们联系上面的代码来验证一下:
我们控制台的输出的前两行如下:
00000001——>01000010——>10010111——>11011011——>
00010101——>00000000——>00000000——>00000000
这里我们注意一下二进制的低位顺序是按箭头方向
对比上面的注释再看:
- 低2位(00)表示锁状态
- 低3位(0)表示偏向锁标志位
- 低4位到低7位(0000)表示分代年龄
- 低8位(0)未使用
- 低9位以上的31位(01000010 10010111 11011011 0010101
注意最后8位的高位0不是
)表示hashcode,我们把它转化成16进制再看:(42 97 db 15),我们把它从高位到地位写:15db9742,这个不就是我们的user对象的hashCode的十六进制嘛。
如果我们对象加锁,那么它的这64bit代表的含义就会发生变化。继续看64bits (biased object,偏向对象)
- 低2位表示lock(锁标志位)
- 低3位表示biased_lock(偏向锁标志位)
- 低4位到低7位表示age(分代年龄)
- 低8位unused(未使用)
- 低9位到低10位表示epoch
- 剩余54位表示JavaThread*(指向Java线程帧栈的指针)
这个我们下面会详细说。
对象的多种锁状态
好了又来了,又有三种锁要记了。。
别慌,听我把整个过程详细讲解一遍你就都懂了。
其实我们说的这么多锁准确来是不说不同的锁,而是对象为了获取锁而产生的不同状态。
这里就涉及到了锁的升级:
- 对象想要获取锁会依次尝试偏向锁,轻量级锁,自旋锁最后采用重量级锁。这个过程我们在下面详细阐述。
所以,锁的升级过程:
- 无锁—>偏向锁—>轻量级锁 —>自旋锁—>重量级锁
为什么要采用锁的升级?
- JVM会尝试为对象采用最低代价的锁,以此来增加性能(仅适用于JDK1.5之后)
锁的升级过程
这里我们总结一下markOop.hpp里面的注释,为了下面更好的理解,这里我们选择图表
无锁—>偏向锁
- 1.当一个线程开始使用对象时,如果这个对象是无锁状态,即图表中锁状态位为“01”,偏向锁标志位为“0”时,JVM首先会尝试在此对象上加上偏向锁
- 2.JVM会将对象的偏向锁标志位设置为1,在线程的栈中新建一块锁记录(Lock Record)的空间,将原对象头中的数据(hashcode,31bit)复制一份副本到锁记录空间中,将JavaThread指针指向占有该对象的线程。值得一提的是,这个过程JVM是采用CAS(有点像你们熟悉的乐观锁机制)实现的,所以还剩下的epoch当然就是时间戳(也可能是version,明白就好)啦。
- 3.如果CAS更新JavaThread指针失败,代表该锁已经被其他线程抢占,此时会触发偏向锁升级。
一些扩展的点:
- 对于某个只可能被同一个线程使用的锁,加偏向锁性能消耗是所有锁中最小的(因为只需要判断锁当前处于偏向锁状态且Thread指针指向当前线程就行了)。当同一个线程再次访问对象时,如果已经占有这个锁,那什么都不需要做就能直接使用了。
- 默认JDK1.6之后开启此锁,并且是延时开启(好像是8秒?记不太清了)。至于原因我想你们应该知道了:偏向锁加锁采用CAS,JVM刚启动线程较多,可能会产生CAS多次失败的情况,反而降低了性能。
这样,该对象就已经被线程占有了。值得一提的是,由于JVM的偏向锁加锁是采用CAS机制,所以在单线程访问该对象时性能较高(自己抢到的锁后面直接用呀)。
偏向锁—>轻量级锁
- 1.当多个线程访问有偏向锁的对象时(同理判断锁状态位和偏向锁标志位),此时就会发生偏向锁的升级(需要占用锁的线程将锁markword中的JavaThread指针修改为当前占有锁的线程帧栈指针,以此来区分该锁已经升级为轻量级锁)。
- 2.每个试图抢占轻量级锁的线程会在线程的栈中新建一块锁记录(Lock Record)的空间,将原对象头中的数据(61bit)复制一份副本到锁记录空间中,用来备份对象即将被覆盖的数据,因为一会儿要把对象头中原来存放hashCode和分代年龄的位置挪出来放别的地方啦。
- 3.此时再次使用CAS来更新线程帧栈指针,使其指向线程栈的锁记录空间。如果更新成功了,那么此时的对象就是轻量级锁状态。如果更新失败则表明这个对象已经被其他线程抢占了,此时就会继续发生锁升级(因为频繁的CAS降低了性能)。
轻量级锁 —>自旋锁(某种意义上这只是一种自旋的状态,并不叫锁)
如果轻量级锁占有失败,此时会进入自旋锁(有些文献中不把这个定义为新的锁类型,只是说处于自旋状态)
什么是自旋状态?看下面这个伪代码,这就是经典的自旋。所谓自旋就是循环等待,直到抢占锁为止
public void waitLock(){
while(true){
if(flag){
//抢占到锁
break;
}else{
//继续等待
}
}
}
那有人就要问了,你这总是循环,岂不是白白浪费了CPU资源?
这里我们就需要引入线程内核态
和用户态
的切换了。
-- 当线程运行时是处于用户态的,而线程因为某些原因阻塞(常见的IO)会转而进入内核态。
-- 这两个状态之间的转换其实就是线程从运行到阻塞之间的切换,而这种转换过程其实是是非消耗性能的。
-- 如果线程抢占轻量级锁失败,并且等待时间可能不是很长的情况下,此时直接进入重量级锁会导致所有
等待的线程进入阻塞状态,即用户态转换到内核态,在抢占到锁之后又会从内核态转换到用户态,整个
过程是比较消耗性能的。
现在你明白为什么需要有自旋状态了把。
但是自旋状态也是有缺点的:
- 1.如果处于自旋状态时间过长,即处于近似死循环状态,对CPU的压力会比较大,持续消耗CPU资源。因此如果自旋时间超时,就会进入下一个升级阶段,升级至重量级锁。
- 2.抢占自旋锁是非公平(原因:内核态用户态切换代价大,公平抢占可能会唤醒已经park的线程导致性能降低,而非公平则不会有这种情况)的,也就是会导致
线程饥饿
:有线程迟迟抢占不到锁。
自旋锁—>重量级锁
重量级锁就是所有锁里面锁代价最高的,他是依靠系统内核的提供的锁来实现的,即使用系统调用,当然性能不会高到哪里去。就好比之前的锁都是你自己解决问题,现在不行了,还需要别人帮助解决,解决了之后还得教会你才行。
这种情况下monitor互斥量指针中会存放指向c++互斥量的指针。
JDK1.5之前的synchronized之所以性能低,就是因为他的底层其实就是这个锁。
说是底层内核实现,要研究我们当然就得看c/c++代码了:
这个类叫objectMontor.cpp,这里我们摘选这个类的构造函数看一下:
ObjectMonitor() {
_header = NULL;
_count = 0;
_waiters = 0,
_recursions = 0; // 递归次数/重入次数
_object = NULL; // 存储Monitor关联对象
_owner = NULL; // 记录当前持有锁的线程ID
_WaitSet = NULL; // 存放处于等待状态的线程 如Java中lock.wait()使线程进入该集合
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ; // 当前monitor没有线程占有时,所有预抢占线程会到该集合中竞争
FreeNext = NULL ;
_EntryList = NULL ; // 存放因为等待锁而阻塞的线程
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
_previous_owner_tid = 0;
}
~ObjectMonitor() {
// TODO: Add asserts ...
// _cxq == 0 _succ == NULL _owner == NULL _waiters == 0
// _count == 0 _EntryList == NULL etc
}
这个其实跟AQS是有点类似的,简单看一下主要成员变量就行,深究就不用了。
synchronized和Lock
最后我们在讨论一下synchronized和Lock的区别。
- synchronized是关键字,你除了直接用啥都做不了。Lock是个类,你可以用它的很多方法。
- synchronized都是底层帮我们实现了(什么时候获取锁,什么时候释放锁)。Lock需要你自己去做。
- synchronized是非公平锁。Lock有公平锁实现类。
总的来说就是:Lock比synchronized功能丰富,什么对象你都可以设置,甚至你可以自定义一个锁。