java memory 泄露 溢出

要點

• 內存泄露是指程序中間動態分配了內存，但在程序結束時沒有釋放這部份內存，從而形成那部份內存不可用的狀況，重啓計算機能夠解決，但也有可能再次發生內存泄露，內存泄露和硬件沒有關係，它是由軟件設計缺陷引發的。 
• 內存泄漏能夠分爲4類：

1) 常發性內存泄漏。發生內存泄漏的代碼會被屢次執行到，每次被執行的時候都會致使一塊內存泄漏。

2) 偶發性內存泄漏。發生內存泄漏的代碼只有在某些特定環境或操做過程下才會發生。常發性和偶發性是相對的。對於特定的環境，偶發性的也許就變成了常發性的。因此測試環境和測試方法對檢測內存泄漏相當重要。

3) 一次性內存泄漏。發生內存泄漏的代碼只會被執行一次，或者因爲算法上的缺陷，致使總會有一塊僅且一塊內存發生泄漏。好比，在類的構造函數中分配內存，在析構函數中卻沒有釋放該內存，因此內存泄漏只會發生一次。

4) 隱式內存泄漏。程序在運行過程當中不停的分配內存，可是直到結束的時候才釋放內存。嚴格的說這裏並無發生內存泄漏，由於最終程序釋放了全部申請的內存。可是對於一個服務器程序，須要運行幾天，幾周甚至幾個月，不及時釋放內存也可能致使最終耗盡系統的全部內存。因此，咱們稱這類內存泄漏爲隱式內存泄漏。

• 內存溢出類型：

1) java.lang.OutOfMemoryError: PermGen space

PermGen space 的全稱是 Permanent Generation space, 是指內存的永久保存區域。這塊內存主要是被JVM存放Class和Meta信息的，Class在被Loader時就會被放到PermGenspace中，它和存放類實例(Instance)的Heap區域不一樣，GC不會在主程序運行期對PermGen space進行清理。

 

JVM由XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；

JVM由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。

 

該錯誤常見場合：

a) 應用中有不少Class，web服務器對JSP進行precompile時。

b) Webapp下用了大量的第三方jar,其大小超過了JVM默認的大小(4M)時。

 

2) java.lang.OutOfMemoryError:Java heap space

 

在JVM中若是98%的時間是用於GC且可用的Heap size 不足2%的時候將拋出此異常信息。

 

JVM初始分配的內存由-Xms指定，默認是物理內存的1/64； 

JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4。 

 

JVM內存的最大值跟操做系統有很大的關係。32位處理器雖然可控內存空間有4GB，可是具體的操做系統會給一個限制，這個限制通常是2GB-3GB（通常來講Windows系統下爲1.5G-2G，Linux系統下爲2G-3G），而64bit以上的處理器就不會有限制了。

注意：若是Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操做系統的最大限制都會引發服務器啓動不起來。 

該錯誤常見場合：

a) Web上傳文件時。

b) 開啓大型文件或從數據庫中一次取了太多的數據。 
 

 

相關問題

1. Q: Java中會存在內存泄漏嗎？
    A:  Java中也存在內存泄露。當被分配的對象可達但已無用（未對做廢數據內存單元的引用置null）即會引發。

         如：

Java代碼

1. Vector v=new Vector(10);    
2. for (int i=1;i<100; i ) {    
3.     Object o=new Object();    
4.     v.add(o);    
5.     o=null;    
6. }    
7. // 此時，全部的Object對象都沒有被釋放，由於變量v引用這些對象。    
8. // 對象加入到Vector後，還必須從Vector中刪除，最簡單釋放方法就是將Vector對象設置爲null。   

 

 

2. Q: 內存泄露、溢出的異同？ 

     A: 同：都會致使應用程序運行出現問題，性能降低或掛起。

         異：

         1) 內存泄露是致使內存溢出的緣由之一；內存泄露積累起來將致使內存溢出。

         2) 內存泄露能夠經過完善代碼來避免；內存溢出能夠經過調整配置來減小發生頻率，但沒法完全避免。

        

 

3. 如何檢測內存泄露？   

 

     A: 能夠經過一些性能監測分析工具，如 JProfiler、Optimizeit Profiler。

 

4. Q: 如何避免內存泄露、溢出？
     A: 1) 儘早釋放無用對象的引用。

          好的辦法是使用臨時變量的時候，讓引用變量在退出活動域後自動設置爲null，暗示垃圾收集器來收集該對象，防止發生內存泄露。

          2) 程序進行字符串處理時，儘可能避免使用String，而應使用StringBuffer。

          由於每個String對象都會獨立佔用內存一塊區域，如：

 

Java代碼

1. String str = "aaa";    
2. String str2 = "bbb";    
3. String str3 = str + str2;    
4. // 假如執行這次以後str , str2再不被調用，那麼它們就會在內存中等待GC回收；    
5. // 假如程序中存在過多的相似狀況就會出現內存錯誤；   

 

         3) 儘可能少用靜態變量。

         由於靜態變量是全局的，GC不會回收。

         4) 避免集中建立對象尤爲是大對象，若是能夠的話儘可能使用流操做。

         JVM會忽然須要大量內存，這時會觸發GC優化系統內存環境； 一個案例以下： 

 

Java代碼

1. // 使用jspsmartUpload做文件上傳，運行過程當中常常出現java.outofMemoryError的錯誤，    
2. // 檢查以後發現問題：組件裏的代碼    
3. m_totalBytes = m_request.getContentLength();    
4. m_binArray = new byte[m_totalBytes];    
5. // totalBytes這個變量獲得的數極大，致使該數組分配了不少內存空間，並且該數組不能及時釋放。    
6. // 解決辦法只能換一種更合適的辦法，至少是不會引起outofMemoryError的方式解決。    
7. // 參考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747   

   

 

        5) 儘可能運用對象池技術以提升系統性能。

         生命週期長的對象擁有生命週期短的對象時容易引起內存泄漏，例如大集合對象擁有大數據量的業務對象的時候，能夠考慮分塊進行處理，而後解決一塊釋放一塊的策略。

         6) 不要在常常調用的方法中建立對象，尤爲是忌諱在循環中建立對象。

         能夠適當的使用hashtable，vector 建立一組對象容器，而後從容器中去取那些對象，而不用每次new以後又丟棄。

         7) 優化配置。

 

 

 

 

5. Q: 內存溢出的解決方案？ 
     A: 一是從代碼層面進行優化完善，儘可能避免該狀況發生；

         二是調整優化服務器配置： 

         1) 設置-Xms、-Xmx相等；

         2) 設置NewSize、MaxNewSize相等；

         3) 設置Heap size, PermGen space:

            Tomcat 的配置示例：修改%TOMCAT_HOME%/bin/catalina.bat or catalina.sh

             在「echo "Using CATALINA_BASE: $CATALINA_BASE"」上面加入如下行：

            

Cmd代碼

1. set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m  

 

怎樣解決內存溢出

 

　1、內存溢出類型

　　一、java.lang.OutOfMemoryError:PermGen space

　　JVM管理兩種類型的內存，堆和非堆。堆是給開發人員用的上面說的就是，是在JVM啓動時建立;非堆是留給JVM本身用的，用來存放類的信息的。它和堆不一樣，運行期內GC不會釋放空間。若是web app用了大量的第三方jar或者應用有太多的class文件而剛好MaxPermSize設置較小，超出了也會致使這塊內存的佔用過多形成溢出，或者tomcat熱部署時侯不會清理前面加載的環境，只會將context更改成新部署的，非堆存的內容就會愈來愈多。

　　PermGen space的全稱是PermanentGeneration space,是指內存的永久保存區域，這塊內存主要是被JVM存放Class和Meta信息的,Class在被Loader時就會被放到PermGen space中，它和存放類實例(Instance)的Heap區域不一樣,GC(GarbageCollection)不會在主程序運行期對PermGen space進行清理，因此若是你的應用中有很CLASS的話,就極可能出現PermGenspace錯誤，這種錯誤常見在web服務器對JSP進行pre compile的時候。若是你的WEB APP下都用了大量的第三方jar, 其大小超過了jvm默認的大小(4M)那麼就會產生此錯誤信息了。

　　一個最佳的配置例子：(通過本人驗證，自從用此配置以後，再未出現過tomcat死掉的狀況)

　　set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M-XX:MaxNewSize=256m -XX:MaxPermSize=256m

　　二、java.lang.OutOfMemoryError:Javaheap space

　　第一種狀況是個補充，主要存在問題就是出如今這個狀況中。其默認空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。若是內存剩餘不到40%，JVM就會增大堆到Xmx設置的值，內存剩餘超過70%，JVM就會減少堆到Xms設置的值。因此服務器的Xmx和Xms設置通常應該設置相同避免每次GC後都要調整虛擬機堆的大小。假設物理內存無限大，那麼JVM內存的最大值跟操做系統有關，通常32位機是1.5g到3g之間，而64位的就不會有限制了。

　　注意：若是Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操做系統的最大限制都會引發服務器啓動不起來。

　　垃圾回收GC的角色

　　JVM調用GC的頻度仍是很高的，主要兩種狀況下進行垃圾回收：

　　當應用程序線程空閒;另外一個是java內存堆不足時，會不斷調用GC，若連續回收都解決不了內存堆不足的問題時，就會報out of memory錯誤。由於這個異常根據系統運行環境決定，因此沒法預期它什麼時候出現。

　　根據GC的機制，程序的運行會引發系統運行環境的變化，增長GC的觸發機會。

　　爲了不這些問題，程序的設計和編寫就應避免垃圾對象的內存佔用和GC的開銷。顯示調用System.GC()只能建議JVM須要在內存中對垃圾對象進行回收，但不是必須立刻回收，

　　一個是並不能解決內存資源耗空的局面，另外也會增長GC的消耗。

　　2、JVM內存區域組成

　　簡單的說java中的堆和棧

　　java把內存分兩種：一種是棧內存，另外一種是堆內存

　　1。在函數中定義的基本類型變量和對象的引用變量都在函數的棧內存中分配;

　　2。堆內存用來存放由new建立的對象和數組

　　在函數(代碼塊)中定義一個變量時，java就在棧中爲這個變量分配內存空間，當超過變量的做用域後，java會自動釋放掉爲該變量所分配的內存空間;在堆中分配的內存由java虛擬機的自動垃圾回收器來管理

　　堆的優點是能夠動態分配內存大小，生存期也沒必要事先告訴編譯器，由於它是在運行時動態分配內存的。缺點就是要在運行時動態分配內存，存取速度較慢;

　　棧的優點是存取速度比堆要快，缺點是存在棧中的數據大小與生存期必須是肯定的無靈活性。

　　java堆分爲三個區：New、Old和Permanent

　　GC有兩個線程：

　　新建立的對象被分配到New區，當該區被填滿時會被GC輔助線程移到Old區，當Old區也填滿了會觸發GC主線程遍歷堆內存裏的全部對象。Old區的大小等於Xmx減去-Xmn

　　java棧存放

　　棧調整：參數有+UseDefaultStackSize -Xss256K，表示每一個線程可申請256k的棧空間

　　每一個線程都有他本身的Stack

　　3、JVM如何設置虛擬內存

　　提示：在JVM中若是98%的時間是用於GC且可用的Heap size 不足2%的時候將拋出此異常信息。

　　提示：Heap Size 最大不要超過可用物理內存的80%，通常的要將-Xms和-Xmx選項設置爲相同，而-Xmn爲1/4的-Xmx值。

　　提示：JVM初始分配的內存由-Xms指定，默認是物理內存的1/64;JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4。

　　默認空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制;空餘堆內存大於70%時，JVM會減小堆直到-Xms的最小限制。所以服務器通常設置-Xms、-Xmx相等以免在每次GC 後調整堆的大小。

　　提示：假設物理內存無限大的話，JVM內存的最大值跟操做系統有很大的關係。

　　簡單的說就32位處理器雖然可控內存空間有4GB,可是具體的操做系統會給一個限制，

　　這個限制通常是2GB-3GB(通常來講Windows系統下爲1.5G-2G，Linux系統下爲2G-3G)，而64bit以上的處理器就不會有限制了

　　提示：注意：若是Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操做系統的最大限制都會引發服務器啓動不起來。

　　提示：設置NewSize、MaxNewSize相等，"new"的大小最好不要大於"old"的一半，緣由是old區若是不夠大會頻繁的觸發"主" GC ，大大下降了性能

　　JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64;

　　由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。

　　解決方法：手動設置Heap size

　　修改TOMCAT_HOME/bin/catalina.bat

　　在「echo "Using CATALINA_BASE: $CATALINA_BASE"」上面加入如下行：

　　JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"

　　4、性能檢查工具使用

　　定位內存泄漏：

　　JProfiler工具主要用於檢查和跟蹤系統(限於Java開發的)的性能。JProfiler能夠經過時時的監控系統的內存使用狀況，隨時監視垃圾回收，線程運行情況等手段，從而很好的監視JVM運行狀況及其性能。

　　1. 應用服務器內存長期不合理佔用，內存常常處於高位佔用，很難回收到低位;

　　2. 應用服務器極爲不穩定，幾乎每兩天從新啓動一次，有時甚至天天從新啓動一次;

　　3. 應用服務器常常作Full GC(GarbageCollection)，並且時間很長，大約須要30-40秒，應用服務器在作Full GC的時候是不響應客戶的交易請求的，很是影響系統性能。

　　由於開發環境和產品環境會有不一樣，致使該問題發生有時會在產品環境中發生，一般可使用工具跟蹤系統的內存使用狀況，在有些個別狀況下或許某個時刻確實是使用了大量內存致使out of memory，這時應繼續跟蹤看接下來是否會有降低，

　　若是一直居高不下這確定就由於程序的緣由致使內存泄漏。

　　5、不健壯代碼的特徵及解決辦法

　　一、儘早釋放無用對象的引用。好的辦法是使用臨時變量的時候，讓引用變量在退出活動域後，自動設置爲null，暗示垃圾收集器來收集該對象，防止發生內存泄露。

　　對於仍然有指針指向的實例，jvm就不會回收該資源,由於垃圾回收會將值爲null的對象做爲垃圾，提升GC回收機制效率;

　　二、咱們的程序裏不可避免大量使用字符串處理，避免使用String，應大量使用StringBuffer，每個String對象都得獨立佔用內存一塊區域;

　　String str = "aaa";

　　String str2 = "bbb";

　　String str3 = str + str2;//假如執行這次以後str ,str2之後再不被調用,那它就會被放在內存中等待Java的gc去回收,程序內過多的出現這樣的狀況就會報上面的那個錯誤,建議在使用字符串時能使用StringBuffer就不要用String,這樣能夠省很多開銷;

　　三、儘可能少用靜態變量，由於靜態變量是全局的，GC不會回收的;

　　四、避免集中建立對象尤爲是大對象，JVM會忽然須要大量內存，這時必然會觸發GC優化系統內存環境;顯示的聲明數組空間，並且申請數量還極大。

　　這是一個案例想定供你們警惕

　　使用jspsmartUpload做文件上傳,運行過程當中常常出現java.outofMemoryError的錯誤，

　　檢查以後發現問題：組件裏的代碼

　　m_totalBytes = m_request.getContentLength();

　　m_binArray = new byte[m_totalBytes];

　　問題緣由是totalBytes這個變量獲得的數極大，致使該數組分配了不少內存空間，並且該數組不能及時釋放。解決辦法只能換一種更合適的辦法，至少是不會引起outofMemoryError的方式解決。參考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747

　　五、儘可能運用對象池技術以提升系統性能;生命週期長的對象擁有生命週期短的對象時容易引起內存泄漏，例如大集合對象擁有大數據量的業務對象的時候，能夠考慮分塊進行處理，而後解決一塊釋放一塊的策略。

　　六、不要在常常調用的方法中建立對象，尤爲是忌諱在循環中建立對象。能夠適當的使用hashtable，vector 建立一組對象容器，而後從容器中去取那些對象，而不用每次new以後又丟棄

　　七、通常都是發生在開啓大型文件或跟數據庫一次拿了太多的數據，形成 Out OfMemory Error 的情況，這時就大概要計算一下數據量的最大值是多少，而且設定所需最小及最大的內存空間值。