ConcurrentHashMap$Node无法被GC回收致堆内存累积问题求助

针对你遇到的ConcurrentHashMap$Node无法被GC回收、堆内存持续增长的问题，可从以下几个方向排查和解决：

1. 确认缓存移除操作的完整性 #

首先排查业务流程中，是否所有调用initNewCache创建的缓存条目，最终都执行了removeCache。比如：

• 异常分支（如try/catch中遗漏remove）
• 异步任务、线程池中的流程未触发remove
• 业务逻辑中某些场景下跳过了移除步骤

可以通过日志记录每个mainSpanId的创建和移除次数，对比是否存在未被清理的条目——如果有未移除的条目，Node会被强引用持续持有，自然无法被GC回收。

2. 主动触发ConcurrentHashMap的懒删除清理 #

ConcurrentHashMap的删除操作采用懒删除机制：调用remove时仅将节点标记为deleted，并不会立即从链表/红黑树中移除，只有当后续的get/put/size等操作遍历到该节点时，才会真正清理。如果你的缓存键分布分散，部分桶长期未被访问，这些标记为删除的Node就会累积在内存中。

解决方法是主动触发清理：添加定时任务定期遍历Map或调用size()，触发内部的清理逻辑：

@Component
public class ZipkinTraceCacheManager {
    private final Map<String, ZipkinTraceCache> threadCaches = new ConcurrentHashMap<>();
    
    // 其他原有方法...

    // 定时触发清理，频率根据业务调整
    @Scheduled(fixedRate = 5, timeUnit = TimeUnit.MINUTES)
    public void cleanStaleNodes() {
        // 遍历Map触发节点清理
        threadCaches.forEach((k, v) -> {});
        // 或调用size()，同样会遍历所有桶触发清理
        // threadCaches.size();
    }
}

3. 替换为适合短生命周期缓存的组件 #

ConcurrentHashMap本身是通用的并发Map，并非专门为缓存场景设计。对于短生命周期、需要自动清理的缓存需求，推荐使用专门的缓存库，比如Caffeine（性能优于Guava Cache），它内置了自动过期、内存回收机制，无需手动处理Node累积问题：

@Component
public class ZipkinTraceCacheManager {
    private final Cache<String, ZipkinTraceCache> threadCaches = Caffeine.newBuilder()
            // 设置缓存条目访问后过期时间，根据业务实际调整
            .expireAfterAccess(5, TimeUnit.MINUTES)
            // 并发级别，建议设为CPU核心数
            .concurrencyLevel(Runtime.getRuntime().availableProcessors())
            .build();

    public ZipkinTraceCache getCache(String mainSpanId) {
        return threadCaches.getIfPresent(mainSpanId);
    }

    public void removeCache(String mainSpanId) {
        threadCaches.invalidate(mainSpanId);
    }

    public String initNewCache(Span mainSpan) {
        String mainSpanId = mainSpan.context().spanId();
        ZipkinTraceCache zipkinTraceCache = new ZipkinTraceCache();
        zipkinTraceCache.setMainSpan(mainSpan);
        threadCaches.put(mainSpanId, zipkinTraceCache);
        return mainSpanId;
    }
}

4. 排查引用泄漏 #

如果以上方法无效，建议使用内存分析工具（如MAT、VisualVM）分析堆快照，查看ConcurrentHashMap$Node的引用链：

• 确认是否有其他外部对象（如线程局部变量、未关闭的资源）持有ZipkinTraceCache实例，导致即使从Map中移除，Node仍无法被GC回收。
• 检查Node实例的引用路径，定位到未释放的强引用来源。

内容的提问来源于stack exchange，提问作者Mister1Burger