在Java軟件中如何更好防止內存泄漏(組圖)

2019-11-18 11:59:42

字體：大中小

來源：轉載

供稿：網友

　　摘要
　　
　　盡管java虛擬機和垃圾回收機制治理著大部分的內存事務，但是在java軟件中還是可能存在內存泄漏的情況。的確，在大型工程中，內存泄漏是一個普遍問題。避免內存泄漏的第一步，就是要了解他們發生的原因。這篇文章就是要介紹一些常見的缺陷，然后提供一些非常好的實踐例子來指導你寫出沒有內存泄漏的代碼。一旦你的程序存在內存泄漏，要查明代碼中引起泄漏的原因是很困難的。同時這篇文章也要介紹一個新的工具來查找內存泄漏，然后指明發生的根本原因。這個工具輕易上手，可以讓你找到產品級系統中的內存泄漏。
　　
　　垃圾回收（GC）的角色
　　
　　雖然垃圾回收關心著大部分的問題，包括內存治理，使得程序員的任務顯得更加輕松，但是程序員還是可能犯些錯誤導致內存泄漏問題。GC(垃圾回收)通過遞歸對所有從“根”對象(堆棧中的對象，靜態數據成員，JNI句柄等等)繼續下來的引用進行工作，然后標記所有可以訪問的活動著的對象。而這些對象變成了程序唯一能夠操縱的對象，其他的對象都被釋放了。因為GC使得程序不能夠訪問那些被釋放的對象，所以這樣做是安全的。
　　
　　內存治理可以說是自動的，但是這并沒有讓程序員脫離內存治理問題。比方說，對于內存的分配（還有釋放）總是存在一定的開銷，盡管這些開銷對程序員來說是隱含的。一個程序假如創建了很多對象，那么它就要比完成相同任務而創建了較少對象的程序執行的速度慢（假如其他的條件都相同）。
　　
　　文章更多想說的，導致內存泄漏主要的原因是，先前申請了內存空間而忘記了釋放。假如程序中存在對無用對象的引用，那么這些對象就會駐留內存，消耗內存，因為無法讓垃圾回收器驗證這些對象是否不再需要。正如我們前面看到的，假如存在對象的引用，這個對象就被定義為“活動的”，同時不會被釋放。要確定對象所占內存將被回收，程序員就要務必確認該對象不再會被使用。典型的做法就是把對象數據成員設為null或者從集合中移除該對象。注重，當局部變量不需要時，不需明顯的設為null，因為一個方法執行完畢時，這些引用會自動被清理。
　　
　　從更高一個層次看，這就是所有存在內存管的語言對內存泄漏所考慮的事情，剩余的對象引用將不再會被使用。
　　
　　典型的泄漏
　　
　　既然我們知道了在java中確實會存在內存泄漏，那么就讓我們看一些典型的泄漏，并找出他們發生的原因。
　　
　　全局集合
　　
　　在大型應用程序中存在各種各樣的全局數據倉庫是很普遍的，比如一個JNDI-tree或者一個session table。在這些情況下，注重力就被放在了治理數據倉庫的大小上。當然是有一些適當的機制可以將倉庫中的無用數據移除。
　　
　　可以有很多不同的解決形式，其中最常用的是一種周期運行的清除作業。這個作業會驗證倉庫中的數據然后清除一切不需要的數據。
　　
　　另一個辦法是計算引用的數量。集合負責跟蹤集合中每個元素的引用者數量。這要求引用者通知集合什么時候已經對元素處理完畢。當引用者的數目為零時，就可以移除集合中的相關元素。
　　
　　高速緩存
　　
　　高速緩存是一種用來快速查找已經執行過的操作結果的數據結構。因此，假如一個操作執行很慢的話，你可以先把普通輸入的數據放入高速緩存，然后過些時間再調用高速緩存中的數據。
　　
　　高速緩存多少還有一點動態實現的意思，當數據操作完畢，又被送入高速緩存。一個典型的算法如下所示：
　　
　　１．檢查結果是否在高速緩存中，存在則返回結果；
　　
　　２．假如結果不在，那么計算結果；
　　
　　３．將結果放入高速緩存，以備將來的操作調用。
　　
　　這個算法的問題（或者說潛在的內存泄漏）在最后一步。假如操作是分別多次輸入，那么存入高速緩存的內容將會非常大。很明顯這個方法不可取。
　　
　　為了避免這種潛在的致命錯誤設計，程序就必須確定高速緩存在他所使用的內存中有一個上界。因此，更好的算法是：
　　
　　１．檢查結果是否在高速緩存中，存在則返回結果；
　　
　　２．假如結果不在，那么計算結果；
　　
　　３．假如高速緩存所占空間過大，移除緩存中舊的結果；
　　
　　４．將結果放入高速緩存，以備將來的操作調用。
　　
　　通過不斷的從緩存中移除舊的結果，我們可以假設，將來，最新輸入的數據可能被重用的幾率要遠遠大于舊的結果。這通常是一個不錯的設想。
　　
　　這個新的算法會確保高速緩存的容量在預先確定的范圍內。精確的范圍是很難計算的，因為緩存中的對象存在引用時將繼續有效。正確的劃分高速緩存的大小是一個復雜的任務，你必須權衡可使用內存大小和數據快速存取之間的矛盾。
　　
　　另一個解決這個問題的途徑是使用java.lang.ref.SoftReference類來將對象放入高速緩存。這個方法可以保證當虛擬機用完內存或者需要更多堆的時候，可以釋放這些對象的引用。
　　
　　類裝載器
　　
　　Java類裝載器創建就存在很多導致內存泄漏的漏洞。由于類裝載器的復雜結構，使得很難得到內存泄漏的透視圖。這些困難不僅僅是由于類裝載器只與“普通的”對象引用有關，同時也和對象內部的引用有關，比如數據變量，方法和各種類。這意味著只要存在對數據變量，方法，各種類和對象的類裝載器，那么類裝載器將駐留在JVM中。既然類裝載器可以同很多的類關聯，同時也可以和靜態數據變量關聯，那么相當多的內存就可能發生泄漏。
　　
　　定位內存泄漏
　　
　　經常地，程序內存泄漏的最初跡象發生在出錯之后，在你的程序中得到一個OutOfMemoryError。這種典型的情況發生在產品環境中，而在那里，你希望內存泄漏盡可能的少，調試的可能性也達到最小。也許你的測試環境和產品的系統環境不盡相同，導致泄露的只會在產品中暴露。這種情況下，你需要一個低負荷的工具來監聽和尋找內存泄漏。同時，你還需要把這個工具同你的系統聯系起來，而不需要重新啟動他或者機械化你的代碼。也許更重要的是，當你做分析的時候，你需要能夠同工具分離而使得系統不會受到干擾。
　　
　　一個OutOfMemoryError經常是內存泄漏的一個標志，有可能應用程序的確用了太多的內存；這個時候，你既不能增加JVM的堆的數量，也不能改變你的程序而使得他減少內存使用。但是，在大多數情況下，一個OutOfMemoryError是內存泄漏的標志。一個解決辦法就是繼續監聽GC的活動，看看隨時間的流逝，內存使用量是否會增加，假如有，程序中一定存在內存泄漏。
　　
　　具體輸出
　　
　　有很多辦法來監聽垃圾回收器的活動。也許運用最廣泛的就是以：-Xverbose:gc選項運行JVM，然后觀察輸出結果一段時間。
　　
　　[memory] 10.109-10.235: GC 65536K->16788K (65536K), 126.000 ms
　　
　　箭頭后的值（在這個例子中 16788K）是垃圾回收后堆的使用量。
　　
　　控制臺
　　
　　觀察這些無盡的GC具體統計輸出是一件非常單調乏味的事情。好在有一些工具來代替我們做這些事情。The JRockit Management Console可以用圖形的方式輸出堆的使用量。通過觀察圖像，我們可以很方便的觀察堆的使用量是否伴隨時間增長。
　　　在Java軟件中如何更好防止內存泄漏(組圖)

　　Figure 1. The JRockit Management Console
　　
　　治理控制臺甚至可以配置成在堆使用量出現問題（或者其他的事件發生）時向你發送郵件。這個顯然使得監控內存泄漏更加輕易。
　　
　　內存泄漏探測工具
　　
　　有很多專門的內存泄漏探測工具。其中The JRockit Memory Leak Detector可以供來觀察內存泄漏也可以針對性地找到泄漏的原因。這個強大的工具被緊密地集成在JRockit JVM中，可以提供最低可能的內存事務也可以輕松的訪問虛擬機的堆。
　　
　　專門工具的優勢
　　
　　一旦你知道程序中存在內存泄漏，你需要更專業的工具來查明為什么這里會有泄漏。而JVM是不可能告訴你的。現在有很多工具可以利用了。這些工具本質上主要通過兩種方法來得到JVM的存儲系統信息的：JVMTI和字節碼儀器。Java虛擬機工具接口（JVMTI）和他的原有形式JVMPI（壓型接口，PRofiling Interface）都是標準接口，作為外部工具同JVM進行通信，搜集JVM的信息。字節碼儀器則是引用通過探針獲得工具所需的字節信息的預處理技術。
　　
　　通過這些技術來偵測內存泄漏存在兩個缺點，而這使得他們在產品級環境中的運用不夠理想。首先，根據兩者對內存的使用量和內存事務性能的降級是不可以忽略的。從JVM獲得的堆的使用量信息需要在工具中導出，收集和處理。這意味著要分配內存。按照JVM的性能導出信息是需要開銷的，垃圾回收器在搜集信息的時候是運行的非常緩慢的。另一個缺點就是，這些工具所需要的信息是關系到JVM的。讓工具在JVM開始運行的時候和它關聯，而在分析的時候，分離工具而保持JVM運行，這顯然是不可能的。
　　
　　既然JRockit Memory Leak Detector是被集成到JVM中的，那么以上兩種缺點就不再存在。首先，大部分的處理和分析都是在JVM中完成的，所以就不再需要傳送或重建任何數據。處理也可以建立在垃圾回收器的基礎上，即提高速度。再有，內存泄漏偵測器可以同一個運行的JVM關聯和分離，只要JVM在開始的時候伴隨著 –Xmanagement選項（通過遠程JMX接口答應監聽和治理JVM）。當工具分離以后，工具不會遺留任何東西在JVM中；JVM就可以全速運行代碼就似乎工具關聯之前一樣。
　　
　　趨勢分析
　　
　　讓我們更深一步來觀察這個工具，了解他如何捕捉到內存泄漏。在你了解到代碼中存在內存泄漏，第一步就是嘗試計算出什么數據在泄

上一篇：學會Tiles在JSF框架中的應用指南

下一篇：讓自己學會寫的一個在線升級的程序