Collections.synchronizedList仅保证单个方法原子性，不保障复合操作线程安全；适合独立add/get/remove等单次操作，如日志队列、配置填充；涉及“先查后改”或遍历修改时须手动同步；适用于低并发、低频写场景，高并发下应选CopyOnWriteArrayList等替代方案。
Collections.synchronizedList 是一个快速启用线程安全的轻量级方案，但它不是“开箱即用”的万能解。它只保证单个方法调用的原子性，不保障复合逻辑的线程安全，实际使用中容易踩坑。
适合单次、无依赖的操作
当多个线程仅做独立的 add()、get(i)、remove(Object) 等单一动作时，synchronizedList 能有效防止数据错乱。例如：
- 日志队列：各线程各自 add 日志条目，无需检查或协调
- 配置缓存填充：多个初始化线程并发 put 配置项，彼此互不干扰
- 状态标记集合：线程执行完任务后向列表 add 标识符，后续统一统计
这类场景下，每个操作本身不依赖前序结果，也不需要跨方法组合判断，synchronizedList 的粗粒度锁足够可靠。
必须手动同步的复合操作
只要涉及“先查后改”或“遍历+修改”，就必须显式加锁，否则极易出错：
立即学习“Java免费学习笔记（深入）”；
- “如果为空则添加默认值” → size()==0 后 add()，中间可能被其他线程清空
- “遍历时删除匹配项” → 增强 for 循环不加锁会抛 ConcurrentModificationException
- “取首元素并移除” → get(0) 和 remove(0) 是两次独立调用，中间可能被删空
正确做法是用原始 syncList 实例作为锁对象：
synchronized (syncList) { if (!syncList.isEmpty()) { syncList.remove(0); } }性能与并发规模的平衡点
它适用于线程数少（通常 ≤10）、写操作频率不高、且无高频迭代的场景：
- 锁是全局独占的，读读、读写、写写全部串行，吞吐随线程增长急剧下降
- 比 Vector 略优（锁在代码块而非整个方法），但远不如 CopyOnWriteArrayList 在读多写少时的表现
- 若写操作频繁或线程密集，锁竞争会导致大量线程阻塞，响应延迟明显上升
典型适用环境：后台管理服务中的小规模配置监听器、内部工具类的状态聚合、低频触发的事件缓冲区。
替代方案的选择依据
遇到以下情况，应优先考虑其他方案：
- 需要频繁迭代且读远多于写 → CopyOnWriteArrayList（迭代安全、无锁读）
- 要求“检查-更新”原子性 → ReentrantLock + 手动同步，或改用 ConcurrentLinkedQueue 等更合适的并发结构
- 底层 List 是不可变或只读的 → synchronizedList 多余，直接用 Collections.unmodifiableList 即可
- 已有复杂业务逻辑依赖 ArrayList 行为（如允许 null 元素、支持 set(null)）→ CopyOnWriteArrayList 不兼容，需坚持 synchronizedList 并严格管控复合操作
