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門戶方修復無法使用的集成介面，并將異步呼叫改為生產者/消費者模式的訊息佇列實作后，系統恢復正常，

??

??

標籤：其他

上一篇：函式的遞回

下一篇：完整實作-通過DelayQueue實作延時任務