synchronizedList不保证迭代器线程安全，显式锁遍历易因锁顺序不一致导致死锁；推荐快照遍历、CopyOnWriteArrayList或短临界区同步。
collections.synchronizedlist 本身不解决遍历并发安全问题，配合显式锁（如 reentrantlock）手动控制 iterator 遍历反而可能引入死锁，这不是推荐做法——正确方向是避免在加锁状态下长期持有迭代器，或改用线程安全的替代集合。
为什么 synchronizedList + 显式锁 Iterator 容易导致死锁
synchronizedList 仅保证单个操作（add、get、remove）原子性，其 iterator() 返回的迭代器 不是线程安全的。若在 synchronized 或 ReentrantLock 保护块中调用 iterator().hasNext()/next()，且该迭代器内部触发了结构性修改（如其他线程并发 add/remove），可能引发 ConcurrentModificationException；更危险的是：若你为“确保遍历安全”而对整个遍历过程加锁，并与其他代码形成不同顺序的锁获取（例如先 lock A 再遍历 list，另一处先遍历 list 再 lock A），就构成典型死锁条件。
真正安全的遍历方案（推荐）
- 快照遍历（最常用）：在进入遍历时，先通过 toArray() 或 new ArrayList(list) 创建当前状态副本，再遍历副本。原 list 可继续被其他线程修改，无锁、无阻塞、无死锁风险。
- 使用 CopyOnWriteArrayList：适合读多写少场景。iterator() 天然弱一致性且不抛 CME，遍历过程无需额外同步，写操作自动复制底层数组。
-
手动同步 + 短临界区：若必须遍历原始 list，只在获取 iterator 的瞬间同步，且不在锁内执行耗时操作或嵌套调用可能持锁的方法。例如：不要在 synchronized(list) { for (it.hasNext()) { ... } }，而是 synchronized(list) { List
snapshot = new ArrayList(list); } for (T t : snapshot) { ... } 。
显式锁（ReentrantLock）不是替代 synchronizedList 的必要选择
synchronizedList 底层已用 synchronized 修饰所有 public 方法，与 ReentrantLock 在语义上不兼容混用。强行在外层加 ReentrantLock 去“保护”它的遍历，既没提升安全性，又增加锁粒度和死锁可能性。除非你完全放弃 synchronizedList，自定义一个用 ReentrantLock 保护全部操作的线程安全列表（通常没必要，有现成更好的选择）。
实战小提醒
- 永远不要假设 iterator 是线程安全的——无论来自 ArrayList、synchronizedList 还是 Vector。
- 避免在 synchronized 块或 lock 中调用可能阻塞、远程调用、或触发未知锁的操作。
- 用 jstack 或 JProfiler 观察线程堆栈，一旦发现 WAITING 状态长时间停留在 Iterator 相关方法，大概率是锁竞争或设计缺陷。
- 优先考虑不可变性或快照语义，比“锁住一切再遍历”更符合高并发直觉。
