Java中HashMap本身不泄漏内存，但使用不当会成为内存泄漏帮凶：静态缓存未清理、Key对象状态变更致无法回收、监听器未解绑、ThreadLocal+HashMap误用、未关闭资源存入Map，均因引用链阻止GC导致对象长期驻留。
Java 中 HashMap 本身不会主动泄漏内存，但**使用方式不当**会让它成为内存泄漏的“帮凶”。真正泄漏的是它所持有的对象——只要这些对象本该被回收，却因 HashMap 的引用链而无法释放，就构成泄漏。以下是实际业务中最常踩坑的几种场景：
静态缓存未清理（最常见）
把 HashMap 声明为 static，用作全局缓存，但缺乏淘汰机制或清理逻辑。
- 比如定时任务反复往
private static final Map<String, Order> cache = new HashMap<>();中 put 订单对象，从不 remove 或 clear - 静态变量生命周期与 JVM 一致，GC Roots 一直强引用着整个 Map 和其中所有 value，导致所有订单对象永久驻留
- 现象：老年代内存持续上涨，Full GC 后几乎不回落，重启后几小时内复现
Key 对象状态变更导致无法回收
HashMap 的 key 是可变对象（如自定义 POJO），且重写了 hashCode() 和 equals()，但 put 后又修改了影响哈希值的字段。
- 例如：
Person p = new Person("A", 25); map.put(p, data); p.setName("B"); - 此时原 key 的 hash 槽已错位，
map.get(p)找不到，map.remove(p)也删不掉——对象卡在桶里出不来 - 反复执行会不断新增 Entry 节点，Map 实际 size 持续增长，最终 OOM
监听器/回调注册后未解绑
用 HashMap 存储事件监听器映射关系（如 Map<EventType, List<Listener>>），但业务结束时未清理对应 listener 列表。
立即学习“Java免费学习笔记（深入）”；
- 典型于 GUI 应用、消息订阅模块、自定义事件总线
- listener 往往持有 Activity、Fragment、Service 等短生命周期对象的引用，Map 不清，它们就无法 GC
- 尤其在 Android 或 Web 容器中，容易引发界面卡顿、内存占用飙升
ThreadLocal + HashMap 组合误用
在 ThreadLocal 中存放 HashMap，而线程来自线程池（长期存活），但业务结束后未调用 remove()。
- 例如：
private static final ThreadLocal<Map<String, Object>> context = ThreadLocal.withInitial(HashMap::new); - 每次请求向 context.get().put(...) 写入数据，却忘记在 filter 或拦截器末尾执行
context.get().clear(); context.remove(); - 线程复用导致 Map 及其 value 在线程局部堆中越积越多，形成隐式泄漏
未关闭资源对象被存入 HashMap
把未关闭的流、连接等资源包装类（如 FileInputStream、Connection）作为 value 存进 HashMap。
- 这类对象内部持有大量 native 内存或句柄，即使 Java 对象被 GC，底层资源仍不释放
- 更严重的是：它们通常还关联着缓冲区、SocketChannel 等长生命周期组件，进一步拖住其他对象
- 虽不是纯 Java 堆泄漏，但会造成系统级资源耗尽，表现类似内存泄漏
