并发修改异常由非迭代器方法修改集合结构触发,应使用Iterator.remove()或removeIf()避免;HashMap多线程put不安全,推荐ConcurrentHashMap;subList返回视图需注意副作用;泛型擦除致运行时类型检查失效。

并发修改异常(ConcurrentModificationException)怎么触发又怎么避免
遍历集合时直接调用 remove() 或 add() 会大概率抛出 ConcurrentModificationException,哪怕单线程下也如此——因为 ArrayList、HashMap 等非线程安全集合内部维护了 modCount 计数器,迭代器在创建时会记录该值,后续结构变更不通过迭代器自身方法(如 Iterator.remove())就会校验失败。
- 错误写法:
for (String s : list) { if ("bad".equals(s)) list.remove(s); // 抛异常 } - 正确做法:用
Iterator.remove()或 Java 8+ 的removeIf()list.removeIf("bad"::equals); // 推荐,简洁安全 - 注意:
CopyOnWriteArrayList虽可规避此异常,但仅适合读多写极少场景;高频率写入会导致频繁数组复制,性能陡降
HashMap 在多线程环境下 put 操作引发死循环
JDK 7 中 HashMap 扩容时采用头插法重哈希,多线程同时触发扩容可能导致链表成环;JDK 8 改为尾插法并引入红黑树,虽不再死循环,但依然不保证线程安全——put 可能覆盖、丢失数据,且 size() 返回值不可靠。
- 不要用
new HashMap()做共享缓存或计数器 - 替代方案:
- 读多写少 →
ConcurrentHashMap(推荐) - 简单计数 →
AtomicInteger或LongAdder - 必须用 HashMap 且需线程安全 → 外层加
synchronized,但注意锁粒度别过大
- 读多写少 →
- 特别提醒:
Collections.synchronizedMap(new HashMap())仅保证单个操作原子性,复合操作(如先get再put)仍需手动同步
ArrayList 的 subList 返回的是“视图”不是新集合
ArrayList.subList(fromIndex, toIndex) 返回的是原列表的逻辑子区间,底层仍指向同一数组;对子列表的结构性修改(如 add()、clear())会直接影响原列表,反之亦然。
- 常见误用:
List
sub = list.subList(0, 3); sub.clear(); // 原 list 前三个元素也被清空 - 若需独立副本,显式构造新集合:
new ArrayList<>(list.subList(0, 3))
- 子列表不支持
add()/remove()超出范围索引,会抛IndexOutOfBoundsException,这点和原列表行为一致但容易忽略
泛型擦除导致的运行时类型安全隐患
Java 泛型是编译期特性,运行时所有泛型信息被擦除。这使得 instanceof 无法判断泛型参数,new ArrayList 和 new ArrayList 运行时都是 ArrayList 类型;更危险的是,反射或反序列化可能绕过编译检查,向 List 插入 Integer,直到取值时才抛 ClassCastException。
立即学习“Java免费学习笔记(深入)”;
- 避免用反射向泛型集合写入非声明类型
- 反序列化时优先用类型安全的库(如 Jackson 配合
TypeReference),而非裸ObjectInputStream -
工具类中谨慎使用通配符:
List>可读不可写,List super T>可写但不能保证读出是T
subList 返回的视图被当成副本传递给异步任务,或者 HashMap 被多个线程反复 put 却只在日志里看到偶尔丢数据。这些都得靠代码审查时盯住集合的生命周期和访问方式。










