Map集合视图迭代器能否感知原Map的replace/覆盖式put修改？

你观察到的这个现象很典型，咱们把问题拆开来理清楚：

为什么没抛出ConcurrentModificationException？ #

首先，ConcurrentModificationException的触发逻辑是Map的结构发生改变——比如新增/删除键、改变了Map的元素总数。而replace(K key, V value)或者put(K existingKey, V newValue)只是修改已有键关联的值，并没有改变Map的结构（键的数量没变），所以像HashMap这类常见的Map实现，它的快速失败迭代器不会触发这个异常，这是完全符合预期的。

迭代器能感知到这类修改吗？有没有保证？ #

答案是完全没有官方保证，具体行为取决于你使用的Map实现：

• 对于普通的非同步Map（比如HashMap）：迭代器是基于创建时Map的内部结构快照生成的。当你修改已有键的值后，迭代器后续遍历到这个键时，有可能拿到更新后的值，也有可能还是旧值——这完全看迭代器的遍历进度和Map内部的存储逻辑，没有任何明确的行为约定。
• 对于并发安全的Map（比如ConcurrentHashMap）：它的迭代器是弱一致性的，可能会感知到迭代开始后的修改，但不保证能实时反映所有变化，同样也不会抛出异常，但这种“感知”不是强保证的，只是尽可能呈现最新状态。

结合Map API规范的核心提醒 #

Map接口API明确规定：若在迭代集合过程中修改Map（除非通过迭代器自身的remove操作），迭代结果未定义。

这句话的重点是：任何非迭代器自身发起的修改（包括修改已有值、增删键），都不能依赖迭代器的行为——不管有没有抛出异常，迭代器的输出都是不可预测的，可能拿到旧值、新值，甚至出现混乱的遍历顺序（如果是有序Map的话）。

实践中的安全建议 #

• 如果需要在迭代过程中修改已有值，并且希望行为可预测，最安全的方式是通过迭代器拿到的Entry对象直接修改：

  for (Map.Entry<K, V> entry : map.entrySet()) {
      if (entry.getKey().equals(targetKey)) {
          entry.setValue(newValue);
      }
  }
  

  这种方式是Map规范允许的，Entry的setValue方法属于合法的迭代中修改，不会产生未定义行为。
• 如果你必须在迭代外部修改Map，修改后请重新获取迭代器，不要继续使用旧的迭代器，避免依赖不可预测的行为。
• 并发场景下，一定要用ConcurrentHashMap这类并发安全的实现，并且清楚理解其迭代器的弱一致性特性。

内容的提问来源于stack exchange，提问作者Code Complete