一、GC监控
GC简述：
GC日志记录了内存使用和回收状态，出现内存故障时，可作为分析排查手段。
GC用于跟踪内存中的对象，回收哪些不再被其他对象引用的对象，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.
IBM JDK 的gc日志：
<AF[3004]: Allocation Failure. need 528 bytes, 20205 ms since last AF>
<AF[3004]: managing allocation failure, action=2 (0/2147482112)>
<GC(3004): GC cycle started Tue Jun 22 16:59:56 2010
<GC(3004): freed 306924344 bytes, 14% free (306924344/2147482112), in 184 ms>
<GC(3004): mark: 168 ms, sweep: 16 ms, compact: 0 ms>
<GC(3004): refs: soft 1 (age >= 32), weak 0, final 260, phantom 0>
<AF[3004]: completed in 184 ms>
<AF[3005]: Allocation Failure. need 528 bytes, 17079 ms since last AF>
<AF[3005]: managing allocation failure, action=2 (0/2147482112)>
<GC(3005): GC cycle started Tue Jun 22 17:00:14 2010
<GC(3005): freed 295474904 bytes, 13% free (295474904/2147482112), in 194 ms>
<GC(3005): mark: 178 ms, sweep: 16 ms, compact: 0 ms>
<GC(3005): refs: soft 0 (age >= 32), weak 0, final 239, phantom 0>
<AF[3005]: completed in 195 ms>
<AF[3006]: Allocation Failure. need 528 bytes, 18713 ms since last AF>
<AF[3006]: managing allocation failure, action=2 (0/2147482112)>
<GC(3006): GC cycle started Tue Jun 22 17:00:33 2010
<GC(3006): freed 300160160 bytes, 13% free (300160160/2147482112), in 195 ms>
<GC(3006): mark: 179 ms, sweep: 16 ms, compact: 0 ms>
<GC(3006): refs: soft 2 (age >= 32), weak 0, final 184, phantom 1>
<AF[3006]: completed in 197 ms>
2. 将GC日志输出到文件：不同JDK设置的参数不同，参考JDK官方文档
SUN：-Xloggc:filename （例如：-Xloggc:D:/gc.log）
IBM：-Xverbosegc:file=filename 或 -Xverbosegclog:filename
HP ：-Xverbosegc=filename
BEA JRockit:verbose:gc -Xverboselog:logfile
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
AIX: GCCollector GCViewer
SUN: GCViewer GCAnalyzer
二、内存问题描述
典型现象是系统运行一段时间后，报OutOfMemoryError错误、页面非常慢、不响应或完全不再接受请求，而此时通过观察JVM内存，发现内存急剧上升到最大值并居高不下。
这种问题出现后，往往很棘手，通常是由于应用程序不合理造成的，而不合理程序或内存泄漏的源头可能并不明显。本人的一次经历是，经过十多天各种测试手段后，最后确定问题是由一处String累加引起的，改成StringBuffer就解决了，可见，忽略“小问题”往往会带来大麻烦。
三、分析手段
1. 分析GC日志、系统日志
2. 程序中设置监控断点
3. 尽可能重现故障并同时监控JVM内存，找出引起内存急剧上升的规律
4. 检查关键程序或频繁使用的工具类的合理性
四、解决手段
1. 主要从程序入手：降低内存使用量；字符串累加时以StringBuffer代替String；随时释放不再需要的对象；SQL优化及避免频繁取出大量数据；Session中不要放大的数据。。。
2. 据WebSphere和WebLogic官方建议：通常情况下JVM的Heap最小值和最大值可设成一样.一般根据实际情况调整IBM JDK 1.4及以前版本： -Xms最好是-Xmx的一半;IBM JDK 1.5以及以后版本：主要看GC算法，如果默认GC算法，同上.如果是分代算法，相等也可以;SUN、BEA Jrockit、HP JDK，都是最好设置为相等。设置大小可取系统内存的25%-75%，保证JVM有合理足够的内存大小，还有一些代的比例和算法的设置，一般情况下只有压力反复测试，不断的调整和观测才能最终确定自己的应用设置的最合理。
3. 应用服务器的其他优化措施（多线程，异步调用等）
五、应急措施
1. 不设定JVM的最大Heap上限
2. 程序中判断内存吃紧时执行Runtime.gc()强制垃圾收集，此方式比自动收集彻底，可一定程度上改善内存利用效率
3. 在不影响业务的情况下，定期重启应用服务器
gc的action 说明：
[1] Performing a GC without using the wilderness. It is designed to avoid compactions by keeping the wilderness available for a large allocation request.
[2] Tried to allocate out of the wilderness and failed.
[3] Attempting to expand the heap.
[4] Clearing any remaining soft references. This is only done if there is less than 12% free space in a fully expanded heap.
[5] Trying to steal some space from the transient heap. Only applies to resettable mode.
[6] Not actually an action. It gives a verbosegc message that we are very low on heap space, or totally out of heap space
0 - 垃圾收集器试图从固化空闲链表中进行分配，但是失败了
1 - 垃圾收集器避免使用荒地，为了避免压缩动作，荒地留作大对象分配使用
2 - 垃圾收集器试图在荒地之外进行分配，但是失败了
3 - 垃圾收集器尝试扩展堆
4 - 垃圾收集器准备清理SoftReference。仅会在进行了完全的扩展之后，堆空闲还低于12%的情况下发生
5 - 仅在resettable 虚拟机发生。表示垃圾收集器试图从临时堆申请空间
6 - 不是一个动作，只是表示堆内空闲空间太少了
最后一行表示分配失败的耗时，包括停止以及重新启动应用线程的时间在内。
http://www.ibm.com/developerworks/ibm/library/i-garbage3.html