1.概述

  前面三篇介紹了處理Java虛擬機記憶體問題的知識與工具，在處理實際項目的問題 時，除了知識與工具外，經驗也是一個很重要的因素。因此本章將與讀者分享幾個比較 有代表性的實際案例。考慮到虛擬機故障處理和調優主要面向各類服務端應用，而大部 分Java程式員較少有機會直接接觸生產環境的伺服器，因此本章還準備了一個所有開發人員都能夠進行“親身實戰”的練習，希望通過實踐使讀者獲得故障處理和調優的經驗。

2. 案例分析

  本章中的案例大部分來源於處理過的一些問題，還有一小部分來源於網上有特色和代表性的案例總結。出於對客戶商業信息保護的目的，在不影響前後邏輯的前提 下，筆者對實際環境和用戶業務做了一些屏蔽和精簡。

  2.1 高性能硬體上的程式部署策略

  一個15萬PV/天左右的線上文檔類型網站最近更換了硬體系統，新的硬體為4個CPU、16GB物理記憶體，操作系統為64位CentOS 5.4, Resin作為Web伺服器。整個 伺服器暫時沒有部署別的應用，所有硬體資源都可以提供給訪問量並不算太大的網站使 用。管理員為了儘量利用硬體資源選用了 64位的JDK 1.5,並通過-Xmx和-Xms參數 將Java堆固定在12GB。使用一段時間後發現使用效果並不理想，網站經常不定期出現 長時間沒有響應的現象。

  監控伺服器運行狀況後發現網站沒有響應是由GC停頓導致的，虛擬機運行在 Server模式，預設使用吞吐量優先收集器，回收12GB的堆，一次Full GC的停頓時間 高達14秒。並且由於程式設計的關係，訪問文檔時要把文檔從磁碟提取到記憶體中，導 致記憶體中出現很多由文檔序列化產生的大對象，這些大對象很多都進入了老年代，沒有 在Minor GC中清理掉。這種情況下即使有12GB的堆，記憶體也很快會被消耗殆盡，由 此導致每隔十幾分鐘出現十幾秒的停頓，令網站開發人員和管理員感到很沮喪。

  這裡先不延伸討論程式代碼問題，程式部署上的主要問題顯然是過大的堆記憶體進行 回收時帶來的長時間的停頓。硬體升級前使用32位系統1.5GB的堆，用戶只感到訪問 網站比較緩慢，但不會發生十分明顯的停頓，因此才考慮升級硬體提升程式效能，如果 重新縮小給Java堆分配的記憶體，那麼硬體上的投資就浪費了。

  在高性能硬體上部署程式，目前主要有兩種方式：

• 通過64位JDK來使用大記憶體。
• 使用若幹個32位虛擬機建立邏輯集群來利用硬體資源。

  此案例中的管理員採用了第一種部署方式。對於用戶交互性強、對停頓時間敏感的 系統，可以給Java虛擬機分配超大堆的前提是有把握把應用程式的Full GC頻率控制得足夠低，至少要低到不會影響用戶使用，譬如十幾個小時乃至一天才出現一次Full GC, 這樣可以通過在深夜執行定時任務的方式觸發Full GC甚至自動重啟應用伺服器來將記憶體可用空間保持在一個穩定的水平。

  控制Full GC頻率的關鍵是看應用中絕大多數對象能否符合“朝生夕滅”的原則， 即大多數對象的生存時間不應當太長，尤其是不能產生成批量的、長生存時間的大對 象，這樣才能保障老年代空間的穩定。

  在大多數網站形式的應用里，主要對象的生存周期都應該是請求級或頁面級的， 會話級和全局級的長生命對象相對很少。只要代碼寫得合理，應當都能實現在超大堆中正常使用而沒有Full GC,這樣的話，使用超大堆記憶體時，網站響應的速度才比較有保證。除此之外，如果計劃使用64位JDK來管理大記憶體，還需要考慮下麵可能面臨的問題：

• 記憶體回收導致的長時間停頓
• 現階段，64位JDK的性能測試接結果普遍低於32位JDK
• 需要保證程式足夠穩定，因為這種應用要是產生堆溢出幾乎就無法產生堆轉儲快 照（因為要產生十幾GB乃至更大的dump文件），哪怕產生了快照也幾乎無法進 行分析。
• 相同的程式在64位JDK中消耗的記憶體一般比32位JDK大，這是由指針膨脹及數據類型對齊補白等因素導致的。

  上面的問題聽起來有點嚇人，所以現階段不少管理員還是選擇第二種方式：使用若 幹個32位虛擬機建立邏輯集群來利用硬體資源。具體做法是在一臺物理機器上啟動多 個應用伺服器進程，給每個伺服器進程分配不同的埠，然後在前端搭建一個負載均衡 器，以反向代理的方式來分配訪問請求。讀者不需要太在意均衡器轉發所消耗的性能, 即使使用64位JDK,許多應用也不止有一臺伺服器，因此在許多應用中前端的均衡器 總是要存在的。

  考慮到在一臺物理機器上建立邏輯集群的目的僅僅是儘可能地利用硬體資源，並不 需要關心狀態保留、熱轉移之類的高可用性需求，也不需要保證每個虛擬機進程有絕對 準確的均衡負載，因此使用無Session複製的親合式集群是一個相當不錯的選擇。我們 僅僅需要保障集群具備親和性，也就是均衡器按一定的規則演算法（一般根據SessionlD 分配）將一個固定的用戶請求永遠分配到固定的一個集群節點進行處理即可，這樣程式開發階段就基本不用為集群環境做什麼特別的考慮。

  當然，很少有沒有缺點的方案，如果讀者計劃使用邏輯集群的方式來部署程式，可 能會遇到下麵一些問題：

• 儘量避免節點競爭全局的資源，最典型的就是磁碟競爭，各個節點如果同時訪問 某個磁碟文件的話（尤其是併發寫操作容易出現問題），很容易導致IO異常。
• 很難最高效率地利用某些資源池，譬如連接池，一般都是在各個節點建立自己 獨立的連接池，這樣有可能導致一些節點池滿了而另外一些節點仍有較多空餘。儘管可以使用集中式的JNDI,但這有一定的複雜性並且可能帶來額外的 性能代價。
• 大量使用本地緩存（如大量使用HashMap作為K/V緩存）的應用，在邏輯集群中會造成較大的記憶體浪費，因為每個邏輯節點上都有一份緩存，這時可以考慮把 本地緩存改為集中式緩存。
• 各個節點仍然不可避免地受到32位的記憶體限制，在32位Windows平臺中每個進程只能使用2GB的記憶體，考慮到堆以外的記憶體開銷，堆一般最多只能開到1.5GB。在某些Linux, Unix系統（如Solaris）中，可以提升到3GB乃至接近4GB的記憶體，但32位中仍然受最高4GB （232）記憶體的限制。

  介紹完這兩種部署方式，再重新回到這個案例之中，最後的部署方案調整為建立5個32位JDK的邏輯集群，每個進程按2GB記憶體計算（其中堆固定為1.5GB）,占用了 10GB的記憶體。另外建立一個Apache服務作為前端均衡代理訪問門戶。考慮到用戶對響 應速度比較關心，並且文檔服務的主要壓力集中在磁碟和記憶體訪問上，CPU資源敏感度 較低，因此改為CMS收集器進行垃圾回收。部署方式調整後，服務再沒有出現長時間 停頓，速度比硬體升級前有較大提升。

  2.2 集群間同步導致的記憶體溢出

  一個基於B/S的MIS系統，硬體為兩台2個CPU、8GB記憶體的HP小型機，伺服器 是WebLogic 9.2,每台機器啟動了 3個WebLogic實例，構成一個6個節點的親合式集 群。由於是親合式集群，節點之間沒有進行Session同步，但是有一些需求要實現部分 數據在各個節點間共享。開始這些數據存放在資料庫中，但由於讀寫頻繁競爭很激烈， 對性能的影響較大，後面使用JBossCache構建了一個全局緩存。全局緩存啟用後，服務 正常使用了較長的一段時間。但最近不定期地多次出現記憶體溢出問題。

  在不出現記憶體溢出異常的時候，服務記憶體回收狀況一直正常，每次記憶體回收後都能 恢復到一個穩定的可用空間，開始懷疑是程式的某些不常用的代碼路徑中存在記憶體泄 漏，但管理員反映最近程式並未更新或升級過，也沒有進行什麼特別的操作。只好讓服 務帶著-XX:+HeapDumpOnOutOfMemoryEiror參數運行了一段時間。在最近一次溢出之 後，管理員發回了 heapdump文件，發現裡面存在著大量的org.jgroups.protocols.pbcast. NAKACK 對象。

  JBossCache是基於自家的JGroups進行集群間的數據通信，JGroups使用協議棧的方式來實現收發數據包的各種所需特性的自由組合，數據包接收和發送時要經過每層協議棧的up（）和down（）方法，其中的NAKACK棧用於保障各個包的有效順序及重發，JBossCache的協議棧如圖5-1所示。

  由於信息有傳輸失敗需要重發的可能性，在確認所有註冊在GMS (Group Membership Service)的節點都收到正確的信息前，發送的信息必須在記憶體中保留。而 此MIS的服務端中有一個負責安全校驗的全局Filter,每當接收到請求時，均會更新一 次最後的操作時間，並且將這個時間同步到所有的節點中，使得一個用戶在一段時間內 不能在多台機器上登錄。在服務使用過程中，往往一個頁面會產生數次乃至數十次的請 求，因此這個過濾器導致集群各個節點之間的網路交互非常頻繁。當網路情況不能滿足 傳輸要求時，重發數據在記憶體中不斷地堆積，很快就產生了記憶體溢出。

  這個案例中的問題，既有JBossCache的缺陷，也有MIS系統實現方式上的缺陷。 JBossCache官方的maillist中討論過很多次類似的記憶體溢出異常問題，據說後續版本有 了改進。而更重要的缺陷是這一類被集群共用的數據如果要使用類似JBossCache這種集群緩存來同步的話，可以允許讀操作頻繁，因為數據在本地記憶體有一份副本，讀取的動 作不會耗費多少資源，但不應當有過於頻繁的寫操作，這會帶來很大的網路同步的開銷。

  2.3 堆外記憶體導致的溢出錯誤

  這是一個學校的小型項目：基於B/S的電子考試系統，為了實現客戶端能實時地從服務端接收考試數據，系統使用了逆向AJAX技術（也成為Comet或Server Side Push），選用CometD 1.1.1 作為伺服器推送框架，伺服器是jetty 7.4.1，硬體為一臺普通PC機，Core i5 CPU，4GB記憶體，運行32位Windows操作系統。

  測試期間發現服務端不定時拋出記憶體溢出異常，伺服器不一定每次都會出現異常， 但假如正式考試時崩潰一次，那估計整場電子考試都會亂套，網站管理員嘗試過把堆開 到最大，32位系統最多到1.6GB基本無法再加大了，而且開大了也基本沒效果，拋出內 存溢出異常好像更加頻繁了。加入-XXi+HeapDumpOnOutOfMemoryError,居然也沒有 任何反應，拋出記憶體溢出異常時什麼文件都沒有產生。無奈之下只好掛著jstat使勁盯屏 幕，發現GC並不頻繁，Eden區、Survivor區、老年代及永久代記憶體全部都表示“情緒 穩定，壓力不大”，但照樣不停地拋出記憶體溢出異常，管理員壓力很大。最後，在記憶體 溢出後從系統日誌中找到異常堆棧，如代碼清單5-1所示。

  如果認真閱讀過本書的第2章，看到異常堆棧就應該清楚這個記憶體溢出異常是怎麼回事了。大家知道操作系統對每個進程能管理的記憶體是有限制的，這台伺服器使用 的32位Windows平臺的限制是2GB,其中給了 Java堆1.6GB,而Direct Memory並不算在1.6GB的堆之內，因此它只能在剩餘的0.4GB空間中分出一部分。在此應用中導致溢出的關鍵是：垃圾收集進行時，虛擬機雖然會對Direct Memory進行回收，但 是Direct Memory卻不能像新生代和老年代那樣，發現空間不足了就通知收集器進行 垃圾回收，它只能等待老年代滿了後Full GC,然後“順便地”幫它清理掉記憶體的廢棄 對象。否則，它只能等到拋出記憶體溢出異常時，先catch掉，再在catch塊裡面“大喊” 一聲：“System.gc。！ ”。要是虛擬機還是不聽(譬如打開了-XX:+DisableExplicitGC 開關)，那就只能眼睜睜地看著堆中還有許多空閑記憶體，自己卻不得不拋出記憶體溢出異 常了。而本案例中使用的CometD 1.1.1框架，正好有大量的NIO操作需要用到Direct Memory。

  從實踐的角度來講，除了Java堆和永久代之外，我們註意到下麵這些區域還會占用較多的記憶體，這裡所有的記憶體總和會受到操作系統進程最大記憶體的限制。

• Direct Memory :可通過-XX:MaxDirectMemorySize調整大小，記憶體不足時拋出 OutOfMemoryError 或 OutOfMemoryError: Direct buffer memory „
• 線程堆棧：可通過-Xss調整大小，記憶體不足時拋出StackOverflowError (縱向無 法分配，即無法分配新的棧幀)或 OutOfMemoryError: unable to create new native thread (橫向無法分配，即無法建立新的線程)。
• Socket緩存區：每個Socket連接都Receive和Send兩個緩存區，分別占大約 37KB和25KB的記憶體，連接多的話這塊記憶體占用也比較可觀。如果無法分配， 則可能會拋出 lOException: Too many open files 異常。
• JNI代碼：如果代碼中使用JNI調用本地庫，那本地庫使用的記憶體也不在堆中。
• 虛擬機和GC：虛擬機和GC的代碼執行也要消耗一定的記憶體。

  2.4 外部命令導致系統緩慢

  這是一個來自網路的案例：一個數字校園應用系統，運行在一臺4個CPU的 Solaris 10操作系統上，中間件為GlassFish伺服器。系統在進行大併發壓力測試的時 候，發現請求響應時間比較慢，通過操作系統的mpstat 工具發現CPU使用率很高，並 且占用絕大多數CPU資源的程式並不是應用系統本身。這是個不正常的現象，通常情況 下用戶應用的CPU占用率應該占主要地位，才能說明系統是正常工作的。

  通過Solaris 10的Dtrace腳本可以査看當前情況下哪些系統調用花費了最多的CPU 資源，Dtrace運行後發現最消耗CPU資源的竟然是“fork”系統調用。眾所周知，“fork” 系統調用是Linux用來產生新進程的，在Java虛擬機中，用戶編寫的Java代碼最多只 有線程的概念，不應當有進程的產生。

  這是個非常異常的現象。通過本系統的開發人員最終找到了答案：每個用戶請求的 處理都需要執行一個外部shell腳本來獲得系統的一些信息。執行這個shell腳本是通過 Java的Runtime.getRuntime().exec()方法來調用的。這種調用方式可以達到目的，但是 它在Java虛擬機中非常消耗資源，即使外部命令本身能很快執行完畢，頻繁調用時創 建進程的開銷也非常可觀。Java虛擬機執行這個命令的過程是：首先克隆一個和當前虛 擬機擁有一樣環境變數的進程，再用這個新的進程去執行外部命令，最後再退出這個進程。如果頻繁執行這個操作，系統的消耗會很大，不僅是CPU,記憶體的負擔也很重。用戶根據建議去掉這個shell腳本執行的語句，改為使用Java的API去獲取這些信息後，系統很快就恢復了正常。

  2.5 伺服器JVM進程崩潰

  一個基於B/S的MIS系統，硬體為兩台2個CPU、8GB記憶體的HP系統，伺服器是 WebLogic 9.2 (就是第二個案例中的那套系統)。正常運行一段時間後，最近發現在運行 期間頻繁出現集群節點的虛擬機進程自動關閉的現象，留下了一個hs_err_pid###.log文 件後，進程就消失了，兩台物理機器里的每個節點都出現過進程崩潰的現象。從系統日 志中註意到，每個節點的虛擬機進程在崩潰前不久，都發生過大量相同的異常，見代碼 清單5-2。

  這是一個遠端斷開連接的異常，通過系統管理員瞭解到系統最近與一個OA門戶做了集成，在MIS系統工作流的待辦事項變化時，要通過Web服務通知OA門戶系 統，把待辦事項的變化同步到OA門戶之中。通過SoapUI測試了一下同步待辦事項的 幾個Web服務，發現調用後竟然需要長達3分鐘才能返回，並且返回的結果都是連接 中斷。

  由於MIS系統的用戶多，待辦事項變化很快，為了不被OA系統的速度拖累，使用了非同步的方式調用Web服務，但由於兩邊服務的速度完全不對等，時間越長就累積了越多Web服務沒有調用完成，導致在等待的線程和Socket連接越來越多，最終超過虛擬 機的承受能力後使得虛擬機進程崩潰。通知OA門戶方修複無法使用的集成介面，並將非同步調用改為生產者/消費者模式的消息隊列實現後，系統恢復正常。