Java Lock支持内存一致性
Java 6 API 问题。调用 LockSupport.unpark(thread) 与刚刚取消停放的线程中的 LockSupport.park 返回是否存在 happens-before 关系？我强烈怀疑答案是肯定的，但 Javadoc 似乎没有明确提及。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我刚刚发现这个问题是因为我也在问自己同样的事情。根据 Oracle 研究员 这篇文章 .com/pls/apex/f?p=labs%3abio:0:29" rel="noreferrer">David Dice，答案似乎是否。这是文章的相关部分：
清空
park()和unpark()< /code> 方法不会给您任何 happens-before 关系保证，因此为了使您的程序 100% 可移植，您不应该依赖它们。再说一次，LockSupport 的 Javadoc 说：
park()的弱保证实际上不应该是有问题吧？I have just found this question because I was asking myself the same thing. According to this article by Oracle researcher David Dice, the answer seems to be no. Here's the relevant part of the article:
Empty
park()andunpark()methods do not give you any happens-before relationship guarantees, so for your program to be 100% portable, you should not rely on them.Then again, the Javadoc of LockSupport says:
Since you have to explicitly check some condition anyway, which will either involve
volatileor properly synchronized variables, the weak guarantees ofpark()should not actually be problem, right?如果没有这样记录，那么您不能依赖它来创建发生在关系之前的关系。
具体来说，Hotspot 代码中的 LockSupport.java 只是调用 Unsafe.park 和 .unpark！
发生之前关系通常来自易失性状态标志或类似标志上的写-读对。
请记住，如果它没有被记录为创建发生之前关系，那么您必须将其视为没有创建，即使您可以证明它在您的特定情况下确实如此系统。未来的系统和实施可能不会。他们给自己留下这种自由是有充分理由的。
If it isn't documented as such then you CANNOT rely on it creating a happens before relationship.
Specifically LockSupport.java in Hotspot code simply calls Unsafe.park and .unpark!
The happens-before relationship will generally come from a write-read pair on a volatile status flag or something similar.
Remember, if it isn't documented as creating a happens-before relationship then you must treat it as though it does not even if you can prove that it does on your specific system. Future systems and implementations may not. They left themselves that freedom for good reason.
我查看了 JDK 代码，看起来 LockSupport 方法通常是在同步块之外调用的。所以，你的假设似乎是正确的。
I have looked though the JDK code and it looks like LockSupport methods are normally called outside of synchronization blocks. So, your assumption seems to be correct.