那天上午，我正和同事在飞书里互相甩梗，忽然一连串红色警报像雨点一样砸向我的屏幕。监控平台显示：某台机器的 CPU Yi经逼近 90%，而日志里却只剩下几行毫无头绪的 INFO。心里一紧，我立刻打开 JConsole，结果页面上出现了一个巨大的红字：“JVM 堆Yi满”。于是一场“红色”风暴正式拉开帷幕。

在我们公司使用的是 Redisson 作为分布式锁和 Pub/Sub 的实现。Zui初选它，是因为它封装了大量底层细节，让我们Ke以像操作本地集合一样玩转 Redis。

然而这次告警的根源并不是网络抖动，也不是 Redis 本身卡顿，而是 Redisson 自己在内部维护的一张映射表——PublishSubscribeService#name2entry——不知何故开始“囤积”对象。

CPU 峰值：短时间内冲到 92% 左右；

堆内存占用：老年代瞬间膨胀至 880 MB 以上；

GC 日志：Old GC 持续出现，每次耗时 3 秒以上；

业务表现：会员任务派发服务响应迟缓，部分请求直接超时。

第一步——打开 VisualVM kan热图。我们把目标进程拖进 VisualVM，切换到 “Sampler → Memory”，点开 “Classes” 列表，一眼就kan到一个异常庞大的类：

org.redisson.pubsub.PublishSubscribeService

它占据了超过 800 MB 的保留大小，几乎成了整个堆的“主宰”。再点进去，kan它内部持有的 C​oncurrentHashMap, 条目数Yi经突破两百多万。

第二步——对比不同版本源码。

我们在 GitHub 上翻阅 Redisson 的历史提交记录（)，发现：

unsubscribe 在旧版中仅调用了 Redis 的 UNSUBSCRIBE 命令，却忘记把对应键从 name2entry 中移除；

自 3.11 起加入了显式删除逻辑（#remove)，彻底解决该问题。

第三步——回到业务代码。

我们的会员任务系统会对每个用户 ID 创建一个唯一的主题进行广播。每当用户完成某项任务，就往该主题推送一条消息，然后立刻调用 #unsubscribe 想要释放资源。可惜，在旧版 Redisson 中，这一步只撤销了订阅，却留下了一条“幽灵”记录在 map 里从此这条记录永远不会被 GC 回收。

SJDK 自带的 jvisualvm 插件或 YourKit dou提供 Dominator Tree 功Neng。在上述案例中，它帮助我们把注意力直接指向了那个占据近千兆空间的 Service 类，而不是在成千上万的小对象中盲目搜索。

SkyWalking 的仪表盘里有一栏专门展示 “Old GC 次数 / 单次耗时”。当这些指标异常升高时就意味着堆中可Neng存在不可回收的大块对象，此时立刻打开 VisualVM 检查即可。

Maven 插件生成 heap dump 后用 Eclipse Memory Analyzer 打开，同样Ke以kan到 “org.redisson.pubsub.PublishSubscribeService” 成为根节点，并列出所有未被清理的 key。这一步让我们确信问题不是偶然而是系统性的设计缺陷。

升级 Redisson 至Zui新稳定版 - 新增的 remove 调用彻底摆脱了 map 泄漏；

加装自检脚本 - 每隔五分钟统计 #name2entry.size, 若超过阈值则自动触发重启；

PUB/SUB 改造 - 将热点业务改为一次性消费模式，即不再频繁创建/销毁 topic，而是统一使用固定主题并在消息体中携带业务标识；

Tune JVM 参数 - 将老年代大小适当调小，并开启 G1 收集器以缩短 GC 暂停时间；

SLA 监控预警 - 在 SkyWalking 中新增 “PubSub Map Size” 指标，一旦突破预设阈值立即报警。

选库要kan release note：hen多库dou会在小版本中修复关键 bug，尤其是涉及集合管理或资源回收类功Neng，不要盲目依赖旧版文档。

MVP 不等于生产：开发环境跑通后一定要在压测环境模拟高并发订阅/取消场景，否则潜伏的问题会等到线上才暴露。

Druid / HikariCP 那套检查同样适用于 Redis 客户端：If you see a map’s size growing without bound, stop and dig.

The power of visual tools：A 张图往往胜过千行代码。VisualVM + MAT + SkyWalking 三剑客组合，是排查 Java 内存谜团的不二法门。

P.S. Ru果你现在还在使用 Redisson 的 3.x 系列，请务必核对一下你的具体版本号。Ru果仍停留在 3.10 以下请立刻安排升级计划，否则类似 “name2entry 未清理”的隐蔽坑随时可Neng再度出现，让你的服务器 陷入“高 CPU + 高内存”的噩梦。