记录一次典型oom的处理过程

背景

有同学反馈收到应用RT的报警,其中的流量都来自于网关集群中的一台机器。因为负责网关,就上去看了下并进行排查。整体是一个比较明显的oom,这里只是记录下排查过程,老司机可以略过了。

初步现象

常规步骤,使用top 和jstat -gcutil 能直观的看到在拼命full gc。推测是出现了oom。

初步排查

一开始是用 jmap -histo:live pid >a.log 导出当前内存对象,为什么没有直接用jmap -dump:live 也是想偷懒,因为-dump 生成的文件太大,我们的服务器又跑在k8s上面,要拿回本地需要通过ftp 中转,想着能省就省。结果发现这个给后面埋了个大坑。

基于上面的结果,一度怀疑是sentinel 引起的问题。特别是对比了正常的机器上的内存分布

在上面浪费了大量时间,后面回过头看其实ConcurrentHashMap 占比这么高说明是缓存管理出现了问题。

进一步排查

老老实实用 jmap -dump:live,format=b,file=xxx.xxx pid 打印出详细的内存堆栈,拿到本地后用 IBM HeapAnalyzer(比较好用) 或者MAT 打开分析。

从上面比较直观看到出现oom的类。这里只是看到单个的类比较大,从源码上看:

会发现有块缓存没有设置长度和失效时间,这个很可能是导致oom的原因。

相关推荐
莫得感情 o9 分钟前
踩坑 - 压测三轮后 502:一个默认 10 的连接池如何拖垮整个服务
java
Escalating_xu10 分钟前
【Linux线程】线程控制全解析:终止、join/detach、cancel、线程栈与 NPTL(下篇)
java·linux·运维
2602_9599609220 分钟前
电商大厂Java面试实录:Spring Boot/JVM/Redis/Kafka/微服务/安全/测试全解析
java·jvm·spring boot·redis·面试题
吃饱了得干活36 分钟前
限界上下文之后:微服务怎么拆、上下文怎么聊?
java·后端·架构
yngsqq1 小时前
窗体快速取消
java·开发语言
岁月如歌77861 小时前
一次讲透 Redis 缓存击穿、穿透、雪崩,从原理到实战解决方案
java·后端·架构
AI多Agent协作实战派2 小时前
AI多Agent协作系统实战(四十六):改了十次规则,AI员工还是老样子——会话缓存的坑
java·spring·缓存
一知半解仙2 小时前
当机器人学会泛化,而我在写Java:一名后端开发者的2026年8月21日观察手记
java·开发语言·机器人
葡萄成熟时 !10 小时前
JAVA 常用API学习笔记
java·笔记·学习
Rain的Java大神之路11 小时前
介绍一下分布式事务
java·分布式·后端·spring·spring cloud·架构·springcloud