17370845950

Java集合类默认非线程安全，多线程共享使用易引发ConcurrentModificationException、元素丢失、死循环、size错误及脏读等问题；Vector、Hashtable等虽同步但粒度粗且复合操作不原子；ConcurrentHashMap、CopyOnWriteArrayList等有适用边界；真正安全需结合不可变性、显式锁、专用并发工具及严谨测试。

Java集合类默认都不是线程安全的，多线程环境下直接共享使用（如 ArrayList、HashMap、HashSet）极易引发数据不一致、丢失更新、无限循环甚至 ConcurrentModificationException 等问题。

常见并发异常与表现

以下是在多线程操作非线程安全集合时最典型的几种风险：

• ConcurrentModificationException：遍历过程中被其他线程修改（如边迭代边 add/remove），触发 fail-fast 机制抛出异常；
• 元素丢失或重复：例如多个线程同时调用 HashMap.put()，因扩容、哈希冲突处理逻辑未同步，导致某次 put 被覆盖或静默丢弃；
• 死循环（CPU 100%）：JDK 7 及以前的 HashMap 在多线程扩容时可能形成环形链表，导致 get() 操作无限遍历；
• size() 返回错误值：ArrayList.size 是普通变量，增删操作未加锁，读到的可能是过期值；
• 脏读/部分写入：对象引用虽可见，但其内部状态可能未完全初始化（如构造中被发布），引发诡异 NPE 或逻辑错误。

常用“线程安全”集合的真实能力边界

Java 提供了一些看似线程安全的集合，但需注意它们的同步粒度和适用场景：

• Vector 和 Stack：方法级 synchronized，粗粒度锁，性能差，且不能保证复合操作原子性（如 if (!list.isEmpty()) list.remove(0) 仍可能出错）；
• Hashtable：同上，所有 public 方法加锁，已基本被 ConcurrentHashMap 替代；
• Collections.synchronizedXxx()：包装器方式加锁，仅保障单个方法调用安全，迭代仍需手动同步（synchronized(list) { for(...) {...} }）；
• ConcurrentHashMap：分段锁（JDK 7）或 CAS + synchronized（JDK 8+），支持高并发读、安全迭代、弱一致性遍历；但 size()、containsValue() 等仍是估算值，不保证实时精确；
• CopyOnWriteArrayList：读无锁、写时复制，适合读多写少场景；但写操作开销大，迭代器不会反映写入变化，且内存占用高。

真正安全的并发操作原则

线程安全不是靠换一个集合类就能一劳永逸，关键在于控制共享状态的访问方式：

• 优先使用不可变集合（如 java.util.ImmutableCollections 或 Guava 的 ImmutableList），避免共享可变状态；
• 若必须共享可变集合，用 ConcurrentHashMap 替代 HashMap，用 ConcurrentLinkedQueue 替代 LinkedList 做队列；
• 对复合逻辑（如“检查后执行”）加显式锁（synchronized 块或 ReentrantLock），确保临界区原子性；
• 避免在集合中存可变对象并跨线程修改其内部状态；如需修改，应深拷贝或封装为不可变视图；
• 利用 java.util.concurrent.atomic 类型（如 AtomicIntegerArray）或 BlockingQueue 等专用并发工具，比通用集合更可靠。

调试与检测建议

并发问题往往偶发难复现，可通过以下方式提前暴露风险：

• 单元测试中使用 Thread.sleep() 或 CountDownLatch 控制线程交错点，模拟竞态；
• 开启 JVM 参数 -XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints 辅助定位；
• 使用 JMC（Java Mission Control）、JFR（Flight Recorder）或第三方工具如 jcstress 进行压力并发验证；
• 静态分析工具（如 SpotBugs）能识别部分明显误用，如在迭代中调用 remove。

不复杂但容易忽略：集合是否线程安全，取决于你怎么用，而不只是它叫什么名字。