某天，A同学给大家分享Java锁优化，大致内容类似 Java锁优化，有兴趣的看客大大们可以跳过去了解一波。。。
HotSpot虚拟机一路发展，花了大量精力对各种锁进行优化，通过适应性自旋、锁消除、锁粗化、轻量级锁和偏向锁等技术，提升线程间共享数据效率，以及解决竞争问题，从而提高程序的执行效率。接着介绍各种锁机制（期间还介绍HotSpot虚拟机的内存布局以及对象头Mark Word），偏向锁-->轻量级锁-->自旋锁-->重量级锁，四种锁状态会随着竞争情况逐渐升级。随后，分享的同学抛出一句：锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。
这句话引起了各位好奇宝宝们的兴趣，HotSpot JVM中为什么锁只能升级不能降级，为什么不能在竞争结束之后锁状态从重量级锁重新回到轻量级锁甚至偏向锁呢？另外，偏向锁是否可以重新偏向呢？而大多读过周大大《深入理解Java虚拟机》这边讲授虚拟机圣经级的同学则说，记得大大在书里说明过锁不能降级以及不能降级的原因。
在争论中结束了这次Java锁优化分享，毕竟咱技术人是容不得半点马虎的，所以带着这样的疑惑去查询相关资料。先有同学发现oracle介绍JRockit JVM的Understanding Locks的文档，明确说锁是可以降级的。原文如下：
A thin lock can be inflated to a fat lock and a fat lock can bedeflatedto a thin lock. The JRockit JVM uses a complex set of heuristics to determine when to inflate a thin lock to a fat lock and when to deflate a fat lock to a thin lock.
这就给好奇宝宝们很大的信心了，同是oracle旗下的JVM，而且也说了会将JRockit JVM一些优势技术移到HotSpot JVM中，那么HotSpot JVM就极有可能是支持锁降级的。又是一顿搜索，可惜只找到Evaluating and improving biased locking in the HotSpot virtual machine 这篇论文有HotSpot JVM锁降级介绍，可是毕竟不如官方文档有说服力呀！
最后，同学们摸到了R大的联系方式，R大直接抛出JEP draft: Concurrent Monitor Deflation，这篇优化提案的大致意思说目前HotSpot JVM锁是可以降级的，但是锁升降级效率较低，如果频繁升降级的话对JVM性能会造成影响。原文如下：
In its current implementation, monitor deflation is performed during every STW pause, while all Java threads are waiting at a safepoint. We have seen safepoint cleanup stalls up to 200ms on monitor-heavy-applications。
重量级锁降级发生于STW阶段，降级对象为仅仅能被VMThread访问而没有其他JavaThread访问的对象。
PS：好奇宝宝回来翻了最新版《深入理解Java虚拟机》，确实没找到锁不能降级的字眼，所以书要买新最版的
故事大概就是这样的，啰里吧嗦哔哔了一通，简单概况一下吧：
1，HotSpot JVM/JRockit JVM是支持锁降级的
2，HotSpot JVM/JRockit JVM是偏向锁是可以重偏向的（STW期间不能，补充前面留的小坑）
3，要好好学英文，要有一颗好奇的心
