Collections.synchronizedList仅保证单方法原子性，复合操作如if(!list.contains(x)) list.add(x)仍不安全，因contains与add是两次独立加锁；迭代删除会抛ConcurrentModificationException；必须手动同步迭代、统一使用包装对象、避免混用原列表。
为什么不能直接用 Collections.synchronizedList 包一层就完事
直接把 new ArrayList() 传给 Collections.synchronizedList() 得到一个线程安全的 List，这只是让单个方法调用（如 get()、add()）原子化，但**复合操作依然不安全**。比如旧代码里常见的 if (!list.contains(x)) list.add(x)，即使 list 是 synchronizedList，中间仍可能被其他线程插入相同元素，导致重复——因为 contains() 和 add() 是两次独立加锁、解锁的操作。
哪些旧代码模式必须重写才能真正安全
同步视图不改变底层行为，它只是在每个 public 方法入口加了 synchronized (mutex)。所以以下模式无法靠包装解决，必须识别并重构：
- 迭代过程中的结构修改：
for (String s : list) { if (s.isEmpty()) list.remove(s); }—— 会抛ConcurrentModificationException，且不是因为并发，而是同步视图内部没做 fail-safe 迭代器 - 批量操作依赖顺序或中间状态：比如先
sort()再binarySearch()，若期间有其他线程修改，结果不可靠 - 使用
list.iterator()后手动调用next()/remove()：返回的是普通Iterator，其remove()虽然会同步，但遍历本身无锁保护，且不支持并发修改检测外的协作逻辑
怎样最小改动接入 synchronizedList 并避免典型陷阱
如果旧代码只做简单读写、且无复合逻辑，可平移，但要注意三处关键细节：
- 显式持有 mutex：
Collections.synchronizedList(list)返回的对象，其内部锁对象是list自身（或指定的mutex），若需手动同步多操作，应统一用synchronized (list) { ... }，而不是 new 出来的包装类实例——后者mutex字段是 package-private，不可直接访问 - 迭代必须手动同步：正确写法是
synchronized (list) { Iterator<string> it = list.iterator(); while (it.hasNext()) {...} }</string>，否则迭代过程裸奔 - 不要混用原始 list 和包装 list：一旦用了
synchronizedList，所有访问都必须走它；若旧代码某处还直连原始ArrayList，整个同步失效 - 注意 null 安全：
synchronizedList不额外校验 null，和原始 list 行为一致，若旧逻辑依赖空值抛NullPointerException，迁移后表现不变
比 synchronizedList 更稳的替代思路（当平移失败时）
如果发现旧代码里大量存在条件性写入、遍历删除、跨方法状态依赖，强行套 synchronizedList 只会掩盖问题。此时应优先考虑：
- 改用
CopyOnWriteArrayList：适合读多写少、迭代频繁的场景，但写操作开销大，且迭代器看到的是快照，不反映实时变更 - 拆出明确临界区，用
synchronized块包裹完整业务逻辑，比依赖视图更可控 - 用
java.util.concurrent.ConcurrentHashMap模拟 set-like 行为（key = element, value = Boolean.TRUE），规避 list 的索引与顺序强耦合问题
最常被忽略的一点：synchronizedList 的“线程安全”仅针对 List 接口契约，它不管你的业务语义。旧代码是否真需要“列表有序可索引”，还是其实只需要“不重复集合”或“生产消费队列”，这个判断比选工具更重要。
