Collections.synchronizedList仅保证单方法线程安全，不解决复合操作、迭代并发及状态依赖问题；需手动同步迭代、避免底层暴露，锁粒度粗影响读性能，应依读写比例与一致性需求选替代方案。
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更轻量安全
