JEP 374：弃用并禁用偏向锁定

概括

默认情况下禁用偏向锁定，并弃用所有相关的命令行选项。

目标

确定是否需要继续支持偏向锁定的传统同步优化，维护成本高昂。

动机

偏向锁定是 HotSpot 虚拟机中使用的一种优化技术，用于减少无竞争锁定的开销。它的目的是通过假设监视器仍然由给定线程拥有，直到另一个线程尝试获取它，从而避免在获取监视器时执行比较和交换原子操作。监视器的初始锁定_使_监视器偏向该线程，从而避免在同一对象上的后续同步操作中需要原子指令。当许多线程对以单线程方式使用的对象执行许多同步操作时，偏向锁历来比常规锁定技术带来了显着的性能改进。

过去看到的性能提升如今远没有那么明显。许多受益于偏向锁定的应用程序都是较旧的遗留应用程序，它们使用早期的 Java 集合 API，这些 API 在每次访问时都进行同步（例如，Hashtable和Vector）。较新的应用程序通常使用Java 1.2 中针对单线程场景引入的非同步集合（例如，HashMap和），或者使用 Java 5 中针对多线程场景引入的性能更高的并发数据结构。ArrayList这意味着，如果代码更新为使用这些较新的类，则由于不必要的同步而受益于偏向锁定的应用程序可能会看到性能改进。此外，围绕线程池队列和工作线程构建的应用程序通常在禁用偏向锁定时性能更好。 （例如，SPECjbb2015 就是这样设计的，而 SPECjvm98 和 SPECjbb2005 则不是）。偏向锁定的代价是在发生争用时需要执行昂贵的撤销操作。因此，受益于它的应用程序只是那些表现出大量无竞争同步操作的应用程序，就像上面提到的那些，因此执行廉价的锁所有者检查加上偶尔昂贵的撤销的成本仍然低于执行所回避的比较的成本。和交换原子指令。自从 HotSpot 中引入偏向锁定以来，原子指令成本的变化也改变了保持该关系所需的无竞争操作的数量。另一个值得注意的方面是，当同步操作上花费的时间仍然只占应用程序总工作负载的一小部分时，即使先前的成本关系成立，应用程序也不会从偏向锁定中获得明显的性能改进。

偏向锁定在同步子系统中引入了大量复杂的代码，并且还会侵入其他 HotSpot 组件。这种复杂性是理解代码各个部分的障碍，也是在同步子系统内进行重大设计更改的障碍。为此，我们希望禁用、弃用并最终删除对偏向锁定的支持。

描述

在 JDK 15 之前，偏向锁定始终启用且可用。使用此 JEP，启动 HotSpot 时将不再启用偏向锁定，除非-XX:+UseBiasedLocking在命令行中设置。

我们将弃用该UseBiasedLocking选项以及与偏向锁定的配置和使用相关的所有选项。

• 产品选项：BiasedLockingStartupDelay、BiasedLockingBulkRebiasThreshold、BiasedLockingBulkRevokeThreshold、BiasedLockingDecayTime和UseOptoBiasInlining
• 诊断选项：PrintBiasedLockingStatistics和PrintPreciseBiasedLockingStatistics

这些选项仍将被接受并采取行动，但将发出弃用警告。

风险和假设

禁用偏向锁定后，某些 Java 应用程序可能会出现性能下降。允许在命令行上重新启用偏向锁定有助于缓解这种情况，并提供可能的洞察力，了解哪些情况仍然可以从其使用中受益。