ThreadSafe装饰器突破Collections.synchronizedList限制

Java 中的 Collections.synchronizedList 并非真正的“线程安全万能解”，它仅对单个方法调用加锁，却在复合操作（如检查后添加、遍历中删除）、迭代并发和状态依赖场景下暴露出严重缺陷——容易引发重复插入、越界异常或 ConcurrentModificationException；其粗粒度的全局锁还导致高并发读性能受限，而手动同步迭代又极易因锁对象错误或底层列表暴露而失效；因此，是否选用它，必须结合实际读写比例、数据规模、一致性要求及操作原子性需求，审慎权衡 CopyOnWriteArrayList、ConcurrentHashMap 模拟索引、ReentrantLock 或不可变封装等替代方案。

Collections.synchronizedList 是 Java 提供的线程安全装饰器，但它不是“开箱即用”的万能方案——它只对单个方法加锁，不解决复合操作、迭代或状态依赖带来的并发风险。

单方法安全 ≠ 逻辑安全

它把 add()、get(i)、size() 等每个调用都包在 synchronized(mutex) 里，但一旦组合使用，原子性就失效：

• “检查后添加”：两个线程同时执行 if (!list.contains(x)) list.add(x)，可能都通过判断并重复插入
• “先 size() 再 get(0)”：中间被其他线程清空，get(0) 直接抛 IndexOutOfBoundsException
• “遍历中删除”：即使用了 synchronizedList，for (String s : list) { if (s.isEmpty()) list.remove(s); } 仍大概率触发 ConcurrentModificationException

迭代必须手动同步，且锁对象不能错

它的 iterator()、listIterator()、增强 for 循环返回的迭代器本身完全不带锁，必须显式同步容器本身：

• 正确写法：synchronized (safeList) { for (String s : safeList) { ... } }
• 错误写法：裸用 for (String s : safeList)，或用 synchronized(new Object()) —— 锁对象不一致等于没锁
• 若底层 List 被意外暴露（如传给 new ArrayList(safeList)），同步彻底失效

锁粒度粗，性能与场景强相关

所有读写操作共用同一把锁（默认是包装对象自身），导致：

• 读读互斥：高并发读场景下吞吐受限，不如 CopyOnWriteArrayList 的无锁读
• 写成本低：相比 CopyOnWriteArrayList 每次写都复制数组，它写是 O(1)，适合写稍频繁、元素较大（如含大 byte[]）的场景
• 不保快照一致性：迭代看到的是实时状态，而 CopyOnWriteArrayList 迭代的是创建时的快照

替代方案要按需选，别硬套

没有银弹，关键看访问模式：

• 读多写极少 + 频繁迭代 → 优先 CopyOnWriteArrayList
• 写较频繁 + 元素体积大 + 需要实时视图 → Collections.synchronizedList 更合适
• 需要真正原子的复合操作（如 put-if-absent、条件移除）→ 改用 ConcurrentHashMap 模拟索引，或配合 ReentrantLock 手动控制
• 只读共享 → Collections.unmodifiableList 更轻量安全

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《ThreadSafe装饰器突破Collections.synchronizedList限制》文章吧，也可关注golang学习网公众号了解相关技术文章。