內存管理調優案例

1.高性能硬件上的程序部署策略

     例如：一個15萬PV/天左右（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位虛擬機創建邏輯集羣來利用硬件資源，具體作法是在一臺物理機器上啓動多個應用服務器進程，每一個服務器進程分配不一樣端口，而後再前端搭建一個負載均衡器，以反向代理的方式來分配訪問請求。

2.集羣間同步致使的內存溢出

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

  在內存溢出異常不出現的時候，服務內存回收情況一直正常，每次內存回收後都能恢復到一個穩定的可用空間，開始懷疑是程序某些不經常使用的代碼路徑中存在內存泄漏，但管理員反映最近程序並未更新、升級過，也沒有進行什麼特別操做。只好讓服務帶着-XX：+HeapDumpOnOfMemeoryError參數運行了一段時間。在最近一次溢出以後，管理員發回了heapdump文件，發現裏面存在着大量的 org.jgrops.protocols.pbcast,NakAck對象。

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

  因爲信息有傳輸失敗須要重發的可能性，在確認全部註冊在GMS的節點都收到正確的信息前，發送的信息必須在內訓中保留。而此MIS的服務端中有一個負責安全校驗的全局Filter，每當接收到請求時，均會更新一次最後操做時間，而且將這個時間同步到全部的就誒點去，使得一個用戶在一段時間內不能在多臺機器上登陸。在服務使用過程當中，每每一個頁面會產生數次乃至數十次的請求，所以這個過濾器致使集羣各個節點之間網絡交互很是頻繁。當網絡狀況不能知足傳輸要求時，重發數據在內存中不斷堆積，很快就產生了內存溢出。

   總結就是：設計中，應當多讀操做，由於數據在本地內存中有一份副本，讀取的 動做不會耗費多少資源，但不該當有過於頻繁的寫操做，那樣會帶來很大的網絡同步的開銷。

3.堆外內存致使的溢出錯誤

  例如：一個學校的小型項目：基於B/S的電子考試系統，爲了實現客戶端能實時地從服務器端接收考試數據，系統使用了逆向AJAX技術