synchronized是Java较为古老的同步实现方式,大家可能叫监视器锁,synchronized不需要显式加锁与解锁,当访问其修饰的方法或者同步块时,会自动获取锁,从生成的Java字节码来看,编译器在同步块开始的地方插入了MONITORENTER,在结束的地方插入MONITOREXIT,这可能也是监视器锁这个名字的由来。
synchronized的锁存放在每个对象的对象头的MarkWord中,在1.6之后,又增加了偏向锁的支持,减少同一线程获取锁的性能损耗。synchronized的锁状态分为无锁,偏向锁,轻量级锁,重量级锁四种。
MarkWord结构(64位 jvm):
偏向锁在同一线程获取锁时,不需要加锁与解锁,只需要判断当前对象头是否有当前线程的偏向锁,有则获取锁,若无则去判断是否设置了偏向标识,有偏向标识,则CAS设置偏向锁,无则CAS竞争锁。
偏向锁有一个撤销的过程,在一个线程获取到偏向锁之后,另外一个线程来竞争锁,会如下图所示,先暂停持有偏向锁的线程,检查线程是否活动(线程死了也暂停不了吧),如果还活动就开始升级为轻量级锁,否则重新偏向到新的线程。
轻量级锁在存在竞争的时候又会发生锁的膨胀,在轻量级锁竞争较激烈时,比如一个线程持有锁,另外一个线程在循环CAS(自旋)获取锁时,再来一个线程竞争锁,这里总不能一直自旋下去,因为比较消耗cpu,因此就升级为重量级锁。这时候竞争锁的行为就改变了,从自旋变成了阻塞。具体如下图:
最后锁只能升级,不能降级,因为在竞争激烈的情况下,自旋只会让cpu空转,啥事也没有做。
总结:偏向锁解锁和加锁不需要额外的同步消耗,但是在存在竞争时会存在撤销和升级。(单纯一个线程访问需要同步吗?除非有这样一种情况,虽然也是多个线程,但是其中一个线程多次获取同一个对象的锁,这个时候,可能会有一些性能提升。另外有人还建议直接使用-XX:-UseBiasedLocking=false关闭偏向锁)
轻量级锁用CAS,竞争时不会阻塞,但是循环CAS比较消耗CPU(基本上所有的锁(除了偏向锁),轻量级锁,重量级锁,以及互斥锁里面加锁解锁都是循环CAS,就不消耗CPU吗,其中比较合理的解释就是使用CAS是认为这个过程比较快就可以完成,如果比较慢的时候还是直接阻塞在那吧)
重量级锁的优缺点正好和轻量级相对。
参考书籍和文档:
1.《深入理解Java虚拟机》
2.《Java并发编程的艺术》