JEP 374:禁用并弃用偏向锁

官方原文(英文)地址: https://openjdk.java.net/jeps/374
个人原创翻译,转载请注明出处。

Summary

Disable biased locking by default, and deprecate all related command-line options.

摘要

默认禁用偏向锁,并弃用所有相关的命令行选项。

Goals

Determine the need for continued support of the legacy synchronization optimization of biased locking, which is costly to maintain.

目标

确定是否需要继续支持偏向锁定的遗留同步优化,这种维护成本很高。

Motivation

Biased locking is an optimization technique used in the HotSpot Virtual Machine to reduce the overhead of uncontended locking. It aims to avoid executing a compare-and-swap atomic operation when acquiring a monitor by assuming that a monitor remains owned by a given thread until a different thread tries to acquire it. The initial lock of the monitor biases the monitor towards that thread, avoiding the need for atomic instructions in subsequent synchronized operations on the same object. When many threads perform many synchronized operations on objects used in a single-threaded fashion, biasing the locks has historically led to significant performance improvements over regular locking techniques.

动机

偏向锁是HotSpot虚拟机中使用的一种优化技术,用于减少无竞争锁定的开销。它旨在避免在获取monitor时执行CAS原子操作,具体方式是假设monitor一直归给定线程所有,直到不同的线程尝试获取它。monitor的初始锁使monitor偏向该线程,从而避免在对同一对象的后续同步操作中需要原子指令。当很多线程对以单线程方式使用的对象执行很多同步操作时,与普通锁的技术相比,偏向锁通常会导致明显的性能改进。

The performance gains seen in the past are far less evident today. Many applications that benefited from biased locking are older, legacy applications that use the early Java collection APIs, which synchronize on every access (e.g., Hashtable and Vector). Newer applications generally use the non-synchronized collections (e.g., HashMap and ArrayList), introduced in Java 1.2 for single-threaded scenarios, or the even more-performant concurrent data structures, introduced in Java 5, for multi-threaded scenarios. This means that applications that benefit from biased locking due to unnecessary synchronization will likely see a performance improvement if the code is updated to use these newer classes. Furthermore, applications built around a thread-pool queue and worker threads generally perform better with biased locking disabled. (SPECjbb2015 was designed that way, e.g., while SPECjvm98 and SPECjbb2005 were not). Biased locking comes with the cost of requiring an expensive revocation operation in case of contention. Applications that benefit from it are therefore only those that exhibit significant amounts of uncontended synchronized operations, like those mentioned above, so that the cost of executing cheap lock owner checks plus an occasional expensive revocation is still lower than the cost of executing the eluded compare-and-swap atomic instructions. Changes in the cost of atomic instructions since the introduction of biased locking into HotSpot also change the amount of uncontended operations needed for that relation to remain true. Another aspect worth noting is that applications won't have noticeable performance improvements from biased locking even when the previous cost relation is true when the time spend on synchronized operations is still only a small fraction of the total application workload.

在过去所看到的提升,在今天远没有那么明显了。很多从偏向锁中受益的应用,都是使用早期Java集合API的陈旧的遗留程序,也就是在每次访问时进行同步(例如HashtableVector)。较新的应用通常使用Java 1.2中为单线程场景引入的非同步集合(例如HashMapArrayList),或者使用Java 5中引入的性能更高的并发数据结构,多用于多线程场景。这意味着,如果更新代码以使用这些较新的类,那些由于不必要的同步而受益于偏向锁的应用可能会看到性能改善。此外,围绕线程池队列和工作线程构建的应用通常在禁用偏向锁的情况下性能更好。(SPECjbb2015就是这样设计的,等等,然而SPECjvm98和SPECjbb2005却不是。)偏向锁带来了在竞争下需要昂贵的撤销操作的成本。因此,受益的只有那些表现出大量无竞争同步操作的应用,如上述那些,因此执行廉价的锁持有者检查加上偶尔的昂贵撤销成本,仍然低于执行避免CAS原子指令的成本。自从将偏向锁定引入HotSpot以来,原子指令成本的变化也改变了该关系保持真实所需的无竞争操作的数量。另一个值得注意的方面是,即使在之前的成本关系是正确的情况下,当花费在同步操作上的时间仍然只占整个应用工作负载的一小部分时,应用也不会从偏向锁定中获得明显的性能改进。

Biased locking introduced a lot of complex code into the synchronization subsystem and is invasive to other HotSpot components as well. This complexity is a barrier to understanding various parts of the code and an impediment to making significant design changes within the synchronization subsystem. To that end we would like to disable, deprecate, and eventually remove support for biased locking.

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

Description

Prior to JDK 15, biased locking is always enabled and available. With this JEP, biased locking will no longer be enabled when HotSpot is started unless -XX:+UseBiasedLocking is set on the command line.

描述

在JDK 15之前,偏向锁始终处于启用和可用的状态。使用本JEP,除非在命令行上设置-XX:+UseBiasedLocking,否则在启动HotSpot时将不再启用偏向锁。

We will deprecate the UseBiasedLocking option and all options related to the configuration and use of biased locking.

  • Product options: BiasedLockingStartupDelay, BiasedLockingBulkRebiasThreshold, BiasedLockingBulkRevokeThreshold, BiasedLockingDecayTime and UseOptoBiasInlining
  • Diagnostic options: PrintBiasedLockingStatistics and PrintPreciseBiasedLockingStatistics

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

  • 生产选项:BiasedLockingStartupDelayBiasedLockingBulkRebiasThresholdBiasedLockingBulkRevokeThresholdBiasedLockingDecayTimeUseOptoBiasInlining
  • 诊断选项:PrintBiasedLockingStatisticsPrintPreciseBiasedLockingStatistics

The options will still be accepted and acted upon, but a deprecation warning will be issued.

这些选项仍将被接受并会生效,但将发出弃用警告。

Risk and Assumptions

Some Java applications may see a performance regression with biased locking disabled. Allowing biased locking to be re-enabled on the command line helps to mitigate this and provides possible insight into which situations may still benefit from its usage.

风险和假设

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