记一次内存无法回收导致频繁fullgc机器假死的思路

目录

• 确定挂机 络绎不绝的来不同类型的bug
• 找到原因 把此问题复现出来
• 确定问题根源
• 总结

 

---

回到顶部

确定挂机 络绎不绝的来不同类型的bug

当bug滚滚而来时，不要怀疑，你的发布的应用基本是不可用状态了。
观察哨兵监控数据，特别是内存打到80%基本就挂机了，或者监控数据缺失也基本是挂机了。
此时应当马上决断：

• 通知运营暂停操作（大多数是因为后台应用导致的，纯经验猜测，因为你也不可能让外部用户停止操作）
• 重启大多数机器，保留一台机器保存现场（下线机器）。

实例：

• 友品app首页有频率的失败
• 运营提bug，后台导出每次都不可用，其他的偶现不可用

回到顶部

找到原因 把此问题复现出来

根据各方面的反馈，加自身的迭代，找寻线索，积极在预发尝试，以求确定病根。

• 最近上线内容
• 最近使用操作
• 最近超时接口

实例：
见上描述，导出每次不可用，马上在预发复现此问题。
感谢运营的反馈，此处可总结，运营在使用系统过程中出现问题要及时反馈，不要害羞。

回到顶部

确定问题根源

线上一般内存偏大，有6-8G，用jmap下来文件很大，也不易分析。
此时可转换思路，创建一个干净的环境，调试此固定逻辑。
这里的问题是线上数据怎么来？

1. dubbo 直连（不建议）
2. 通知运维导出线上数据

搭建本地环境，调试固定逻辑：

1. 相关业务逻辑迁移到本地（线上数据来源是2，此时需要导入数据，封装dao）
2. 本地设置 -xms-xmx为20M（设置本地使用内存）
3. jmap -histo 77710 >./Downloads/15.log 导出内存文件查看内存消耗
4. 分析并解决，如果是自己责任内则解决，否则抛出（纯能力和经验）

实例：
在本地环境调试后发现导出正常，20M内存可以支撑导出37万条数据没有问题。
此时回过头去看线上逻辑代码，比本地多一个文件加水印，此时修改代码，再文件生成后打印一条日志，部署预发。
发现文件可以生成，但文件加水印迟迟未结束。
去掉文件加水印后部署预发，导出正常。
此时排查出问题出在文件加水印，此为中间件的工具，故而不做解决，直接去掉加水印提测。并报告问题给相应人。

回到顶部

总结

1. 判断是否挂机
2. 通知运营暂停操作
3. 重启大多数机器，保留一台机器保存现场
4. 找到那个操作引起的此现象
5. 转为本地调试，找寻问题根源
6. 解决或抛出