java - 为什么volatile read总是无竞争？

Question

引自《Java 并发实践》一书:

The performance cost of synchronization comes from several sources. The visibility guarantees provided by synchronized and volatile may entail using special instructions called memory barriers that can flush or invalidate caches, flush hardware write buffers, and stall execution pipelines. Memory barriers may also have indirect performance consequences because they inhibit other compiler optimizations; most operations cannot be reordered with memory barriers. When assessing the performance impact of synchronization, it is important to distinguish between contended and uncontended synchronization. The synchronized mechanism is optimized for the uncontended case (volatile is always uncontended), and at this writing, the performance cost of a "fastͲpath" uncontended synchronization ranges from 20 to 250 clock cycles for most systems.

您能更清楚地说明这一点吗？如果我有大量读取 volaile 变量的线程怎么办？

你能提供竞争定义吗？

是否有衡量争用的工具？它以哪些值(value)观衡量？

Answer 1

Can you clarify this more clear?

这是一个涉及很多主题的密集段落。您具体要求澄清哪个或哪些主题？您的问题太宽泛，无法令人满意地回答。对不起。

现在，如果您的问题是特定于无竞争同步的，这意味着 JVM 中的线程不必阻塞、解除阻塞/通知然后返回到阻塞状态。

在底层，JVM 使用硬件特定的内存屏障来确保

1. volatile 字段总是从主内存中读取和写入，而不是从 CPU/核心缓存中读取和写入，并且
2. 您的线程不会阻止/取消阻止访问它。

没有争执。当您使用同步块(synchronized block) OTH 时，您的所有线程都处于阻塞状态，除了一个线程，该线程读取同步块(synchronized block)保护的任何数据。

我们称该线程，即访问同步数据的线程，线程 A。

现在，更重要的是，当线程 A 处理完数据并存在同步块(synchronized block)时，这会导致 JVM 唤醒所有其他线程正在/正在等待线程 A 退出同步块(synchronized block)。

他们都醒了(这在 CPU/内存方面是昂贵的)。他们都争先恐后地试图控制同步块(synchronized block)。

想象一下，一大群人试图通过一个小房间离开拥挤的房间。是的，就像那样，这就是线程在尝试获取同步锁时的行为方式。

但只有一个人得到它并进入。所有其他人都回到 sleep 状态，某种程度上，处于所谓的阻塞状态。这在资源方面也是昂贵的。

因此，每当其中一个线程存在一个同步块(synchronized block)时，所有其他线程都会发疯(我能想到的最好的心理形象)来访问它，一个得到它，所有其他线程都回到阻塞状态.

这就是同步块(synchronized block)昂贵的原因。现在，这里有一个警告:在 JDK 1.4 之前它曾经非常昂贵。那是17年前。 Java 1.4 开始出现一些改进(2003 IIRC)。

然后 Java 1.5 在 12 年前的 2005 年引入了更大的改进，这使得同步块(synchronized block)的成本更低。

记住这些事情很重要。那里有很多过时的信息。

What if I have huge amount threads which read volaile variable ?

就正确性而言，这无关紧要。 volatile 字段将始终显示一致的值，无论线程数如何。

现在，如果您有大量线程，性能会因上下文切换、内存使用等而受到影响(不一定和/或主要是因为访问 volatile 字段。

Can you provide contention definition?

请不要误会，但如果你问这个问题，恐怕你还没有完全准备好使用你正在阅读的这本书。

您将需要更基本的并发介绍，尤其是争用。

https://en.wikipedia.org/wiki/Resource_contention

最好的问候。