概述
本文介绍一次解决现场java内存泄漏问题的经过，希望能提供后续遇到类似情况的读者一点思路。
生产环境发现的问题问题
生产环境运维人员反馈，服务器(windows系统)卡死，相关的服务都运行异常，重启之后也没作用。通过运行管理器看到java进程内存占用5G，初步判断是程序内存泄漏。
基本解决方案
基本解决方案是先收集生产环境的jvm内存使用信息，线程信息，再利用工具进行进一步分析。
解决过程
1、收集jvm内存信息，线程信息
生产环境的操作系统是windows，机器需要先设置好JAVA_HOME环境变量。下面以java进程PID为12140，输出文件路径保存在C:\jvmtest 文件夹中为例。
1.1、收集内存使用基本情况统计
使用命令行命令：jmap -heap 12140 > C:\jvmtest\jmapheap
直接打开查看C:\jvmtest文件夹下面的jampheap文件，里面包含内存使用情况基本统计，可以确认问题原因不是jvm参数内存分配过小。
可以看到java堆内存基本已经用完。
1.2、收集所有java线程运行信息
使用命令行命令：jstack 12140 > C:\jvmtest\jstack
直接打开查看C:\jvmtest文件夹下面的jstack文件，里面包含所有java线程运行信息：
1.3、收集java内存详细使用信息
使用命令行命令：jmap -dump:format=b,file=C:\jvmtest\jmap_dump_all 12140
得到C:\jvmtest文件夹下面的jmap_dump_all文件，该内存dump文件有5G大小，二进制文件，不可直接查看，需要用工具查看。
2、基于工具分析
2.1、工具选择
如果dump文件比较小，推荐直接使用jdk自带的jvisiualvm工具进行打开，但是如果dump文件比较大，亲测jvisiualvm打开失败，这时推荐选择eclipse的内存分析工具：eclipse memory analyer(mat)
2.2、eclipse memory analye软件配置
这里选择从eclipse官网下载MemoryAnalyzer-1.7.0.20170613-win32.win32.x86_64.zip文件(也可以下载eclipse插件)，由于dump文件比较大，打开分析工具前需要修改eclipse memory analyer的内存配置：
最后一行修改为需要的内存大小
如果dump文件比较大的情况下，如果分析工具运行的环境机器内存太小是打不开的，机器可用内存至少要比dump文件大。
2.2、查看分析情况
打开eclipse memory analye软件，载入dump文件，看到以下信息：
2.3、问题定位
基于eclipse memory analye软件，可用定位到有1条线程名为pool-4-thread-1的线程，里面有一个ArrayList的对象，这个list对象保存了一系列的HashMap对象，总共有4G。
搜索 1.2步骤介绍的所有java线程信息的文件，可以得到pool-4-thread-1线程运行状态如下：基于此可以定位到有问题的代码。
2.4、问题原因定位
检查代码的时候发现，程序有一个模块，功能是从数据库定时查询数据然后数据做处理，模块中把查出来的数据基于log4j写到日志中，实际现场环境有时候定时查询得到的数据有几百兆，打印到日志文件中打印不过来。导致数据在内存中不断积压等待被打印，内存得不到释放。
总结
本次使用了JVM性能调优监控工具jstack、jamp，相关工具还有jstack、jmap、jhat、jstat，这些工具对于内存溢出，CPU飙升，线程死锁、等问题解决非常有帮助。
