java虚拟机 synchronized锁优化

自旋锁与自适应自旋

互斥同步的时候，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发带来很大压力。同步虚拟机团队发现许多应用上锁定状态的维持时间很短，为了这段时间去挂起和恢复线程并不值得。所以当一个线程请求另一个线程的锁时，我们可以让请求线程稍等一下，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁，我们只需让请求线程执行一个忙循环(自旋),这就是所谓的自旋锁。

自旋等待的时间是有限度的，因为如果锁占用时间很长，那么自旋的线程只会白白消耗处理器资源，带来性能上的浪费，所以在JDK1.6引入了自适应的自旋锁，自适应的自旋锁自旋时间不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定，如果在同一个锁上，自旋等待刚刚获得成功，并且持有锁的线程正在运行，那么虚拟机就会认为这次自旋也很有可能获得成功，进而它将允许自旋等待持续相对更长的时间，比如100个循环，对于自旋很少成功的锁，以后获取这个锁将可能省略掉自旋过程。

JDK1.6后锁自旋默认开启。

锁消除

锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但被检查到不可能存在共享数据竞争的锁进行消除。如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行

锁粗化

我们编写代码时，推荐将同步块的作用范围限制得尽量小——只在共享的实际作用域才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快拿到锁。

如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中，即时没有线程竞争，频繁进行互斥同步操作也会导致不必要的性能损耗。

如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部。即扩展到对象第一次加锁前和最后一次加锁后。