weakhashmap 适合防内存泄漏场景，如gui组件元数据绑定、弱监听器注册、线程上下文快照；其核心是键为弱引用，随外部强引用消失而自动清理条目，但值仍为强引用，不适用于缓存或长期配置。
WeakHashMap 适合什么场景？不是缓存，但能防泄漏
WeakHashMap 的核心价值不是做缓存，而是避免因 Map 持有键引用导致的内存泄漏。它只在“键对象生命周期不由 Map 控制”时才真正起作用——比如 GUI 组件、监听器、临时上下文绑定等场景。
常见错误现象：HashMap 存了大量 Component 或 ThreadLocal 相关对象后，发现老年代持续增长、GC 频繁却回收不掉；用 WeakHashMap 替换后，对象随外部强引用消失而自动清理。
- 适用场景：GUI 组件元数据绑定（如
JButton→ tooltip 配置）、弱监听器注册（避免观察者模式中被观察者持有了监听器）、线程上下文快照（Thread→ 临时上下文） - 不适用场景：长期存活的配置项（如
"timeout"字符串常量作 key）、需要稳定迭代的映射表（GC 后 Entry 被异步清理，遍历时可能ConcurrentModificationException）、高并发读写（它本身非线程安全，且清理逻辑带锁） - 值仍是强引用：如果
value反向持有key（比如 value 是个闭包捕获了 key），那 key 就不会被回收——WeakHashMap只弱化 key，不碰 value
为什么 key 是弱引用，value 不是？
因为 WeakHashMap 的设计目标从来就不是节省 value 占用的内存，而是解耦“键对象是否还该存在”这个生命周期决策权。key 是索引标识，value 是附属信息；只要 key 在别处没人要了，整个条目就该失效——value 留不留，由业务逻辑决定。
容易踩的坑：new WeakHashMap<string byte>()</string> 中，String key 被置为 null 后确实会被回收，但 byte[] 值仍占着大块堆内存，且没任何机制触发它释放。
立即学习“Java免费学习笔记（深入）”；
- 若 value 也需弱化，得手动包装：
map.put(key, new WeakReference(bigObject)) - 若想按内存压力自动释放 value，应选
SoftReference，而不是依赖 WeakHashMap 本身 - 不要用字符串字面量（如
"abc"）当 key：它们在字符串常量池里有强引用，永远不回收，WeakHashMap彻底失效
怎么验证 WeakHashMap 真正在工作？别信 System.gc()
WeakHashMap 的清理发生在 GC 之后，并通过内部 ReferenceQueue 异步完成；调用 System.gc() 既不保证触发 GC，也不保证立即清理 Entry。靠它测试，十次九次误判。
实操建议：用可变对象 + 显式断引用 + 堆监控组合验证：
- 创建一个自定义类实例作 key：
MyKey key = new MyKey("test") -
map.put(key, "value")后立刻key = null - 触发一次 Full GC（可用
jstat -gc <pid></pid>观察） - 再调用
map.size()或遍历，确认条目消失——这才是真实行为 - 生产环境绝不能依赖
System.gc()；JVM 参数如-XX:+PrintGCDetails更可靠
WeakHashMap 和 HashMap 性能差在哪？
每次 get()、put()、size() 都会顺带扫描并清理已入队的 stale Entry，带来额外开销；哈希桶结构和 HashMap 一样，但清理逻辑引入了隐式同步和 queue 处理成本。
性能影响明显体现在高频访问或 Entry 密集场景：
- 单次操作延迟略高（尤其在 ReferenceQueue 积压多时）
- 内存占用略低（Entry 对象本身更重，继承自
WeakReference） - 并发下比 HashMap 更易出现清理竞争，不建议直接用于高并发写入
- 替代方案：若需线程安全 + 弱引用语义，考虑
ConcurrentHashMap+ 手动WeakReference<k></k>包装 key，或用第三方库如 Guava 的CacheBuilder.weakKeys()
最常被忽略的一点：WeakHashMap 不是“自动缓存淘汰策略”，它不感知 value 大小、访问频次或内存压力——它只响应 key 的可达性。真要做缓存，优先考虑 SoftReference 或专用缓存库。
