JVM內存分析及致使內存溢出的不健壯代碼及解決辦法

轉自：http://hi.baidu.com/fvsd3/blog/item/9baec09a301bdebcc9eaf4a2.html

1、JVM內存區域組成 

java把內存分四種： 
一、棧區（stack segment）— 由編譯器自動分配釋放,存放函數的參數值，局部變量的值等，具體方法執行結束以後，系統自動釋放內存資源 
二、堆區（heap segment） — 通常由程序員分配釋放，存放由new建立的對象和數組，jvm不定時查看這個對象，若是沒有引用指向這個對象就回收 
三、靜態區（data segment）— 存放全局變量，靜態變量和字符串常量，不釋放 
四、代碼區（code segment）— 存放程序中方法的二進制代碼，並且是多個對象 共享一個代碼空間區域 

在方法（代碼塊）中定義一個變量時，java就在棧中爲這個變量分配內存空間，當超過變量的做用域後，java會自動釋放掉爲該變量所分配的內存空間；在堆中分配的內存由java虛擬機的自動垃圾回收器來管理，堆的優點是能夠動態分配內存大小，生存期也沒必要事先告訴編譯器，由於它是在運行時動態分配內存的。缺點就是要在運行時動態分配內存，存取速度較慢；棧的優點是存取速度比堆要快，缺點是存在棧中的數據大小與生存期必須是肯定的無靈活性。 

java堆由Perm區和Heap區組成，Heap區則由Old區和New區組成，而New區又分爲Eden區, From區, To區，Heap = {Old + NEW = { Eden, From, To } }，見圖1所示。

Heap區分兩大塊，一塊是 NEW Generation, 另外一塊是Old Generation. 在New Generation中，有一個叫Eden的空間，主要是用來存放新生的對象，還有兩個Survivor Spaces（from,to）, 它們用來存放每次垃圾回收後存活下來的對象。在Old Generation中，主要存放應用程序中生命週期長的內存對象，還有個Permanent Generation，主要用來放JVM本身的反射對象，好比類對象和方法對象等。 

在New Generation塊中，垃圾回收通常用Copying的算法，速度快。每次GC的時候，存活下來的對象首先由Eden拷貝到某個Survivor Space, 當Survivor Space空間滿了後, 剩下的live對象就被直接拷貝到Old Generation中去。所以，每次GC後，Eden內存塊會被清空。在Old Generation塊中，垃圾回收通常用mark-compact的算法，速度慢些，但減小內存要求. 

垃圾回收分多級，0級爲所有(Full)的垃圾回收，會回收OLD段中的垃圾；1級或以上爲部分垃圾回收，只會回收NEW中的垃圾，內存溢出一般發生於OLD段或Perm段垃圾回收後，仍然無內存空間容納新的Java對象的狀況。 

JVM調用GC的頻度仍是很高的，主要兩種狀況下進行垃圾回收：當應用程序線程空閒；另外一個是java內存堆不足時，會不斷調用GC，若連續回收都解決不了內存堆不足的問題時，就會報out of memory錯誤。由於這個異常根據系統運行環境決定，因此沒法預期它什麼時候出現。 

根據GC的機制，程序的運行會引發系統運行環境的變化，增長GC的觸發機會。爲了不這些問題，程序的設計和編寫就應避免垃圾對象的內存佔用和GC的開銷。顯示調用System.GC()只能建議JVM須要在內存中對垃圾對象進行回收，但不是必須立刻回收，一個是並不能解決內存資源耗空的局面，另外也會增長GC的消耗。 


當一個URL被訪問時，內存申請過程以下： 
A. JVM會試圖爲相關Java對象在Eden中初始化一塊內存區域 
B. 當Eden空間足夠時，內存申請結束。不然到下一步 
C. JVM試圖釋放在Eden中全部不活躍的對象（這屬於1或更高級的垃圾回收）, 釋放後若Eden空間仍然不足以放入新對象，則試圖將部分Eden中活躍對象放入Survivor區 
D. Survivor區被用來做爲Eden及OLD的中間交換區域，當OLD區空間足夠時，Survivor區的對象會被移到Old區，不然會被保留在Survivor區 
E. 當OLD區空間不夠時，JVM會在OLD區進行徹底的垃圾收集（0級） 
F. 徹底垃圾收集後，若Survivor及OLD區仍然沒法存放從Eden複製過來的部分對象，致使JVM沒法在Eden區爲新對象建立內存區域，則出現"out of memory錯誤" 

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


二、java.lang.OutOfMemoryError: Java heap space 
這種內存溢出是最多見的狀況之一，主要體如今Old區的溢出，產生的緣由多是：1) 設置的內存參數太小(ms/mx, NewSize/MaxNewSize)；2) 程序問題。Heap space其默認空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。若是內存剩餘不到40％，JVM就會增大堆到Xmx設置的值，內存剩餘超過70％，JVM就會減少堆到Xms設置的值。因此服務器的Xmx和Xms設置通常應該設置相同避免每次GC後都要調整虛擬機堆的大小。假設物理內存無限大，那麼JVM內存的最大值跟操做系統有關，通常32位機是1.5g到3g之間，而64位的就不會有限制了。 

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

三、java.lang.OutOfMemoryError: c heap space 
系統對C Heap沒有限制，故C Heap發生問題時，Java進程所佔內存會持續增加，直到佔用全部可用系統內存 

四、其餘 
JVM有2個GC線程。第一個線程負責回收Heap的Young區。第二個線程在Heap不足時，遍歷Heap，將Young 區升級爲Older區。Older區的大小等於-Xmx減去-Xmn，不能將-Xms的值設的過大，由於第二個線程被迫運行會下降JVM的性能。 
爲何一些程序頻繁發生GC？有以下緣由： 
a、程序內調用了System.gc()或Runtime.gc()。 
b、一些中間件軟件調用本身的GC方法，此時須要設置參數禁止這些GC。 
c、Java的Heap過小，通常默認的Heap值都很小。 
d、頻繁實例化���象，Release對象。此時儘可能保存並重用對象，例如使用StringBuffer()和String()。 
若是你發現每次GC後，Heap的剩餘空間會是總空間的50%，這表示你的Heap處於健康狀態。許多Server端的Java程序每次GC後最好能有65%的剩餘空間 

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 ，大大下降了性能 
提示：增長Heap Size 雖然會下降GC的頻率，但也增長了每次GC的時間。而且GC運行時，全部的用戶線程將暫停，也就是GC期間，Java應用程序不作任何工做。 
提示：Heap Size 並不決定進程的內存使用量。進程的內存使用量要大於-Xmx定義的值，由於Java爲其餘任務分配內存，例如每一個線程的Stack等。 
提示：每一個線程都有他本身的Stack，Stack Size 限制着線程的數量。若是Stack過大就好致使內存溢漏。-Xss參數決定Stack大小，例如-Xss1024K。若是Stack過小，也會致使Stack溢漏。 


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、不健壯代碼的特徵及解決辦法 
一、儘早釋放無用對象的引用。好的辦法是使用臨時變量的時候，讓引用變量在退出活動域後，自動設置爲null，暗示垃圾收集器來收集該對象，防止發生內存泄露。對於仍然有指針指向的實例，jvm就不會回收該資源,由於垃圾回收會將值爲null的對象做爲垃圾，提升GC回收機制效率； 
二、咱們的程序裏不可避免大量使用字符串處理，避免使用String，應大量使用StringBuffer，每個String對象都得獨立佔用內存一塊區域；例如 
三、儘可能少用靜態變量，由於靜態變量是全局的，GC不會回收的； 
四、避免集中建立對象尤爲是大對象，JVM會忽然須要大量內存，這時必然會觸發GC優化系統內存環境；顯示的聲明數組空間，並且申請數量還極大。 
五、儘可能運用對象池技術以提升系統性能；生命週期長的對象擁有生命週期短的對象時容易引起內存泄漏，例如大集合對象擁有大數據量的業務對象的時候，能夠考慮分塊進行處理，而後解決一塊釋放一塊的策略。 
六、不要在常常調用的方法中建立對象，尤爲是忌諱在循環中建立對象。能夠適當的使用hashtable，vector 建立一組對象容器，而後從容器中去取那些對象，而不用每次new以後又丟棄 
七、通常都是發生在開啓大型文件或跟數據庫一次拿了太多的數據，形成 Out Of Memory Error 的情況，這時就大概要計算一下數據量的最大值是多少，而且設定所需最小及最大的內存空間值。