缓存框架本身不导致内存泄漏，问题出在“怎么用”——没设边界、没管生命周期、没断引用链，对象越积越多，gc始终无法回收。

缓存框架本身不导致内存泄漏，问题出在“怎么用”——没设边界、没管生命周期、没断引用链，对象越积越多，GC始终无法回收。

本地缓存无上限，堆内存被悄悄吃光

Guava Cache、Caffeine 或手写 ConcurrentHashMap 缓存，若只 put 不限 size、不配淘汰策略，就等于在堆里建了个“只进不出”的仓库：

• maximumSize 未设置，或设为 Long.MAX_VALUE，缓存条目无限增长
• expireAfterWrite / expireAfterAccess 完全没配，冷数据永久滞留
• 用 ConcurrentHashMap 自己封装缓存，却没加定时清理或 LRU 逻辑，key-value 全靠强引用锁死

静态缓存是隐形炸弹

static Map/List 是最危险的缓存方式，因为它的生命周期和类加载器绑定，只要应用不重启，里面的东西 GC 永远碰不到：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 缓存 key 是自定义对象但没重写 hashCode/equals，导致重复 entry 积压
• value 是含外部强引用的对象（如 Service 实例、未关闭的流、HttpServletRequest），连带把一堆无关对象钉在堆里
• 没有 invalidate() 或 clear() 调用入口，业务异常路径下缓存写入后彻底失联

分布式缓存客户端反成堆内存大户

RedisTemplate、Jedis 等本身不占堆，但用法不当会让本地堆爆炸：

• 一次查库返回百万级 List，直接塞进本地 Map 缓存，没做分页或大小预检
• 序列化反序列化时用了 JDK 默认序列化，生成大量临时 Class 对象和代理类，撑大元空间或老年代
• 预热阶段把全量数据 load 到本地 ConcurrentHashMap，且未按需懒加载

强引用 + 长生命周期 = 泄漏温床

缓存不是不能存对象，而是要控制谁在持有着它：

• 用 WeakHashMap 存缓存？仅当 key 不再被其他地方强引用时才有效；value 仍可能被其他链路持有
• ThreadLocal 套缓存？线程池复用下，value 可能跨请求残留，尤其没调 remove()
• 监听器、回调、规则引擎中嵌套缓存结果？一旦注册未注销，整个引用树就被挂起

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南