流式对话服务 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 里取的,网