WeakHashMap 的迭代器是 fail-safe 的，不会抛出 ConcurrentModificationException；它遍历时跳过 key 为 null 的 Entry，不校验结构性修改，也不依赖 modCount。
WeakHashMap 的迭代器在 Key 被 GC 回收后，不会抛出 ConcurrentModificationException，因为它本质上是 fail-safe（非 fail-fast）的实现。
WeakHashMap 本身不是 fail-fast 的
与 HashMap、ArrayList 等容器不同，WeakHashMap 的迭代器不依赖 modCount 检查。它的内部 Entry 数组在遍历时会跳过已被清除的 key（即 referent 为 null 的 WeakReference），整个过程不校验结构性修改，因此不触发 fail-fast 机制。
常见误解是“WeakHashMap 有 fail-fast”，实际它属于 Java 中少数明确设计为 fail-safe 的集合之一（类似 ConcurrentHashMap、CopyOnWriteArrayList）。
Key 被 GC 后，Iterator 行为是安全跳过
当某个 key 是弱引用且无强引用指向它时，GC 可能回收该 key。WeakHashMap 的 get/put/remove 等操作会在访问时清理对应 Entry（调用 expungeStaleEntries）。而迭代器在遍历过程中：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 遇到 key == null 的 Entry（即已被 GC 回收的 key），直接跳过，不返回该条目
- 不会中断迭代，也不会抛异常
- 返回的元素仅包含当前仍有效的 key-value 对
注意：fail-fast 和弱引用清理不是一回事
有人误以为 “key 被清掉导致迭代异常” 是 fail-fast，其实这是两个独立机制：
- fail-fast 是通过 modCount + expectedModCount 校验并发修改的策略
- WeakHashMap 的 key 清理是基于 ReferenceQueue 的被动回收，发生在 put/get 或 expunge 阶段，与迭代器无强耦合
- Iterator.next() 内部会主动检查 entry.key 是否为 null，是显式防御逻辑，不是异常检测
实际编码建议
使用 WeakHashMap 迭代时无需额外 try-catch ConcurrentModificationException；但需注意：
- 迭代结果可能“看不见”刚被 GC 的 key，这是正常行为，不是 bug
- 若业务依赖 key 的稳定存在（如缓存命中判断），应确保 key 有强引用，或改用其他 Map 实现
- 不要在迭代中手动调用 clear() 或 remove()——虽然不抛 CME，但可能让后续 next() 返回更少元素，逻辑仍需自洽
WeakHashMap 的设计目标就是容忍 key 的随时消失，它的 Iterator 为此做了适配，既不 fast-fail，也不保证实时一致性，而是以安全、静默的方式反映当前内存状态。
