java - 将对象重新放入 ConcurrentHashMap 是否会导致 "happens-before"内存关系？

Question

我正在使用具有 ConcurrentHashMap 形式的对象存储的现有代码。映射中存储了可变对象，供多个线程使用。按照设计，没有两个线程会尝试同时修改一个对象。我担心的是线程之间修改的可见性。

目前，对象的代码在“setter”(由对象本身保护)上同步。 “ setter/getter ”没有同步，成员也不是易变的。对我来说，这意味着无法保证可见性。然而，当一个对象被修改时，它被重新放置回到 map 中(再次调用put()方法，相同的键)。这是否意味着当另一个线程将对象从 map 中拉出时，它会看到修改？

我在 stackoverflow 上研究过这个，在 JCIP ，并在 java.util.concurrent 的包描述中。我想我基本上把自己弄糊涂了……但导致我问这个问题的最后一根稻草来自包裹描述，它指出:

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.

关于我的问题，“ Action ”是否包括在 re-put() 之前对映射中存储的对象的修改？如果所有这些确实导致跨线程的可见性，这是​​一种有效的方法吗？我对线程比较陌生，非常感谢您的意见。

编辑:

谢谢大家的回复!这是我在 StackOverflow 上的第一个问题，它对我很有帮助。

我必须选择 ptomli的回答，因为我认为它最清楚地解决了我的困惑。也就是说，在这种情况下建立“先于发生”关系并不一定会影响修改的可见性。关于我在文中描述的实际问题，我的“标题问题”构造不当。 ptomli现在的答案与我在 JCIP 中读到的内容一致:“为确保所有线程都能看到共享可变变量的最新值，读写线程必须在公共(public)锁上同步”(第 37 页)。将对象重新放回映射中不会为插入对象的成员的修改提供此公共(public)锁。

我很欣赏所有关于更改的提示(不可变对象(immutable对象)等)，并且我全心全意地同意。但是对于这种情况，正如我所提到的，由于仔细的线程处理，没有并发修改。一个线程修改一个对象，另一个线程稍后读取该对象(CHM 是对象传送器)。在我提供的情况下，我认为 CHM 不足以确保稍后执行的线程将看到第一个线程的修改。不过，我认为你们中的许多人正确回答了标题问题。

Answer 1

您在每次写入对象后调用 concurrHashMap.put。但是，您没有指定在每次读取之前还调用 concurrHashMap.get。这是必要的。

所有形式的同步都是如此:您需要在两个线程中都有一些“检查点”。只同步一个线程是没有用的。

我没有检查 ConcurrentHashMap 的源代码以确保 put 和 get 触发 happens-before，但它们应该是合乎逻辑的。

但是，即使您同时使用了 put 和 get，您的方法仍然存在问题。当您修改一个对象并且它在 put 之前被另一个线程使用(处于不一致状态)时，就会出现问题。这是一个微妙的问题，因为您可能认为旧值会被读取，因为它还没有被 put 并且它不会导致问题。问题是当你不同步时，你不能保证得到一个一致的旧对象，而是行为是未定义的。 JVM 可以随时更新其他线程中对象的任何部分。只有在使用某些显式同步时，您才能确保以一致的方式跨线程更新值。

你可以做什么:
(1) 在代码的任何地方同步对你的对象的所有访问(getters 和setters)。小心 setter :确保您不能将对象设置为不一致的状态。例如，当设置名字和姓氏时，有两个同步的 setter 是不够的:您必须同时为两个操作获取对象锁。
或者
(2) 当您在 map 中放置一个对象时，放置一个深拷贝而不是对象本身。这样其他线程将永远不会读取处于不一致状态的对象。

编辑:
我刚注意到

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.

这样不好。正如我上面所说，只在一个线程上同步根本就不是同步。您可能会在所有编写器线程上进行同步，但谁在乎呢，因为读者不会获得正确的值。