多线程请求时同步锁授予顺序？

Posted 2023-02-16

【中文标题】多线程请求时同步锁授予顺序？

【英文标题】：synchronized lock grant order when multiple thread ask for it?

【发布时间】：2014-02-28 17:03:06

【问题描述】：

当一个线程已经获得锁时，当多个线程尝试在同步时获得锁。 我的理解是锁将按照获取锁请求的顺序给出。

但是根据 O'Reilly 的书，Java 线程锁将被给予最适合平台的。那是非常抽象的陈述。我认为平台在这里主要是指操作系统。 我的问题是基于哪个 JVM 决定什么最适合平台以及开发人员如何计算它的标准是什么？ 编程吗？

更新：- 我知道我可以使用带有公平参数的 Lock 对象。但只是想知道它如何与同步锁一起工作？

【问题讨论】：

您为什么不自己管理锁以确保一切按您的意愿运行？查找有关 java Lock 对象的教程

这是一个通用问题还是您有兴趣强制执行锁定获取顺序？

只是一个警告：公平锁定会带来性能损失。这增加了开销。

【参考方案1】：

synchronized 获取遵循non-fair 锁定策略。也就是说，在阻塞时先进入的线程可能不是第一个获取的。如果您想要fair 锁，请使用new ReentrantLock(true)

【讨论】：

Semaphore 也允许公平锁定，但 ReentrantLock 是同步的更好替代品。

【参考方案2】：

我的理解是锁将按照获取锁请求的顺序给出。

我相信这仅适用于绿色线程（没有人真正使用过）。

我的问题是，JVM 决定什么最适合平台以及开发人员在编程时如何计算它的标准是什么？

我认为 JVM 不会在运行时“决定”。线程模型只会编译到 JVM 中。

【参考方案3】：

从 JDK6（在 HotSpot JVM 中）开始，它使用一种称为偏向锁定的算法。看看 Oracle 的 white paper，尤其是。关于偏向锁定的部分。他们引用了this paper，进一步描述了算法的细节。

至于开发者应该如何解释这一点，IMO 唯一重要的部分是它不公平。你概率。除非您正在编写高频交易平台或其他东西，否则永远不必担心其他任何事情。

除非您有理由，否则您通常应该支持不公平锁定而不是公平锁定，因为前者通常具有更高的吞吐量。