JPA实体Map复制抛出ConcurrentModificationException解决方案

从异常堆栈能直接定位两个触发CME的核心原因：

• 你JPA实体里的props根本不是普通HashMap，是Hibernate的PersistentMap代理类，这个类会绑定持久化上下文的状态追踪、脏检查逻辑，事务flush、懒加载初始化等动作都会修改它内部的modCount计数
• 不管是PersistentMap还是普通HashMap，迭代器都走fail-fast机制：遍历过程中只要检测到Map结构变化（增删元素、rehash等），就直接抛ConcurrentModificationException，这是集合类的保护机制，不是bug。
  你写的多线程复现用例也印证了这点：非线程安全的HashMap在多线程同时读写、遍历时必然触发这个异常，和用什么复制API没有关系。

不能，100%会抛同样的异常。
你贴的是Map.ofEntries的源码，不是Map.copyOf的实现，但不管是new HashMap<>(map)、Map.copyOf(map)还是自己手写for循环遍历entrySet复制，核心逻辑都是走原Map的迭代器逐个取元素。只要遍历过程中原Map结构被改——不管是Hibernate内部状态更新触发的修改，还是多线程并发增删元素——都会触发fail-fast抛CME。
别被Map.copyOf返回不可变集合的特性误导，这个不可变性只针对复制完成后的新Map，复制过程没有任何并发安全处理，遍历阶段该抛异常一样抛。

按你的实际场景选就行：

单线程JPA场景（无多线程并发改Map） #

这种情况抛CME基本都是因为你把Hibernate的PersistentMap代理直接传到了持久层外，在事务没提交、Session没关闭的时候，触发了Hibernate自动flush、懒加载之类的动作，悄悄改了Map内部的计数。

• 最稳妥的做法：在持久层、事务边界内拿到实体后，先强制初始化集合，立刻复制成普通HashMap再往业务层传，别把PersistentMap的代理引用传到业务逻辑里：

// 强制加载完所有集合元素，避免后续懒加载触发隐式修改
Hibernate.initialize(item.getProps());
// 复制为普通HashMap，脱离Hibernate的状态追踪
Map<String, String> propsSnapshot = new HashMap<>(item.getProps());

• 复制操作尽量避开Hibernate的flush窗口，别在复制前后执行会触发持久化上下文自动flush的操作（比如批量更新、执行会触发auto-flush的查询等）。

多线程并发访问场景 #

这种场景下CME的本质是多线程共享了非线程安全的可变Map，所有无锁遍历的复制方法都解决不了问题，可选方案：

• 加互斥锁：所有Map的增删改、复制操作都用同一把锁保护（比如synchronized或者显式ReentrantLock），保证遍历复制的时候没有其他线程改Map结构。优点是实现简单，缺点是并发性能一般，锁粒度不好控制。
• 换线程安全Map实现：把Map替换成ConcurrentHashMap，它的迭代器是弱一致的，不会抛CME，遍历复制时拿到的是遍历时刻的数据快照，不受并发修改影响。JPA场景下别直接把实体属性类型声明成ConcurrentHashMap避免Hibernate代理兼容问题，加载完实体后把PersistentMap内容转存到ConcurrentHashMap再交给多线程用就行。
• 不可变快照模式：所有Map修改操作都放在单线程里处理，每次改完生成一个不可变的Map快照，所有读线程只访问最新的快照，完全没有并发修改问题，性能也最高，适合读多写少的场景。

别搞反射改modCount、捕获CME重试这类野路子，本质是掩盖并发问题，后续会出数据丢失、HashMap并发rehash死循环这类更难排查的故障。

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