当前位置： 文江博客 话题详情

java中的偏向锁

发布于 2025-01-08 21:25:03 字数 145 浏览 0 评论 0 原文

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

任何人都可以向我解释它到底是什么，或者可以向我指出一些解释的链接/资源吗？

原文

I keep reading about how biased locking, using the flag -XX:+UseBiasedLocking, can improve the performance of un-contended synchronization. I couldn't find a reference to what it does and how it improves the performance.

Can anyone explain me what exactly it is or may be point me to some links/resources that explains??

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（5）

岁月流歌 2025-01-15 21:25:03

本质上，如果您的对象仅由一个线程锁定，则 JVM 可以进行优化并将该对象“偏向”该线程，从而使对该对象的后续原子操作不会产生同步成本。我认为这通常适用于过于保守的代码，这些代码对对象执行锁定而不将它们暴露给另一个线程。仅当另一个线程尝试获取该对象的锁时，实际的同步开销才会出现。

它在 Java 6 中默认处于打开状态。

-XX:+UseBiasedLocking
启用一种提高无竞争同步性能的技术。对象“偏向”首先通过monitorenter字节码或同步方法调用获取其监视器的线程；在多处理器计算机上，该线程执行的后续与监视器相关的操作相对要快得多。启用此标志后，一些具有大量无竞争同步的应用程序可能会获得显着的加速；尽管已尝试将负面影响降至最低，但某些具有某些锁定模式的应用程序可能会出现速度减慢的情况。

Essentially, if your objects are locked only by one thread, the JVM can make an optimization and "bias" that object to that thread in such a way that subsequent atomic operations on the object incurs no synchronization cost. I suppose this is typically geared towards overly conservative code that performs locks on objects without ever exposing them to another thread. The actual synchronization overhead will only kick in once another thread tries to obtain a lock on the object.

It is on by default in Java 6.

-XX:+UseBiasedLocking
Enables a technique for improving the performance of uncontended synchronization. An object is "biased" toward the thread which first acquires its monitor via a monitorenter bytecode or synchronized method invocation; subsequent monitor-related operations performed by that thread are relatively much faster on multiprocessor machines. Some applications with significant amounts of uncontended synchronization may attain significant speedups with this flag enabled; some applications with certain patterns of locking may see slowdowns, though attempts have been made to minimize the negative impact.

回复 原文
对岸观火 2025-01-15 21:25:03

这还不能回答你的问题吗？

http://www.oracle.com/technetwork/java/tuning -139912.html#section4.2.5

启用一种提高无竞争性能的技术
同步。对象“偏向”首先
通过 MonitorEnter 字节码或同步获取其监视器
方法调用；随后执行的与监视器相关的操作
该线程在多处理器机器上相对要快得多。
一些具有大量无竞争的应用程序
使用此标志可以显着提高同步速度
已启用；某些具有特定锁定模式的应用程序可能会看到
经济放缓，尽管已尝试将负面影响最小化
影响。

不过我认为您会发现它在 1.6 中默认处于打开状态。使用 PrintFlagsFinal 诊断选项查看有效标志是什么。如果您正在调查服务器应用程序，请确保指定 -server，因为标志可能不同：

http: //www.jroller.com/ethdsy/entry/print_all_jvm_flags

Does this not answer your questions?

http://www.oracle.com/technetwork/java/tuning-139912.html#section4.2.5

Enables a technique for improving the performance of uncontended
synchronization. An object is "biased" toward the thread which first
acquires its monitor via a monitorenter bytecode or synchronized
method invocation; subsequent monitor-related operations performed by
that thread are relatively much faster on multiprocessor machines.
Some applications with significant amounts of uncontended
synchronization may attain significant speedups with this flag
enabled; some applications with certain patterns of locking may see
slowdowns, though attempts have been made to minimize the negative
impact.

Though I think you'll find it's on by default in 1.6. Use the PrintFlagsFinal diagnostic option to see what the effective flags are. Make sure you specify -server if you're investigating for a server application because the flags can differ:

http://www.jroller.com/ethdsy/entry/print_all_jvm_flags

回复 原文
长安忆 2025-01-15 21:25:03

我自己一直想知道偏向锁。

然而，似乎java的偏向锁在intel的nehalem处理器上比普通锁慢，并且大概在nehalem以来的两代处理器上。请参阅 http://mechanical-sympathy.blogspot.com/2011 /11/java-lock-implementations.html
在这里 http:// www.azulsystems.com/blog/cliff/2011-11-16-a-short-conversation-on-biased-locking

这里还有更多信息https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot

我一直希望有一些相对便宜的方法可以撤销对英特尔的偏见锁定，但我开始相信这是不可能的。我看过的关于如何完成的文章依赖于以下任一方法：

  1. 使用操作系统来停止
  2. 发送信号的线程，即在
  3. 具有安全点的另一个线程中运行代码，这些安全点保证在另一个线程中经常运行并等待一个信号被执行（这就是java所做的）。
  4. 具有类似的安全点，即调用返回 - 另一个线程将代码修改为断点...

I've been wondering about biased locks myself.

However it seems that java's biased locks are slower on intel's nehalem processors than normal locks, and presumably on the two generations of processors since nehalem. See http://mechanical-sympathy.blogspot.com/2011/11/java-lock-implementations.html
and here http://www.azulsystems.com/blog/cliff/2011-11-16-a-short-conversation-on-biased-locking

Also more information here https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot

I've been hoping that there is some relatively cheap way to revoke a biased lock on intel, but I'm beginning to believe that isn't possible. The articles I've seen on how it's done rely on either:

  1. using the os to stop the thread
  2. sending a signal, ie running code in the other thread
  3. having safe points that are guaranteed to run fairly often in the other thread and waiting for one to be executed (which is what java does).
  4. having similar safe points that are a call to a return - and the other thread MODIFIES THE CODE to a breakpoint...
回复 原文
长亭外，古道边 2025-01-15 21:25:03

值得一提的是，从 jdk15 开始，默认情况下将禁用偏向锁定

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

过去的性能提升如今远没有那么明显。许多受益于偏向锁定的应用程序都是较旧的遗留应用程序，它们使用早期的 Java 集合 API，这些 API 在每次访问时都进行同步（例如，Hashtable 和 Vector）。较新的应用程序通常使用 Java 1.2 中针对单线程场景引入的非同步集合（例如 HashMap 和 ArrayList），或者使用 Java 5 中针对多线程场景引入的性能更高的并发数据结构。

更远

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

是的，不再有 System.identityHashCode(o) 魔法了；)

Worth mentioning that biased locking will be disabled by default jdk15 onwards

JEP 374 : Disable and Deprecate Biased Locking

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.

Further

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.

And ya, no more System.identityHashCode(o) magic ;)

回复 原文
~没有更多了~

关于作者

拥抱没勇气

暂无简介

文章
评论
26 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

卷耳

文章 0 评论 0

佚名

文章 0 评论 0

℉服软

文章 0 评论 0

qq_2gSKZM

文章 0 评论 0

凉宸

文章 0 评论 0

gyhjy

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文