怎么利用 Collections.synchronizedList() 将线程不安全的列表转化为简单的同步列表

Collections.synchronizedList() 无法解决并发遍历问题，因其仅保证单个方法原子性，复合操作（如size()+get()）、迭代及批量操作仍需手动同步，且不适用于Stream或强一致性场景。

为什么 Collections.synchronizedList() 不能直接解决并发遍历问题

没错，它确实能把你的 ArrayList 或 LinkedList 的单个操作——比如 add()、get()、set()——变得线程安全。但这里有个关键细节：所有方法内部，其实只是简单地套了一层 synchronized(this)。这意味着什么？意味着多个线程分别调用 size() 和 get(i) 时，它们是各自加锁、各自释放的，两次调用之间，根本没有原子性保障可言。

于是，那些经典的并发错误就出现了：ConcurrentModificationException 异常，或者更隐蔽的越界异常（IndexOutOfBoundsException）。尤其是在一个典型的 for 循环里，先调用 list.size() 确定边界，再逐个 get(i) 取值——就在这两次调用的间隙，另一个线程完全可能已经删掉了最后一个元素。

• 所以，别指望它能自动保护任何复合操作。像“检查是否存在再添加”（if (!list.contains(x)) list.add(x);）这种逻辑，必须手动加锁。
• 迭代器（list.iterator()）返回的对象本身不是同步的。遍历时，必须手动同步外部对象：

  synchronized (list) {
      Iterator it = list.iterator();
      while (it.hasNext())
          foo(it.next());
  }
  

• 即使是使用增强 for 循环（for (E e : list)），底层调用的依然是 iterator()，因此同样需要用显式的同步块包裹起来。

什么时候可以用 Collections.synchronizedList() 简单应付

那么，它是不是就一无是处了呢？当然不是。它适用于一些读多写少、且不涉及迭代或条件复合操作的特定场景。举个例子：一个后台线程持续往列表里追加日志条目，而多个监控线程只进行 get(0) 或 size() 这类快照统计——只要业务逻辑不依赖多次方法调用之间的状态一致性，这个轻量级的包装就足够用了。

• 写入线程是唯一的，或者写操作的频率极低（比如配置只在初始化时加载一次）。
• 读操作不要求强实时性，可以接受看到“上一时刻”的快照结果。
• 没有 removeIf()、sort()、replaceAll() 这类批量操作的需求（这些方法不会被自动同步，需要额外的同步块）。
• 不与 Stream 的并行流配合使用（list.parallelStream() 会绕过同步逻辑，直接引发数据竞争）。

Collections.synchronizedList() 和 CopyOnWriteArrayList 怎么选

两者都提供了线程安全的列表，但背后的机制和适用边界截然不同：synchronizedList 是阻塞式的，内存开销低，但在高争用下性能会急剧下降；而 CopyOnWriteArrayList 实现了无锁读，采用写时复制策略，特别适合读操作远多于写的场景。

• 如果你的列表大小稳定在百以内，且写操作极少（比如一个监听器注册表），那么 CopyOnWriteArrayList 通常更安全、更省心——它的迭代器天生具备弱一致性，完全不怕并发修改。
• 如果列表规模很大（达到万级以上），或者写操作非常频繁（每秒多次），就要小心了。CopyOnWriteArrayList 每次写操作都会触发整个底层数组的复制，GC压力会陡然增加。这时，synchronizedList 配合外部同步控制，往往是更实际的选择。
• 还有一个结构性区别：synchronizedList 可以包装任意 List 实现（包括自定义的），而 CopyOnWriteArrayList 是一个具体类，无法用来包装已有的列表对象。

正确初始化和使用的最小实践模板

别随手写个 new ArrayList() 然后包一层就了事。初始容量、泛型类型、是否允许 null 值，这些细节都需要提前考虑清楚。

• 初始化时指定一个合理的初始容量，可以避免频繁扩容带来的额外同步开销：

  List syncList = Collections.synchronizedList(
      new ArrayList<>(128));
  

• 如果用作类的字段，务必将其声明为 List 接口类型，而不是具体的实现类（如 ArrayList）。这可以防止误调用那些未被同步包装的原始方法（比如 ArrayList.ensureCapacity()）。
• 当需要对外暴露这个列表时，可以考虑返回一个经过 Collections.unmodifiableList() 包装的视图，避免下游代码无意中绕过同步逻辑。
• 测试阶段，千万别只测单线程逻辑。务必使用 ExecutorService 启动多个线程，反复执行 add() 和 size() 等操作，观察是否会出现 size() 返回负数或结果突变的情况——这通常是同步失效或存在其他共享状态污染的明确信号。

说到底，真正棘手的从来不是加锁这个动作本身，而是那些你以为“已经锁住”、但实际上根本没覆盖到的代码路径。比如流式处理、lambda引用，或者跨方法的状态判断。在使用 synchronizedList 之前，不妨先问自己一个关键问题：在这段业务逻辑里，有没有任何地方，依赖了两次方法调用之间的那个“中间状态”？