1. 監控GC的狀態

　　使用各種JVM工具，查看當前日志，分析當前JVM參數設置，并且分析當前堆內存快照和gc日志，根據實際的各區域內存劃分和GC執行時間，覺得是否進行優化。

　　2. 系統崩潰前的一些現象：

　　每次垃圾回收的時間越來越長，由之前的10ms延長到50ms左右，FullGC的時間也有之前的0.5s延長到4、5s

　　FullGC的次數越來越多，最頻繁時隔不到1分鐘就進行一次FullGC

　　年老代的內存越來越大并且每次FullGC后年老代沒有內存被釋放

　　之后系統會無法響應新的請求，逐漸到達OutOfMemoryError的臨界值，這個時候就需要分析JVM內存快照dump。

　　3. 生成堆的dump文件

　　通過JMX的MBean生成當前的Heap信息，大小為一個3G(整個堆的大小)的hprof文件，如果沒有啟動JMX可以通過Java的jmap命令來生成該文件。

　　4. 分析dump文件

　　打開這個3G的堆信息文件，顯然一般的Window系統沒有這么大的內存，必須借助高配置的Linux，幾種工具打開該文件：

　　Visual VM

　　IBM HeapAnalyzer

　　JDK 自帶的Hprof工具

　　Mat(Eclipse專門的靜態內存分析工具)推薦使用

　　備注：文件太大，建議使用Eclipse專門的靜態內存分析工具Mat打開分析。

　　5. 分析結果，判斷是否需要優化

　　如果各項參數設置合理，系統沒有超時日志出現，GC頻率不高，GC耗時不高，那么沒有必要進行GC優化，如果GC時間超過1-3秒，或者頻繁GC，則必須優化。

　　注：如果滿足下面的指標，則一般不需要進行GC：

　　Minor GC執行時間不到50ms;

　　Minor GC執行不頻繁，約10秒一次;

　　Full GC執行時間不到1s;

　　Full GC執行頻率不算頻繁，不低于10分鐘1次;

　　6.調整GC類型和內存分配

　　如果內存分配過大或過小，或者采用的GC收集器比較慢，則應該優先調整這些參數，并且先找1臺或幾臺機器進行beta，然后比較優化過的機器和沒有優化的機器的性能對比，并有針對性的做出最后選擇。

　　7. 不斷的分析和調整

　　通過不斷的試驗和試錯，分析并找到最合適的參數，如果找到了最合適的參數，則將這些參數應用到所有服務器。