1、每天15萬 PV 的線上文件型別網站

環境：4 CPU，16GB 記憶體， 64位 CentOS 5.4

問題：網站失去響應

原先JVM配置：JDK1.5，  -Xmx12G  -Xms12G

解決過程：發現問題來自GC停頓（12G記憶體 的 Full GC 需要12秒），記憶體中暫存檔案導致“朝生夕滅”大量大物件，採用預設吞吐量優先收集器。

最終JVM配置：使用5個32位JDK作為邏輯叢集，每個程序2GB記憶體，Apache服務作為前端負載均衡，垃圾回收改為CMS回收。

2、叢集間同步導致的記憶體溢位

環境：兩臺伺服器，每臺2個CPU、8GB記憶體、啟動3個WebLogic，構成6個節點的親和式叢集，JBossCache作為全域性快取

問題：記憶體溢位。

解決過程：配置-XX：+HeapDumpOnOutOfMemoryError ，檢查heap檔案，發現是JBossCache問題，快取多次被寫，。

最後結論：快取可以頻繁讀，但是不能頻繁寫。

3、堆外記憶體導致的溢位

環境：1CPU，4GB記憶體，32位Window系統，小型B/S的電子考試系統，使用了CometD技術

問題：不定時丟擲記憶體溢位異常

原先配置：

解決過程：加入-XX：HeapDumpOnOutOfMemoryError 無果，使用jstat 無果，查日誌發現是Direct Memory 溢位：OutOfMemory:null, at  sun.misc.Unsafe.allocateMemory (Native Method)。

CometD技術 用到了NIO 技術。Direct Memory  不能像老生代、新生代那樣，發現空間不足了就通知收集器進行垃圾回收，他只能等待老生代Full GC的時候，順便幫他清理記憶體的廢棄物件，否則只能等待丟擲異常。

最後結論：除了Heap 和 Perm ，這些區域也會佔用記憶體： Direct Memory（-MaxDirectMemorySize）、執行緒棧 (-Xss)、Socket 快取、JNI程式碼、虛擬機器本身和GC

4、外部命令導致系統緩慢

環境：4CPU，Solaris，Glassfish

問題：請求響應慢，CPU使用率高

解決過程：通過Rumtime.getRuntime().exec() 執行外部shell指令碼, 啟動大量新程序，消耗大量時間。JVM執行Rumtime.getRuntime().exec() 流程：先複製一個與當前JVM擁有一樣環境變數的程序，再使用這個新的程序去執行外部命令，最後退出，這種呼叫方式即使命令很快能執行完成，頻繁建立程序的開銷也非常可觀。

解決方法：不使用shell 指令碼，使用Java API。

5、伺服器JVM程序崩潰

環境：2臺伺服器，2個CPU，8GB記憶體，WebLogic

問題：JVM自動關閉

解決過程：看日誌，"Java.net.SocketException:Connection reset" 。因為遠端連線到另外一個系統，呼叫另一個系統 完成Task，另一個系統處理速度非常慢，於是本系統積累了越來越多的等待執行緒和Socket連線。

解決方法：將呼叫另外一個系統的方式改成生產者-消費者模式的訊息佇列。 

6、不恰當資料結構導致記憶體佔用過大

環境：後臺RPC伺服器，64位虛擬機器

原先JVM配置：-Xms4g -Xmx8g -Xmn1g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 

問題：載入80M的資料檔案時候，每次Minor GC 造成停頓500 毫秒。

解決過程：看日誌，新生代有多次Minor GC還存在的大物件

解決方法：去掉Survivor，-XX:+SurviorRatio=65536  ; 加入引數 -XX: MaxTenuringThreshold=0  -XX:+AlwaysTenure，將Minor GC後的物件立即進入老生代。修改程式。

7、Windows 虛擬記憶體導致長時間停頓

環境：帶心跳檢查的GUI桌面程式，每15秒一次心跳

問題：心跳檢測有誤，偶爾1分鐘停頓

原先配置: -Xmx256M

解決過程：加入 -XX:PrintGCApplicaitonStoppedTime -XX:+PrintGCDateStamps -Xlooger:gclogs. 看日誌 .程式在最小化時候，其工作記憶體被自動交換到磁碟的頁面檔案中

加入：-Dsun.awt.keepWorkingSetOnMinimize=true