并发修改异常由非迭代器方法修改集合结构触发，应使用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()）会直接影响原列表，反之亦然。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 常见误用：
List<String> sub = list.subList(0, 3); sub.clear(); // 原 list 前三个元素也被清空
- 若需独立副本，显式构造新集合：
new ArrayList<>(list.subList(0, 3))
- 子列表不支持
add()/remove()超出范围索引，会抛IndexOutOfBoundsException，这点和原列表行为一致但容易忽略
泛型擦除导致的运行时类型安全隐患
Java 泛型是编译期特性，运行时所有泛型信息被擦除。这使得 instanceof 无法判断泛型参数，new ArrayList<string>()</string> 和 new ArrayList<integer>()</integer> 运行时都是 ArrayList 类型；更危险的是，反射或反序列化可能绕过编译检查，向 List<string></string> 插入 Integer，直到取值时才抛 ClassCastException。
立即学习“Java免费学习笔记（深入）”；
- 避免用反射向泛型集合写入非声明类型
- 反序列化时优先用类型安全的库（如 Jackson 配合
TypeReference），而非裸ObjectInputStream - 工具类中谨慎使用通配符：
List>可读不可写，List super T>可写但不能保证读出是T
subList 返回的视图被当成副本传递给异步任务，或者 HashMap 被多个线程反复 put 却只在日志里看到偶尔丢数据。这些都得靠代码审查时盯住集合的生命周期和访问方式。 
