java集合类内存泄漏主因是对象被长期持有却不再需要，关键在于让引用可控可释放：静态集合需配清理机制；优先用weakhashmap或软引用缓存；缓存须限容+自动淘汰；局部化替代全局化，避免一次性对象入静态集合。
Java集合类使用不当导致内存泄漏，核心在于“对象被长期持有却不再需要”，尤其常见于静态集合、未清理的缓存、或生命周期不匹配的引用关系。关键不是禁用集合，而是让引用可控、可释放。
静态集合必须配清理机制
静态集合（如 static Map、static List）生命周期与应用一致，一旦存入对象，若无干预，这些对象永远无法被 GC 回收。
- 避免直接声明
public static final Map<string object> cache = new HashMap();</string>这类“裸静态集合” - 若必须用，务必提供显式清除入口：比如
evictByKey()、clearExpired()或定时任务定期调用cache.clear() - 业务侧需在明确时机主动触发清理，例如用户登出时清空其相关缓存项
优先选用弱/软引用容器
当缓存语义允许“自动释放”，就别靠人工管理——改用更符合内存语义的容器。
- WeakHashMap：键为弱引用，只要外部不再强引用该 key，对应 entry 在下次 GC 时自动消失，适合以对象实例为 key 的临时映射
- SoftReference + 自定义缓存：软引用在内存紧张时才回收，适合做内存敏感型缓存（如图片、模板）
- 注意：
ConcurrentHashMap本身不解决泄漏问题，它只是线程安全，仍需配合淘汰策略
限制容量并内置淘汰逻辑
无限增长是多数缓存泄漏的直接原因。用有限容量+自动淘汰，比依赖人工清理更可靠。
- 继承
LinkedHashMap，重写removeEldestEntry()实现 LRU 或固定大小上限 - 使用成熟缓存库（如 Caffeine），它默认支持大小限制、过期时间、引用清理等能力
- 对自研缓存，至少暴露
size()和put()调用统计，便于监控是否持续增长
局部化替代全局化
很多所谓“缓存需求”，其实根本不需要跨请求、跨线程共享。
- 方法内临时聚合数据，直接用
new ArrayList()或new HashMap()，随栈帧自然消亡 - 请求级上下文缓存，可用
ThreadLocal<map></map>（但记得在 finally 中 remove()，防线程复用导致泄漏） - 避免把本该一次性的 DTO、VO、中间计算结果塞进静态集合
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
