将对象重新放入ConcurrentHashMap中导致“发生在之前”内存关系？ [英] Does re-putting an object into a ConcurrentHashMap cause a "happens-before" memory relation?
问题描述
我正在使用具有ConcurrentHashMap形式的对象存储的现有代码。在地图中存储可变对象，由多个线程使用。没有两个线程试图通过设计一次修改对象。我关心的是线程之间的修改的可见性。
目前对象的代码在setters（由对象本身保护）同步。 getter没有同步，成员也不挥发。这对我来说意味着不能保证可见性。然而，当对象被修改时，它被重新回到映射中（ put（）方法被再次调用，同一个键）。这是否意味着当另一个线程拉出对象从映射，它会看到修改？
我已经研究了这里在stackoverflow，在 JCIP ，以及java.util.concurrent的软件包描述。我基本上困惑自己我认为...但最后的稻草，导致我提出这个问题是从包描述，它说：
在将对象放入任何并发集合之前，线程中的操作发生在从另一个线程中的集合访问或删除该元素之前发生的操作。
关于我的问题，actions包括对re-put之前存储在地图中的对象的修改？如果这一切确实导致线程的可见性，这是一种有效的方法吗？
p>谢谢大家的回应！这是我对StackOverflow的第一个问题，它对我非常有帮助。
我必须用 ptomli 的答案，因为我认为它最清楚地解决了我的困惑。也就是说，在这种情况下，建立发生先于关系不一定影响修改可见性。我的标题问题对我在文本中描述的实际问题的构造不好。 ptomli 的答案现在与我在 JCIP ：为了确保所有线程都能看到共享可变变量的最新值，读写线程必须在公共锁上同步（第37页）。将对象重新放入映射不会为修改插入对象的成员提供此常用锁。
我感谢所有的改变提示（不可变对象，等等），我完全同意。但对于这种情况，正如我提到的，没有并发修改，因为仔细的线程处理。一个线程修改对象，另一个线程稍后读取对象（CHM是对象传送器）。我认为CHM不足以确保稍后执行的线程将看到从给定的情况下我提供的修改。
我认为你的问题与你的问题有关。
如果您要存储在映射中的实例更多地映射到映射中的对象，以及它们对并发访问的响应， map有同步的mutators，但没有同步的访问器，那么我不知道他们如何可以像描述的线程安全。
取 Map 出来的方程，并确定您存储的实例是否是线程安全的自己。
但是，当一个对象被修改时，它被重新放回映射中（put（）方法被再次调用， ）。这是否意味着当另一个线程将对象从映射中拉出时，它会看到修改吗？
重新放入地图的实例将由另一个线程从地图中检索。这是并发映射的保证。这与存储实例本身的状态的可见性无关。
I'm working with existing code that has an object store in the form of a ConcurrentHashMap. Within the map are stored mutable objects, use by multiple threads. No two threads try to modify an object at once by design. My concern is regarding the visibility of the modifications between the threads.
Currently the objects' code has synchronization on the "setters" (guarded by the object itself). There is no synchronization on the "getters" nor are the members volatile. This, to me, would mean that visibility is not guaranteed. However, when an object is modified it is re-put back into the map (the put() method is called again, same key). Does this mean that when another thread pulls the object out of the map, it will see the modifications?
I've researched this here on stackoverflow, in JCIP, and in the package description for java.util.concurrent. I've basically confused myself I think... but the final straw that caused me to ask this question was from the package description, it states:
Actions in a thread prior to placing an object into any concurrent collection happen-before actions subsequent to the access or removal of that element from the collection in another thread.
In relation to my question, do "actions" include the modifications to the objects stored in the map before the re-put()? If all this does result in visibility across threads, is this an efficient approach? I'm relatively new to threads and would appreciate your comments.
Edit:
Thank you all for you responses! This was my first question on StackOverflow and it has been very helpful to me.
I have to go with ptomli's answer because I think it most clearly addressed my confusion. To wit, establishing a "happens-before" relation doesn't necessarily affect modification visibility in this case. My "title question" is poorly constructed regarding my actual question described in the text. ptomli's answer now jives with what I read in JCIP: "To ensure all threads see the most up-to-date values of shared mutable variables, the reading and writing threads must synchronize on a common lock" (page 37). Re-putting the object back into the map doesn't provide this common lock for the modification to the inserted object's members.
I appreciate all the tips for change (immutable objects, etc), and I wholeheartedly concur. But for this case, as I mentioned there is no concurrent modification because of careful thread handling. One thread modifies an object, and another thread later reads the object (with the CHM being the object conveyer). I think the CHM is insufficient to ensure that the later executing thread will see the modifications from the first given the situation I provided. However, I think many of you correctly answered the title question.
I think your question relates more to the objects you're storing in the map, and how they react to concurrent access, than the concurrent map itself.
If the instances you're storing in the map have synchronized mutators, but not synchronized accessors, then I don't see how they can be thread safe as described.
Take the Map out of the equation and determine if the instances you're storing are thread safe by themselves.
However, when an object is modified it is re-put back into the map (the put() method is called again, same key). Does this mean that when another thread pulls the object out of the map, it will see the modifications?
This exemplifies the confusion. The instance that is re-put into the Map will be retrieved from the Map by another thread. This is the guarantee of the concurrent map. That has nothing to do with visibility of the state of the stored instance itself.
这篇关于将对象重新放入ConcurrentHashMap中导致“发生在之前”内存关系？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
