java - ReentrantLock 与 CPU 级别上的同步？

Question

“ReentrantLock”和“synchronized”在 CPU 级别的实现方式上有区别吗？或者他们使用相同的“CAS”方法吗？

Answer 1

如果我们谈论的是 ReentrantLock 与 synchronized(也称为“内在锁”)，那么最好看看 Lock documentation :

All Lock implementations must enforce the same memory synchronization semantics as provided by the built-in monitor lock:

• A successful lock operation acts like a successful monitorEnter action
• A successful unlock operation acts like a successful monitorExit action

因此，总的来说，认为synchronized 只是一种易于使用且简洁的锁定方法。您可以通过使用 ReentrantLock 编写代码来实现完全相同的同步效果，但代码要多一些(但它提供了更多选项和灵 active )。

不久前，ReentrantLock 在某些条件下(例如高争用)速度更快，但现在 Java 使用不同的优化技术(例如锁粗化和自适应锁定)来使得程序员在许多典型场景中几乎看不到性能差异。

在低争用情况下(例如偏向锁定)优化内在锁方面也做了出色的工作。 Java 平台的作者确实喜欢 synchronized 关键字和内在锁定方法，他们希望程序员不要害怕使用这个方便的工具(并防止可能的错误)。这就是为什么同步优化和打破“同步很慢”的神话对于 Sun 和 Oracle 来说是如此重要。

问题的“CPU部分”:synchronized 使用内置于 JVM 和 MONITORENTER/MONITOREXIT 字节码指令中的锁定机制。因此，底层实现是特定于 JVM 的(这就是为什么它被称为内在锁)并且据我所知通常(可能会发生变化)使用相当保守的策略:一旦锁是“在获取锁时发生线程冲突后，synchronized 开始使用基于操作系统的锁定(“胖锁定”)而不是快速 CAS(“瘦锁定”)，并且不“喜欢”再次使用 CAS很快(即使争用消失)。

ReentrantLock 实现基于 AbstractQueuedSynchronizer 并用纯 Java 编写(使用 Java 5 中引入的 CAS 指令和线程调度)，因此跨平台更加稳定，提供了更大的灵 active ，并尝试使用快速 CAS 方法每次获取锁(如果失败则获取操作系统级锁定)。

因此，这些锁实现在性能方面的主要区别在于锁获取策略(在特定的 JVM 实现或情况下可能不存在)。

并且没有通用的答案哪种锁定更好+它可能会随着时间和平台的变化而变化。您应该查看具体问题及其性质来选择最合适的解决方案(通常在 Java 中)

PS:您很好奇，我强烈建议您查看 HotSpot 源以深入了解(并找出特定平台版本的确切实现)。它可能真的有帮助。起点在这里:http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/synchronizer.cpp