synchronized笔记

synchronized是Java较为古老的同步实现方式，大家可能叫监视器锁，synchronized不需要显式加锁与解锁，当访问其修饰的方法或者同步块时，会自动获取锁，从生成的Java字节码来看，编译器在同步块开始的地方插入了MONITORENTER,在结束的地方插入MONITOREXIT，这可能也是监视器锁这个名字的由来。

synchronized的锁存放在每个对象的对象头的MarkWord中，在1.6之后，又增加了偏向锁的支持，减少同一线程获取锁的性能损耗。synchronized的锁状态分为无锁,偏向锁,轻量级锁,重量级锁四种。

MarkWord结构（64位 jvm）：

markword.png

偏向锁在同一线程获取锁时，不需要加锁与解锁，只需要判断当前对象头是否有当前线程的偏向锁，有则获取锁，若无则去判断是否设置了偏向标识，有偏向标识，则CAS设置偏向锁，无则CAS竞争锁。

偏向锁有一个撤销的过程，在一个线程获取到偏向锁之后，另外一个线程来竞争锁，会如下图所示，先暂停持有偏向锁的线程，检查线程是否活动（线程死了也暂停不了吧），如果还活动就开始升级为轻量级锁，否则重新偏向到新的线程。

偏向锁的撤销.png

轻量级锁在存在竞争的时候又会发生锁的膨胀，在轻量级锁竞争较激烈时，比如一个线程持有锁，另外一个线程在循环CAS（自旋）获取锁时，再来一个线程竞争锁，这里总不能一直自旋下去，因为比较消耗cpu，因此就升级为重量级锁。这时候竞争锁的行为就改变了，从自旋变成了阻塞。具体如下图：

轻量级锁.png

最后锁只能升级，不能降级，因为在竞争激烈的情况下，自旋只会让cpu空转，啥事也没有做。

总结：偏向锁解锁和加锁不需要额外的同步消耗，但是在存在竞争时会存在撤销和升级。（单纯一个线程访问需要同步吗？除非有这样一种情况，虽然也是多个线程，但是其中一个线程多次获取同一个对象的锁，这个时候，可能会有一些性能提升。另外有人还建议直接使用-XX:-UseBiasedLocking=false关闭偏向锁）

轻量级锁用CAS，竞争时不会阻塞，但是循环CAS比较消耗CPU（基本上所有的锁（除了偏向锁），轻量级锁，重量级锁，以及互斥锁里面加锁解锁都是循环CAS，就不消耗CPU吗，其中比较合理的解释就是使用CAS是认为这个过程比较快就可以完成，如果比较慢的时候还是直接阻塞在那吧）

重量级锁的优缺点正好和轻量级相对。

参考书籍和文档：

1.《深入理解Java虚拟机》

2.《Java并发编程的艺术》