流式对话服务 OOM，堆转储里有 47 万个 ByteBuffer 十一月中旬的一个周一早上，告警炸了：智能客服服务的三个实例在 20 分钟内相继 OOM 重启。这个服务上线两个月一直很稳，堆 8 GB，平时使用率 40% 左右。 这篇是完整的排查过程。结论不复杂——流式响应没有正确关闭，但排查过程
内存曲线像极了漏水的水龙头 订单服务上线两周，Old 区内存从 1.2G 缓慢爬到 3.8G，Full GC 后也只回一点，没真正回落。不是突崩，是慢性失血。这种"缓增长"最容易被忽视，因为单次看都正常，直到某天 Old 区满了频繁 Full GC，接口全抖。我用多次 dump 对比把它揪出来，过程
RSS 涨到 5.8 GB，但堆才用了 1.2 GB，也没 OOM 4 月底值班，监控告警：订单服务一个实例的容器内存（RSS）从 2 GB 缓慢涨到 5.8 GB，持续了四天还在涨，但没有抛 OutOfMemoryError。K8s 的内存 limit 是 6 GB，再涨就要被 OOMKilled
客服工单里的串号：A 用户看到了 B 用户的手机号 7 月初的一个下午，客服转过来一张截图：用户 A 在个人中心看到的手机号，是另一个用户的。我第一反应是不信，把那串号码脱敏后在库里一查，确实属于用户 B，两个人八竿子打不着。 我们那个接口长这样，用户信息是从一个 ThreadLocal 里取的，网
