Collections.synchronizedList()仅保证单方法原子性，不保障复合操作或迭代安全；需手动同步临界区，如检查再添加、遍历时须synchronized(list)块；替代方案依读写比例选CopyOnWriteArrayList或ReentrantLock。
直接用 Collections.synchronizedList() 包装原始 ArrayList，就能快速获得线程安全的列表对象——但它只保证单个操作原子性，**不等于整个业务逻辑线程安全**，这点必须清醒。
包装后获得的是“方法级同步”的列表
它返回一个代理对象，内部对每个 public 方法（如 add()、get()、size()）加了 synchronized 锁（锁在自身实例上）。这意味着：
- 单次调用是线程安全的，比如
list.add(x)不会因多线程并发而丢数据或抛ConcurrentModificationException - 但复合操作仍需手动同步，例如“检查是否存在再添加”：
if (!list.contains(e)) list.add(e);—— 这两步之间可能被其他线程插入相同元素 - 迭代器（
iterator()）返回的对象本身**不是线程安全的**，遍历时若其他线程修改列表，会触发ConcurrentModificationException
正确使用迭代：必须手动同步外部块
要安全遍历，得显式同步整个迭代过程：
synchronized (list) {
for (Object e : list) {
// 处理 e
}
}
注意：这里的 list 是 Collections.synchronizedList() 返回的对象，同步锁对象必须和它内部使用的锁一致（即该对象自身），否则无效。
替代方案对比：按场景选更合适的
如果需求不止是“简单读写”，建议评估以下选项：
-
CopyOnWriteArrayList：适合读多写少（如监听器列表），每次写都复制数组，迭代绝对安全，但写操作开销大、不反映实时变更 -
Vector：历史遗留类，所有方法同步，语义同synchronizedList，但设计过时，一般不推荐新代码使用 -
显式
ReentrantLock+ 普通ArrayList：控制粒度更细（如读写锁分离），但编码复杂度上升，需自行管理锁生命周期
一句话总结补锁要点
调用 Collections.synchronizedList(new ArrayList()) 确实能快速让列表具备基础线程安全性；但务必记住：它只锁住每个方法入口，不保护跨方法的逻辑一致性。真正安全，靠的是开发者对临界区的识别与主动加锁，而不是依赖这个工具自动兜底。
