是否有任何 JVM 使用自旋等待实现阻塞？答案

【问题标题】：Does any JVM implement blocking with spin-waiting?是否有任何 JVM 使用自旋等待实现阻塞？
【发布时间】：2011-09-13 15:01:50
【问题描述】：

在 Java 并发实践中，作者写道：

当锁被争用时，失败的线程必须阻塞。 JVM 可以通过spin-waiting（反复尝试获取锁直到成功）或通过挂起被阻塞的线程来实现阻塞要么操作系统。哪个更高效取决于上下文切换开销和锁可用时间之间的关系； spin-waiting 是短等待的首选，而暂停是长等待的首选。 一些 JVM 会根据过去等待时间的分析数据自适应地在两者之间进行选择，但大多数只是挂起等待锁定的线程。

当我读到这篇文章时，我感到非常惊讶。由于分析结果，是否有任何已知的 JVM 在始终旋转等待或有时旋转等待时实现阻塞？现在很难相信。

【问题讨论】：

我不知道具体在 JVM 中的使用，但是 Windows 在多核系统上为 CRITICAL_SECTION 对象实现了自适应自旋锁。
是的，据我所知，所有这些，正常的同步关键字使用自旋锁来修改服务员。有些 impl 可以旋转几秒钟（只要你有足够的核心，没关系）

标签： java multithreading concurrency operating-system scheduling

【解决方案1】：

这是 JRockit 可以使用自旋锁的证据 - http://forums.oracle.com/forums/thread.jspa?threadID=816625&tstart=494

如果您在here 列出的 JVM 选项中搜索“spin”，您将看到在 Hotspot JVM 中使用/支持自旋锁的证据。

如果您需要当前示例，请查看 OpenJDK Java 11 源代码树中的“src/hotspot/share/runtime/mutex.cpp”。

【讨论】：

JVM 选项列表已移动：oracle.com/technetwork/java/javase/tech/…

【解决方案2】：

作者写的都是对的，而且才有意义。对于 Linux 也是如此。使用自旋锁的基本原理是因为大多数资源在几分之一毫秒内受到保护。因此，要挂起，将寄存器的所有内容压入堆栈并放弃 CPU，开销太大，不值得。因此，即使它只是在一组紧凑的指令中旋转，有时只是浪费时间，它仍然比换出更有效。

话虽如此，通过 VM 分析，理想情况下它会使您的处理更加高效。因此，是否存在您总是想暂停的特殊情况？或者也许总是旋转等待？

【讨论】：

我不熟悉Java，但出于好奇，程序员是否可以强制暂停或强制旋转等待，而不是让JVM自适应选择？