jboss内存泄漏导致服务宕机故障排查及分析处理

问题描述

现有公司某产品运行在jboss上，线上运行一段时间后会出现宕机现象，宕机频率为2周左右。每次宕机后需要重新启动jboss后应用才可使用。运维人员已经多次反馈，此问题影响客户体验，急需解决。

问题排查思路

1. 网络层。运维人员已有监控，对jboss应用HTTP接入端口9999进行了监听，如果9999端口无响应时，应用无法对外提供服务。此时在网络层Telnet检查9999端口是否可用，同时发送HTTP请求，检查是否有返回。
2. 线程日志。抓取线程日志，检查是否存在死锁等情况。
3. 内存堆栈。抓取线程日志，分析是否存在超大对象未释放。
4. 分析jboss日志，对gc.log、boot.log、server.log等jboss日志与应用日志进行分析，检查报错信息。

问题排查步骤

准备应用日志抓取脚本

1. 网络监听脚本：checklink.sh
2. 应用端口状态脚本：checknetstat.sh
3. 线程日志脚本：checkjstack.sh
4. 内存堆栈脚本: checkjmap.sh
   具体脚本内容见附件1

应用正常运行时抓取对照组

应用正常运行时，执行日志抓取脚本得到日志文件，作为结果对照组。

宕机时抓取日志

应用宕机时，执行日志抓取脚本，抓取错误日志。并取下当天jboss日志与应用日志。

结果分析

对比两次checklink.sh结果

端口都是处于监听状态，配置应用端口与对照组一致。初步排除网络问题，问题应该在应用层。

对比两次checkjstack.sh结果

两次结果中，比参照组中少了红色部分，当中并未异常线程，同时整个日志中并未查询到死锁等情况。初步排除应用有线程死锁等现象。

对比两次checkjmap.sh结果

将jmap执行出的.hprof文件，使用Eclipse Memory Analyzer Tools进行分析，整体内存占用情况如下：

对比两次结果，内存明显增长，逼近配置的最大内存1G。对照组为宕机前3天获取，3天内存由原来的761增长至941。
分析宕机时的内存最大的对象