1. 监控GC的状态，使用各种JVM工具，查看当前日志，分析当前JVM参数设置，并且分析当前堆内存快照和gc日志，根据实际的各区域内存划分和GC执行时间，觉得是否进行优化。

　　举一个例子：系统崩溃前的一些现象：

　　- 每次垃圾回收的时间越来越长，由之前的10ms延长到50ms左右，FullGC的时间也有之前的0.5s延长到4、5s

　　- FullGC的次数越来越多，最频繁时隔不到1分钟就进行一次FullGC

　　- 年老代的内存越来越大并且每次FullGC后年老代没有内存被释放 之后系统会无法响应新的请求，逐渐到达OutOfMemoryError的临界值，这个时候就需要分析JVM内存快照dump。

　　2. 生成堆的dump文件 通过JMX的MBean生成当前的Heap信息，大小为一个3G(整个堆的大小)的hprof文件，如果没有启动JMX可以通过Java的jmap命令来生成该文件。

　　3. 分析dump文件打开这个3G的堆信息文件，显然一般的Window系统没有这么大的内存，必须借助高配置的Linux，几种工具打开该文件：

　　- Visual VM - IBM HeapAnalyzer

　　- JDK 自带的Hprof工具

　　- Mat(Eclipse专门的静态内存分析工具)推荐使用

　　备注：文件太大，建议使用Eclipse专门的静态内存分析工具Mat打开分析。

　　4. 分析结果，判断是否需要优化 如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化，如果GC时间超过1-3秒，或者频繁GC，则必须优化。

　　注：如果满足下面的指标，则一般不需要进行GC：

　　- Minor GC执行时间不到50ms;

　　- Minor GC执行不频繁，约10秒一次;

　　- Full GC执行时间不到1s;

　　- Full GC执行频率不算频繁，不低于10分钟1次;

　　5. 调整GC类型和内存分配 如果内存分配过大或过小，或者采用的GC收集器比较慢，则应该优先调整这些参数，并且先找1台或几台机器进行beta，然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择。

　　6. 不断的分析和调整 通过不断的试验和试错，分析并找到最合适的参数，如果找到了最合适的参数，则将这些参数应用到所有服务器。