java - wait() 和 notify() JMM 语义

Question

关闭。这个问题需要更多 focused .它目前不接受答案。












想改进这个问题？更新问题，使其仅关注一个问题 editing this post .

2年前关闭。




Improve this question




我有一个非常特殊的问题，我找不到答案。

众所周知，在 synchronized 入口处阻塞线程重新读取其范围内的所有共享(非本地)变量。某些底层架构的示例:如果线程 A 在 RAM 线程 B 中更新对象的状态，则进入同步块(synchronized block)将看到更改。
从 synchronized 退出时也会发生类似的情况 block :线程将其范围内的所有内容刷新到 RAM，以便其他线程可以看到。
这些是基本的 JVM 可见性保证，并且存在之前发生的规则来强制执行它。

但是，从语义上看，代码是否使用 wait() 不是很清楚。或 notify()也做所有这一切:毕竟它没有明确地进入或离开 synchronized堵塞。

这些问题是:

JVM 是否确保对 wait() 上其他线程的更改可见？入口？

JVM 是否确保 wait() 上其他线程中所做更改的可见性？离开？

线程是否确保对 notify() 上其他线程的更改可见？ ?

Answer 1

As we know, on entrance in synchronized blocks a thread performs a re-read of all the variables in it's scope; that is, if thread A updates the object's state in RAM thread B entering a synchronized block will see the changes.

第一部分是不正确的。不会重读所有变量。局部变量肯定不会。它们不需要重新阅读，因为它们永远不会被另一个线程看到。

正确的说法是编译器将确保线程 A 在退出 block 之前写入的共享变量在线程 B 进入 block 后对它是可见的。假设 A 和 B 在同一个互斥对象上同步，并且假设 A(或其他一些线程)在此期间没有覆盖它们。

没有与 notify 关联的显式内存语义。或 notifyAll .然而，一个 wait将导致互斥锁被释放并(通常)重新获取。释放和重新获取与一些其他线程相关联的happens-before 关系。

Could you, please, elaborate on exact semantics associated with releasing and acquiring a lock? Are they one and same with entering the synchronized block?

假设我们只有两个线程，A 和 B，以及一个互斥锁 L。假设我们从两个线程都没有持有互斥锁开始。

还要记住 wait和 notify只能由持有锁的线程调用

线程 A 获取 L。

线程 A 调用 L.wait() .

线程 A 被放到 L 的等待队列中，L 被释放。

线程 B 获取 L。

线程 B 调用 L.notify()

线程 A 移动到等待获取 L 的线程队列中。

线程 B 释放 L。

线程 A 重新获取锁，L.wait()调用返回。

这里重要的发生前边缘在 2 和 3 之间，然后在 5 和 6 之间。

如果涉及多个线程，您可以通过链接发生之​​前的关系来分析行为。但是在释放互斥锁的线程和下一个获取它的线程之间只有一个直接的 HB ......无论如何。

因此，您的问题的答案是:

1) & 2) 是，假设另一个线程正在使用 synchronized正确。
3) 否。可见点是互斥锁被调用 notify() 的线程释放时。 .

请注意，内存屏障、刷新等是实现细节。事实上，编译器可以随意实现happens-before 的语义。如果没有必要，包括(假设地)优化掉内存刷新。

最好(IMO)忽略这些实现细节，只考虑发生前的关系。

有关happens-before的更多信息，请阅读:

How to understand happens-before consistent

Brian Goetz 等人的“Java concurrency in action”的内存模型章节

JVM 规范第 17.4 章