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

肯定挂机 络绎不绝的来不一样类型的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. 解决或抛出