第三方库缓存未设上限引发内存泄漏，表现为堆内存缓慢持续上涨、oom前无异常；需通过监控曲线、堆快照分析确认缓存存在且无淘汰，再用mat定位gc roots中的静态引用或spring上下文强引用，最后通过配置淘汰策略、禁用默认缓存或封装代理层快速缓解，并以压测和堆快照验证效果。
第三方库缓存未设上限引发的内存泄漏，往往表现为堆内存随时间缓慢但持续上涨，尤其在高并发或长周期运行后触发 OOM。这类问题不报错、不抛异常，隐蔽性强，关键在于“确认缓存存在 → 验证无淘汰 → 定位持有者 → 限流兜底”。
一、快速确认是不是缓存没上限在作怪
别一上来就翻源码。先看现象和数据：
- 用 VisualVM 或 Arthas 实时观察 heap.used 趋势：如果内存曲线呈平缓上升（非锯齿状），且 GC 后老年代回收极少，高度可疑
- 抓取两个间隔 15 分钟的堆快照（
jmap -dump:live,format=b,file=heap-01.hprof <pid></pid>），用 MAT 打开后进入 Histogram，按 package 过滤（如com.github.benmanes.caffeine、net.sf.ehcache、org.springframework.cache），看对应缓存 Entry 类（如Caffeine$Policy$BoundedLocalCache$WriteOrderDeque、Element）实例数是否成倍增长 - 检查应用启动日志或配置文件：是否只配了
cacheManager却漏掉maxSize、expireAfterWrite、maxEntries等关键参数
二、用 MAT 穿透引用链，锁定“不死缓存”
找到实例数异常高的缓存类后，右键 → Path to GC Roots，勾选 with all references，重点关注三类路径：
-
static final 字段：比如
EhcacheManager.instance或Caffeine.newBuilder().build()赋值给静态变量，导致整个缓存结构无法卸载 -
Spring ApplicationContext 持有：查看是否被
SimpleCacheManager或ConcurrentMapCacheManager的内部 map 强引用，而该 manager 又被上下文单例持有 -
未清理的 key/value 引用：例如缓存 value 是一个大对象（如
byte[]或 DTO 集合），key 却是未重写equals/hashCode的临时对象，导致重复 put 不命中、缓存不断膨胀
三、针对性缓解：不等升级，立刻生效
开源库修复慢，线上不能停。以下手段可当天上线：
- 显式配置淘汰策略：对 Caffeine 加
maximumSize(1000).expireAfterWrite(10, TimeUnit.MINUTES)；对 Ehcache XML 配置补上<cache maxentrieslocalheap="1000" timetoliveseconds="600"></cache> - 禁用全局默认缓存：Spring Boot 中设
spring.cache.type=none，改用局部、带明确生命周期的缓存实例（如方法级@Cacheable(cacheNames="user", cacheManager="limitedCacheManager")） - 封装代理层：写一个
SafeCaffeineCache包装类，在put前校验当前 size，超限时强制invalidateAll()并打告警日志
四、验证是否真解决
改完别信配置，要见效果：
- 压测 30 分钟，用
jstat -gc <pid> 2s</pid>观察OU（老年代使用量）是否稳定，不再单向爬升 - 再次抓堆快照，对比缓存类实例数是否收敛在预设上限附近（如 Caffeine 显示
Node数 ≈ 1000 ± 50） - 查 GC 日志：若
Full GC频率明显下降，且每次回收后老年代回落正常，基本可确认缓解成功
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
