JVM如何处理锁

当我们谈论最新版本的Sun Hotspot Java虚拟机1.6时，当您尝试从java.util.concurrent.locks.Lock实现获取锁或输入同步块时，JVM将执行以下三种锁类型：

• 有偏见的 ：有时即使在并发系统中也没有争用，并且在这种情况下，JVM不应从OS借用互斥锁来执行锁定。 热点可以使用其自己的内部数据结构进行操作，以更有效的方式模拟锁定。 例如，如果代码的同步部分没有实时并发执行，则JVM使用CAS操作将所有者线程ID分配给Java代码中用作互斥对象的对象，并在传递CAS时另外存储重入计数。 它是有偏锁 -JVM完成的“最轻”的锁类型。 重入次数将由锁所有者线程更新，就像没有CAS的通常本地变量一样。 如果CAS失败，则意味着另一个线程已经获得了该锁，在这种情况下，JVM 停止了互斥锁所有者线程， 将线程上下文刷新到主内存中并检查重入计数。 如果为0，则JVM将锁升级为瘦型，否则升级为胖型 （我认为主要目的是等待时间，如果锁很薄，则应该很小）。 注意 Hotspot使用与用于缓存标识哈希码相同的字段在互斥对象中存储所有者线程ID。 因此，如果您一次在互斥体上检索到身份哈希码，则即使已被用作偏向锁定，它也无法用于偏向锁定。 有关偏向锁的更多信息，请参见David Dice的博客 。
• 薄 ：这是一个简单的自旋锁。 当旋转时间非常小时，它有助于节省线程上下文切换的时间。 当一个线程尝试获取占用的互斥锁时，它旋转了一段时间直到锁将被释放。 旋转次数基于内部JVM分辨率，并且可能取决于不同的因素：JVM收集的有关您的应用程序的统计信息，使用的线程数，CPU等等。 JVM确定精简锁何时变得无效，并将其升级为胖锁。
• fat ：JVM请求操作系统互斥并使用OS调度程序引擎进行线程驻留和唤醒时，“最强”的锁定类型。 它比以前的类型昂贵得多，因为在这种情况下，每次线程获取并释放锁时，JVM都应直接与OS进行交互。

参考： JVM如何处理 Slava技术博客上的 JCG合作伙伴提供的锁 。

相关文章 ：

• Erlang与Java内存架构
• Java Fork / Join进行并行编程
• Java内存模型–快速概述和注意事项
• Java中可怕的双重检查锁定成语
• Java最佳实践–队列之战和链接的ConcurrentHashMap

翻译自: https://www.javacodegeeks.com/2011/05/how-jvm-handle-locks.html