问题标签 [biased-locking]

我一直在阅读有关使用 flag 的偏向锁定如何-XX:+UseBiasedLocking提高非竞争同步的性能的信息。我找不到关于它的作用以及它如何提高性能的参考。

谁能解释一下它到底是什么，或者可能指向我一些解释的链接/资源？

据我所知，对象的哈希码通常存储在对象的标题字中，例如，在 HotSpot 中可能具有以下布局：

根据HotSpotInternals -启用了偏向锁定的同步，标题字布局如下所示：

当启用偏向锁定时，如果需要，哈希码实际存储在哪里？

I am trying to make sense of the output of Java object layout on a 64-bit HotSpot VM (v8). I do not understand how the first three bit of the mark word are used which according to the commentary in the linked class file should indicated weather a biased lock or non-biased lock is set on the instance.

When I analyze an instance of Object using JOL by

I get the following output:

From HotSpot's description of the mark word (the first 8 byte), I understand that I should interpret the above bit ranges of the output as follows:

• 00:01 - Flag for lock (00 in example.)
• 02:02 - Flag for biased lock (0 in example.)
• 03:06 - Age as number of young garbage collection iterations. (0000 in example.)
• 07:07 - Unused. (Seems to be always 1.)
• 08:39 - Identity hash code. (Only after its computation, before filled with zero.)
• 40:63 - Unused. (Seems to be filled with zeros.)

Confirming this layout for the hash code range

At least for the hash code, this can be easily confirmed by computing the identity hash code and comparing the values:

where the hash code is set as the actual bit (ignoring the fact that it is only represented by 31 bit instead of 32 as the reminder is set to zero). The flags for the locks are all set to zero as expected.

Validating the layout for biased locking

The markOops also gives a layout for when an object is subject to biased locking. Here, the last two bullet points are replaced with the following ranges:

• 08:09 - Epoch bit
• 10:63 - Pointer of the thread holding this biased lock.

When I now attempt a biased lock running the following code with -XX:BiasedLockingStartupDelay=0, I can also observe how the biased lock is set. When I run the following code:

The biased lock is visible in the mark word after the initial locking as shown below:

I can validate that this is not representing the hash code as the mark word changes (the biased lock is revoked) once I invoke object.hashCode().

What I do not understand is that the flags for the biased lock and the non-biased lock are still set to zero. How does HotSpot know that this is a biased lock and not a hash code represented in the object. I additionally wonder: What does the epoch bits indicate?

当我调用object.notifyAll()一个完全不满足（可能有偏差，如果当前 JVM 允许这样做）监视器时，特别是如果没有线程实际上在监视器上等待，它是否会导致监视器重新偏置和/或通货膨胀？

最近我在读这篇文章，对“中断帧”和“编译帧”感到困惑，有什么不同？此外，它们是如何在 JVM 中生成的？

这个问题是关于偏向锁定的启发式 Java 使用之一。下一段是为未来的读者准备的；我怀疑任何能回答这个问题的人都可以安全地跳过它。

据我了解，曾几何时，人们注意到 Java 有很多线程安全的类，但它们的实例往往只被一个线程使用，因此 Sun 引入了偏向锁定来利用这一点。问题是，如果你“猜错了”并试图偏向一个需要从两个线程使用的锁，那么即使没有争用，偏向也需要撤消（“撤销”），这非常昂贵，以至于JVM 努力避免它，即使这意味着有时会错过偏向锁定可能是一个净赢的情况。

我也知道，有时 JVM 会决定执行“批量”重新偏置，并将某种类型的许多所有锁迁移到不同的线程。这个问题与此无关。出于这个问题的目的，假设我只有两个线程和一个锁。（实际情况更复杂，涉及线程池，但现在让我们忽略它。真的，假装我没有提到它。）进一步假设线程 A 运行一个无限循环，类似于“睡眠几秒钟” ，增加锁定下的整数，重复”。（这并不是真的那么无用，但这应该足以理解这一点。）同时，线程 B 运行一个类似的循环，但睡眠时间是几个小时而不是几秒钟。进一步假设调度器是神奇的并且保证永远不会有任何争用。

现在，假设我们关心线程 A 唤醒和成功增加其整数之间的平均延迟。据我了解，JVM 最初会将锁偏向 A，然后在线程 B 第一次唤醒时撤销偏向。

我的问题是：JVM 是否会意识到它最初的猜测基本上是正确的，从而再次将锁重新偏向线程 A？

我正在尝试了解偏向锁定背后的基本原理并将其设为默认值。由于阅读了这篇博文，即：

“由于大多数对象在其生命周期内最多被一个线程锁定，因此我们允许该线程将对象偏向自身”

我很困惑......为什么有人会设计一组同步的方法，只能由一个线程访问？在大多数情况下，人们专门为多线程用例设计某些构建块，而不是单线程用例。在这种情况下，没有偏差的线程的每次锁获取都是以安全点为代价的，这是一个巨大的开销！有人可以帮我理解这张照片中我缺少什么吗？

我正在编写基于 Vert.x 构建的 Clojure HTTP 库。我刚刚意识到从 Java 15 开始弃用“偏向锁定”。我知道 Vert.x 非常依赖它，我想知道是否有任何计划来解决这个问题？听起来对性能的影响将非常明显。