如何监控GC及内存问题解决方案概述
内存问题错综复杂，本人水平也有限，浅薄之见仅供参考。
一、GC监控
GC日志记录了内存使用和回收状态，出现内存故障时，可作为分析排查手段。
1. 启用GC监控的方法：增加java启动参数-verbose:gc，输出信息的样例：
2. 将GC日志输出到文件：不同JDK设置的参数不同，参考JDK官方文档
SUN：-Xloggc:filename （例如：-Xloggc:D:/gc.log）
IBM：-Xverbosegc:file=filename 或 -Xverbosegclog:filename
HP ：-Xverbosegc=filename
3. 如何设置Java启动参数：有多种方式，以下各举一例
Tomcat：在catalina.bat的“set JAVA_OPTS=%JAVA_OPTS% ”后设置
WebLogic：在startWebLogic.cmd的“%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% ”后设置
WebSphere：进入管理控制台，应用服务器->进程定义->Java虚拟机高级定义
4. GC日志的图形分析工具：HP的jtune
二、内存问题描述
典型现象是系统运行一段时间后，报OutOfMemoryError错误、页面非常慢、不响应或完全不再接受请求，而此时通过观察JVM内存，发现内存急剧上升到最大值并居高不下。
这种问题出现后，往往很棘手，通常是由于应用程序不合理造成的，而不合理程序或内存泄漏的源头可能并不明显。本人的一次经历是，经过十多天各种测试手段后，最后确定问题是由一处String累加引起的，改成StringBuffer就解决了，可见，忽略“小问题”往往会带来大麻烦。
三、分析手段
1. 分析GC日志、系统日志
2. 程序中设置监控断点
3. 尽可能重现故障并同时监控JVM内存，找出引起内存急剧上升的规律
4. 检查关键程序或频繁使用的工具类的合理性
四、解决手段
1. 主要从程序入手：降低内存使用量；字符串累加时以StringBuffer代替String；随时释放不再需要的对象；SQL优化及避免频繁取出大量数据；Session中不要放大的数据。。。
2. 据WebSphere和WebLogic官方建议：通常情况下JVM的Heap最小值和最大值可设成一样（根据实际情况调整），可取系统内存的25%-75%，保证JVM有合理足够的内存大小
3. 应用服务器的其他优化措施
五、应急措施
1. 不设定JVM的最大Heap上限
2. 程序中判断内存吃紧时执行Runtime.gc()强制垃圾收集，此方式比自动收集彻底，可一定程度上改善内存利用效率
3. 在不影响业务的情况下，定期重启应用服务器
一、GC监控
GC日志记录了内存使用和回收状态，出现内存故障时，可作为分析排查手段。
1. 启用GC监控的方法：增加java启动参数-verbose:gc，输出信息的样例：
引用
GC 135: total final references 4390; cleared final references 8.
GC 135: total phantom references 0; cleared phantom references 0.
GC 135: total old soft references 0; cleared old soft references 0.
GC 135: total JNI global weak references 0; cleared JNI global weak references 0.
GC 136: starting collection, maximum allocation reached.
GC 136: live objects 1081046; collected objects 6038; collected(KB) 558.
GC 136: queued for finalization 0; total soft references 113; cleared soft references 18.
GC 136: current heap(KB) 716784; current threshold(KB) 262144.
GC 136: collect (milliseconds) 1314.
GC 136: current cycle allocation(KB) 0; previous cycle allocation(KB) 532.
GC 136: total weak references 1321; cleared weak references 0.
GC 135: total phantom references 0; cleared phantom references 0.
GC 135: total old soft references 0; cleared old soft references 0.
GC 135: total JNI global weak references 0; cleared JNI global weak references 0.
GC 136: starting collection, maximum allocation reached.
GC 136: live objects 1081046; collected objects 6038; collected(KB) 558.
GC 136: queued for finalization 0; total soft references 113; cleared soft references 18.
GC 136: current heap(KB) 716784; current threshold(KB) 262144.
GC 136: collect (milliseconds) 1314.
GC 136: current cycle allocation(KB) 0; previous cycle allocation(KB) 532.
GC 136: total weak references 1321; cleared weak references 0.
2. 将GC日志输出到文件：不同JDK设置的参数不同，参考JDK官方文档
SUN：-Xloggc:filename （例如：-Xloggc:D:/gc.log）
IBM：-Xverbosegc:file=filename 或 -Xverbosegclog:filename
HP ：-Xverbosegc=filename
3. 如何设置Java启动参数：有多种方式，以下各举一例
Tomcat：在catalina.bat的“set JAVA_OPTS=%JAVA_OPTS% ”后设置
WebLogic：在startWebLogic.cmd的“%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% ”后设置
WebSphere：进入管理控制台，应用服务器->进程定义->Java虚拟机高级定义
4. GC日志的图形分析工具：HP的jtune
二、内存问题描述
典型现象是系统运行一段时间后，报OutOfMemoryError错误、页面非常慢、不响应或完全不再接受请求，而此时通过观察JVM内存，发现内存急剧上升到最大值并居高不下。
这种问题出现后，往往很棘手，通常是由于应用程序不合理造成的，而不合理程序或内存泄漏的源头可能并不明显。本人的一次经历是，经过十多天各种测试手段后，最后确定问题是由一处String累加引起的，改成StringBuffer就解决了，可见，忽略“小问题”往往会带来大麻烦。
三、分析手段
1. 分析GC日志、系统日志
2. 程序中设置监控断点
3. 尽可能重现故障并同时监控JVM内存，找出引起内存急剧上升的规律
4. 检查关键程序或频繁使用的工具类的合理性
四、解决手段
1. 主要从程序入手：降低内存使用量；字符串累加时以StringBuffer代替String；随时释放不再需要的对象；SQL优化及避免频繁取出大量数据；Session中不要放大的数据。。。
2. 据WebSphere和WebLogic官方建议：通常情况下JVM的Heap最小值和最大值可设成一样（根据实际情况调整），可取系统内存的25%-75%，保证JVM有合理足够的内存大小
3. 应用服务器的其他优化措施
五、应急措施
1. 不设定JVM的最大Heap上限
2. 程序中判断内存吃紧时执行Runtime.gc()强制垃圾收集，此方式比自动收集彻底，可一定程度上改善内存利用效率
3. 在不影响业务的情况下，定期重启应用服务器