jvm锁_JVM如何处理锁

jvm锁

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

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