Java原生集合类默认非线程安全，多线程修改易引发ConcurrentModificationException或数据异常；Collections.synchronizedXxx()仅方法级同步，迭代仍需手动加锁；推荐使用ConcurrentHashMap、CopyOnWriteArrayList等并发集合，需依读写比例、实时性等场景选型。
Java原生集合类默认都不线程安全
直接用 ArrayList、HashMap、HashSet 等在多线程环境下修改（比如多个线程同时 add() 或 put()），大概率触发 ConcurrentModificationException，或者产生数据丢失、脏读等不可预测行为。这不是“偶尔出错”，而是设计使然——这些类没做任何同步控制。
想线程安全？别用 Collections.synchronizedXxx() 封装
虽然 Collections.synchronizedList(new ArrayList()) 这类方法能提供基本同步，但只是给每个方法加了 synchronized，**迭代时仍需手动同步整个容器**，否则依然可能抛异常。常见错误写法：
List<String> list = Collections.synchronizedList(new ArrayList<>());
// ❌ 危险！迭代期间其他线程可能修改
for (String s : list) { ... }
// ✅ 必须包一层 synchronized
synchronized (list) {
for (String s : list) { ... }
}
这种写法易漏、难维护，且吞吐量低——所有操作串行排队。
推荐用 java.util.concurrent 包里的专用并发集合
它们按场景做了精细设计，不是简单加锁，而是分段锁、CAS、无锁算法等：
Blender Geometry Nodes Script Generator
下载
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
立即学习“Java免费学习笔记（深入）”；
-
ConcurrentHashMap：支持高并发读写，get()无锁，put()分段/桶级锁，JDK 8+ 改为基于Node+ CAS + 红黑树 -
CopyOnWriteArrayList：适合读多写少，写操作复制整个数组，迭代不抛ConcurrentModificationException，但内存开销大、实时性差 -
ConcurrentLinkedQueue：无锁队列，基于 CAS，适合高并发生产消费场景 -
BlockingQueue实现如ArrayBlockingQueue、LinkedBlockingQueue：带阻塞语义，常用于线程池、生产者消费者模型
选错并发集合反而更慢甚至死锁
比如用 CopyOnWriteArrayList 存高频更新的配置项，每次修改都复制数组，GC 压力陡增；又比如在循环里反复调用 ConcurrentHashMap.size() 判断是否为空——它不保证强一致性，返回的是估算值，且 JDK 8+ 的实现中该方法本身有额外开销。
真正关键的不是“能不能用”，而是理解每个并发集合的**一致性模型、性能边界和适用节奏**：读写比例、元素数量级、是否需要实时可见、是否要阻塞等待……这些比“是不是线程安全”重要得多。
