记一次内存无法回收导致频繁fullgc机器假死的思路
确定挂机 络绎不绝的来不同类型的bug
当bug滚滚而来时，不要怀疑，你的发布的应用基本是不可用状态了。
观察哨兵监控数据，特别是内存打到80%基本就挂机了，或者监控数据缺失也基本是挂机了。
此时应当马上决断：
- 通知运营暂停操作（大多数是因为后台应用导致的，纯经验猜测，因为你也不可能让外部用户停止操作）
- 重启大多数机器，保留一台机器保存现场（下线机器）。
实例：
- 友品app首页有频率的失败
- 运营提bug，后台导出每次都不可用，其他的偶现不可用
找到原因 把此问题复现出来
根据各方面的反馈，加自身的迭代，找寻线索，积极在预发尝试，以求确定病根。
- 最近上线内容
- 最近使用操作
- 最近超时接口
实例：
见上描述，导出每次不可用，马上在预发复现此问题。
感谢运营的反馈，此处可总结，运营在使用系统过程中出现问题要及时反馈，不要害羞。
确定问题根源
线上一般内存偏大，有6-8G，用jmap下来文件很大，也不易分析。
此时可转换思路，创建一个干净的环境，调试此固定逻辑。
这里的问题是线上数据怎么来？
- dubbo 直连（不建议）
- 通知运维导出线上数据
搭建本地环境，调试固定逻辑：
- 相关业务逻辑迁移到本地（线上数据来源是2，此时需要导入数据，封装dao）
- 本地设置 -xms-xmx为20M（设置本地使用内存）
- jmap -histo 77710 >./Downloads/15.log 导出内存文件查看内存消耗
- 分析并解决，如果是自己责任内则解决，否则抛出（纯能力和经验）
实例：
在本地环境调试后发现导出正常，20M内存可以支撑导出37万条数据没有问题。
此时回过头去看线上逻辑代码，比本地多一个文件加水印，此时修改代码，再文件生成后打印一条日志，部署预发。
发现文件可以生成，但文件加水印迟迟未结束。
去掉文件加水印后部署预发，导出正常。
此时排查出问题出在文件加水印，此为中间件的工具，故而不做解决，直接去掉加水印提测。并报告问题给相应人。
总结
- 判断是否挂机
- 通知运营暂停操作
- 重启大多数机器，保留一台机器保存现场
- 找到那个操作引起的此现象
- 转为本地调试，找寻问题根源
- 解决或抛出
