Caffeine缓存库内存增长问题分析与解决方案

内存泄漏现象分析

在使用Caffeine缓存库时，开发者遇到了一个典型的内存增长问题。配置了一个60分钟过期时间、最大容量为20,000项的缓存后，发现内存每隔60分钟就会出现一次明显的增长，并且这些内存似乎永远不会被垃圾回收。有趣的是，当添加.weakKeys和.weakValues配置后，内存问题得到解决，但代价是缓存命中率降为零。

问题背景

该应用场景中缓存使用具有以下特点：

• 每秒多次读取操作
• 共配置了4个独立的缓存实例
• 部分缓存返回Optional包装的自定义类对象
• 两个缓存非常活跃（每秒数十万次get操作）
• 两个缓存相对不活跃

专家诊断思路

1. 缓存过期机制分析

Caffeine的过期清理机制采用惰性策略，主要在以下情况下触发：

• 写入操作时
• 足够数量的读取操作触发维护周期
• 显式调用清理方法

对于不活跃的缓存，过期条目可能不会立即被清理，导致内存暂时性增长。这种情况下，建议启用系统调度器(scheduler(Scheduler.systemScheduler()))，通过后台线程基于下一个过期时间触发维护操作。

2. 并发与性能考量

可能出现问题的几个关键点：

• 长时间运行的加载操作：如果自定义Redis客户端没有设置合理的网络超时，僵尸请求可能阻塞整个缓存操作
• ForkJoinPool.commonPool()过载：当默认执行器被I/O密集型任务占满时，缓存清理任务可能被延迟
• 哈希冲突：新条目与被移除条目位于同一哈希桶时，ConcurrentHashMap会阻塞移除操作直到完成

3. 内存分析建议

对于此类问题，专家建议采用以下诊断方法：

• 获取生产环境的JFR(Java Flight Recorder)记录
• 分析堆转储(Heap Dump)
• 启用原生内存跟踪(Native Memory Tracking)
• 收集线程转储(Thread Dump)
• 启用缓存统计信息(recordStats)

解决方案与实践

1. 配置优化

针对不同活跃度的缓存，可采取差异化配置：

// 高活跃度缓存配置
Caffeine.newBuilder()
    .expireAfterWrite(Duration.ofMinutes(60))
    .maximumSize(20_000)
    .scheduler(Scheduler.systemScheduler())
    .executor(Runnable::run) // 避免使用commonPool
    .build(key -> customRedisClient.getIsExpired(key));

// 低活跃度缓存配置
Caffeine.newBuilder()
    .expireAfterWrite(Duration.ofMinutes(60))
    .maximumSize(5_000)
    .build(key -> customRedisClient.getIsExpired(key));

2. 资源限制

确保Redis客户端配置了合理的超时：

// 示例Redis客户端配置
RedisClient client = RedisClient.create()
    .setDefaultConnectTimeout(Duration.ofSeconds(5))
    .setDefaultReadTimeout(Duration.ofSeconds(3));

3. JVM调优

对于现代JVM版本（Java 12+），可以利用以下特性：

• G1垃圾收集器的即时内存归还(JEP-346)
• ZGC的内存归还功能(JEP-351)
• 自适应GC调优(JEP-387)

建议配置：

-XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps

经验总结

1. 监控先行：在生产环境部署前，应该充分测试缓存的内存行为，特别是长时间运行的场景

2. 差异化配置：不同活跃度的缓存应该采用不同的配置策略

3. 防御性编程：所有外部依赖（如Redis）都应设置合理的超时

4. 工具链准备：提前配置好JFR、堆转储等诊断工具，便于快速定位问题

5. 渐进式优化：从简单配置开始，根据实际表现逐步调整参数

通过系统性的分析和针对性优化，可以有效解决Caffeine缓存的内存增长问题，同时保持良好的缓存命中率。关键在于理解缓存的工作机制，并根据实际使用场景进行合理配置。