Java 8中Map.forEach遍历时直接修改Map会抛ConcurrentModificationException，应改用Iterator.remove()或先收集再批量操作；getOrDefault仅在key不存在时返回默认值，若key映射null则返回null。
Java 8 Map.forEach 怎么写才不抛 ConcurrentModificationException
直接改原 Map 的同时用 forEach 遍历，八成会崩。这不是 forEach 的锅，是底层迭代器检测到结构被并发修改后主动抛的错。
常见错误现象：ConcurrentModificationException 在遍历时调了 map.remove(key) 或 map.put(key, val) 后立刻触发。
- 安全做法：想边遍历边删，改用
Iterator+remove()；想边遍历边改值，先收集 key 或 entry 到临时集合，遍历完再批量操作 - 别把
forEach当万能循环——它只适合「只读」或「纯副作用」（比如打日志、发通知），不负责结构变更 forEach底层走的是entrySet().forEach()，所以性能和直接遍历entrySet()差不多，但可读性略高；不过一旦混入修改逻辑，反而更难 debug
getOrDefault 为什么有时返回 null 而不是默认值
不是 getOrDefault 失效了，而是你传进去的 key 本身在 map 里对应着 null 值——它只在 key 完全不存在时才兜底。
使用场景：从配置 Map 里取值，又不想每次写 map.get(k) != null ? map.get(k) : def 这种重复逻辑。
- 典型陷阱：
map.put("timeout", null)后再调map.getOrDefault("timeout", 30)，结果是null，不是30 - 如果业务允许 key 映射
null，那就不能依赖getOrDefault判空，得用containsKey()配合get() - 参数顺序别记反：
getOrDefault(key, defaultValue)，第二个参数是“找不到时才用”的值，不是“找到了也替换”的值
forEach + getOrDefault 组合用法的实际边界在哪
这两个方法可以一起用，但组合不等于自动安全——它们解决的是不同层面的问题：一个是遍历方式，一个是取值容错，叠加并不消除并发或 null 值隐患。
示例场景：统计订单状态分布，对每个 status 累加次数，初始值为 0：
Map<String, Integer> count = new HashMap<>();
orders.forEach(order -> {
String status = order.getStatus();
// ✅ 正确：先 get 再 put，避免 null 值干扰
int curr = count.getOrDefault(status, 0);
count.put(status, curr + 1);
});
- ❌ 错误写法：
count.compute(status, (k, v) -> (v == null ? 0 : v) + 1)更简洁，但初学者容易漏掉v == null判断，误以为compute自带兜底 - ⚠️ 注意
getOrDefault不改变 map 结构，forEach也不保证执行顺序——多线程环境下必须自己加锁或换ConcurrentHashMap - 如果只是单次聚合且数据量小，这种组合够用；但数据量大或需多次复用逻辑，建议封装成工具方法，而不是堆砌 lambda
替代方案：computeIfAbsent 和 compute 的适用时机
当你发现反复写 getOrDefault + put 时，说明该换更语义明确的 API 了。
computeIfAbsent 是懒加载式初始化的标准解法；compute 则适合需要基于旧值做计算的场景，比如计数、拼接、累加。
computeIfAbsent(key, k -> new ArrayList<>())：key 不存在才新建 list，存在就直接返回原 list，线程安全（在ConcurrentHashMap中）compute(key, (k, v) -> v == null ? 1 : v + 1)：比getOrDefault + put少一次 hash 查找，也避免竞态条件下的覆盖问题- 注意：这些方法在
HashMap中仍可能抛ConcurrentModificationException，并发场景务必用ConcurrentHashMap
getOrDefault 的“默认”到底默认什么——它默认的只是“key 不存在”，不是“值不为空”。 
