首页 / JAVA / java – 为什么ConcurrentHashMap中的方法被阻塞？

java – 为什么ConcurrentHashMap中的方法被阻塞？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了java – 为什么ConcurrentHashMap中的方法被阻塞？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1433字，纯文字阅读大概需要3分钟。

内容图文

我在java中有一个关于ConcurrentHashMap的问题.它在内部调用readValueUnderLock.为什么在获取操作时需要锁定.在这种情况下,这种情况将成立
    (Entry.value == NULL)
导致调用readValueUnderLock)

解决方法:

从源代码java doc注释readValueUnderLock

  /**
     * Reads value field of an entry under lock. Called if value
     * field ever appears to be null. This is possible only if a
     * compiler happens to reorder a HashEntry initialization with
     * its table assignment, which is legal under memory model
     * but is not known to ever occur.
     */

从这link

Not quite. You are right that it should never be called.
However, the JLS/JMM can be read as not absolutely
forbidding it from being called because of weaknesses
in required ordering relationships among finals
vs volatiles set in constructors (key is final, value is
volatile), wrt the reads by threads using the
entry objects. (In JMM-ese, ordering constraints for
finals fall outside of the synchronizes-with relation.)
That’s the issue the doc comment (pasted below) refers to.
No one has ever thought of any practical loophole that a
processor/compiler might find to produce a null value read,
and it may be provable that none exist (and perhaps someday
a JLS/JMM revision will fill in gaps to clarify this),
but Bill Pugh once suggested we put this in anyway just
for the sake of being conservatively pedantically correct.
In retrospect, I’m not so sure this was a good idea, since
it leads people to come up with exotic theories.

内容总结

以上是互联网集市为您收集整理的java – 为什么ConcurrentHashMap中的方法被阻塞？全部内容，希望文章能够帮你解决java – 为什么ConcurrentHashMap中的方法被阻塞？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/791579.html

来源：【匿名】