JVM內存模型以及垃圾收集策略解析

 

JVM內存模型以及垃圾收集策略解析

 JVM內存模型

1.1 Java

Java棧是與每一個線程關聯的,JVM在創建每一個線程的時候,會分配一定的棧空間給線程。它主要用來存儲線程執行過程中的局部變量,方法的返回值,以及方法調用上下文。棧空間隨着線程的終止而釋放。

StackOverflowError:如果在線程執行的過程中,棧空間不夠用,那麼JVM就會拋出此異常,這種情況一般是死遞歸造成的。

1.2 

Java中堆是由所有的線程共享的一塊內存區域,堆用來保存各種JAVA對象,比如數組,線程對象等。

1.2.1 Generation

JVM堆一般又可以分爲以下三部分:

 

Ø Perm

Perm代主要保存class,method,filed對象,這部門的空間一般不會溢出,除非一次性加載了很多的類,不過在涉及到熱部署的應用服務器的時候,有時候會遇到java.lang.OutOfMemoryError : PermGen space 的錯誤,造成這個錯誤的很大原因就有可能是每次都重新部署,但是重新部署後,類的class沒有被卸載掉,這樣就造成了大量的class對象保存在了perm中,這種情況下,一般重新啓動應用服務器可以解決問題。

Ø Tenured

Tenured區主要保存生命週期長的對象,一般是一些老的對象,當一些對象在Young複製轉移一定的次數以後,對象就會被轉移到Tenured區,一般如果系統中用了application級別的緩存,緩存中的對象往往會被轉移到這一區間。

Ø Young

Young區被劃分爲三部分,Eden區和兩個大小嚴格相同的Survivor區,其中Survivor區間中,某一時刻只有其中一個是被使用的,另外一個留做垃圾收集時複製對象用,在Young區間變滿的時候,minor GC就會將存活的對象移到空閒的Survivor區間中,根據JVM的策略,在經過幾次垃圾收集後,任然存活於Survivor的對象將被移動到Tenured區間。

1.2.2 Sizing the Generations

JVM提供了相應的參數來對內存大小進行配置。

 

正如上面描述,JVM中堆被分爲了3個大的區間,同時JVM也提供了一些選項對Young,Tenured的大小進行控制。

Ø Total Heap 

-Xms :指定了JVM初始啓動以後初始化內存

-Xmx:指定JVM堆得最大內存,在JVM啓動以後,會分配-Xmx參數指定大小的內存給JVM,但是不一定全部使用,JVM會根據-Xms參數來調節真正用於JVM的內存

-Xmx -Xms之差就是三個Virtual空間的大小

Ø Young Generation

-XX:NewRatio=8意味着tenured  young的比值81,這樣eden+2*survivor=1/9

堆內存

-XX:SurvivorRatio=32意味着eden和一個survivor的比值是321,這樣一個Survivor就佔Young區的1/34.

-Xmn 參數設置了年輕代的大小

Ø Perm Generation

-XX:PermSize=16M -XX:MaxPermSize=64M

Thread Stack

-XX:Xss=128K

 

1.3 堆棧分離的好處

 

呵呵,其它的先不說了,就來說說面向對象的設計吧,當然除了面向對象的設計帶來的維護性,複用性和擴展性方面的好處外,我們看看面向對象如何巧妙的利用了堆棧分離。如果從JAVA內存模型的角度去理解面向對象的設計,我們就會發現對象它完美的表示了堆和棧,對象的數據放在堆中,而我們編寫的那些方法一般都是運行在棧中,因此面向對象的設計是一種非常完美的設計方式,它完美的統一了數據存儲和運行。

 

 JAVA垃圾收集器

2.1 垃圾收集簡史

垃圾收集提供了內存管理的機制,使得應用程序不需要在關注內存如何釋放,內存用完後,垃圾收集會進行收集,這樣就減輕了因爲人爲的管理內存而造成的錯誤,比如在C++語言裏,出現內存泄露時很常見的。

Java語言是目前使用最多的依賴於垃圾收集器的語言,但是垃圾收集器策略從20世紀60年代就已經流行起來了,比如Smalltalk,Eiffel等編程語言也集成了垃圾收集器的機制。

2.2 常見的垃圾收集策略

所有的垃圾收集算法都面臨同一個問題,那就是找出應用程序不可到達的內存塊,將其釋放,這裏面得不可到達主要是指應用程序已經沒有內存塊的引用了,而在JAVA中,某個對象對應用程序是可到達的是指:這個對象被根(根主要是指類的靜態變量,或者活躍在所有線程棧的對象的引用)引用或者對象被另一個可到達的對象引用。

2.2.1 Reference Counting(引用計數)

 引用計數是最簡單直接的一種方式,這種方式在每一個對象中增加一個引用的計數,這個計數代表當前程序有多少個引用引用了此對象,如果此對象的引用計數變爲0,那麼此對象就可以作爲垃圾收集器的目標對象來收集。

優點:

簡單,直接,不需要暫停整個應用

缺點:

1.需要編譯器的配合,編譯器要生成特殊的指令來進行引用計數的操作,比如每次將對象賦值給新的引用,或者者對象的引用超出了作用域等。

2.不能處理循環引用的問題

2.2.2 跟蹤收集器

跟蹤收集器首先要暫停整個應用程序,然後開始從根對象掃描整個堆,判斷掃描的對象是否有對象引用,這裏面有三個問題需要搞清楚:

1如果每次掃描整個堆,那麼勢必讓GC的時間變長,從而影響了應用本身的執行。因此在JVM裏面採用了分代收集,在新生代收集的時候minor gc只需要掃描新生代,而不需要掃描老生代。

2JVM採用了分代收集以後,minor gc只掃描新生代,但是minor gc怎麼判斷是否有老生代的對象引用了新生代的對象,JVM採用了卡片標記的策略,卡片標記將老生代分成了一塊一塊的,劃分以後的每一個塊就叫做一個卡片,JVM採用卡表維護了每一個塊的狀態,當JAVA程序運行的時候,如果發現老生代對象引用或者釋放了新生代對象的引用,那麼就JVM就將卡表的狀態設置爲髒狀態,這樣每次minor gc的時候就會只掃描被標記爲髒狀態的卡片,而不需要掃描整個堆。具體如下圖:

3GC在收集一個對象的時候會判斷是否有引用指向對象,在JAVA中的引用主要有四種:Strong reference,Soft reference,Weak reference,Phantom reference.

Ø Strong Reference 

強引用是JAVA中默認採用的一種方式,我們平時創建的引用都屬於強引用。如果一個對象沒有強引用,那麼對象就會被回收。

public void testStrongReference(){

Object referent = new Object();

Object strongReference = referent;

referent = null;

System.gc();

assertNotNull(strongReference);

}

 

    

Ø Soft Reference

軟引用的對象在GC的時候不會被回收,只有當內存不夠用的時候纔會真正的回收,因此軟引用適合緩存的場合,這樣使得緩存中的對象可以儘量的再內存中待長久一點。

Public void testSoftReference(){

String  str =  "test";

SoftReference softreference = new SoftReference(str);

 

str=null;

System.gc();

assertNotNull(softreference.get());

}

 

Ø Weak reference

弱引用有利於對象更快的被回收,假如一個對象沒有強引用只有弱引用,那麼在GC後,這個對象肯定會被回收。

Public void testWeakReference(){

String  str =  "test";

WeakReference weakReference = new WeakReference(str);

str=null;

System.gc();

assertNull(weakReference.get());

}

 

Ø Phantom reference 

2.2.2.1 Mark-Sweep Collector(標記-清除收集器)

標記清除收集器最早由Lisp的發明人於1960年提出,標記清除收集器停止所有的工作,從根掃描每個活躍的對象,然後標記掃描過的對象,標記完成以後,清除那些沒有被標記的對象。

優點:

解決循環引用的問題

不需要編譯器的配合,從而就不執行額外的指令

缺點:

1每個活躍的對象都要進行掃描,收集暫停的時間比較長。

2.2.2.2 Copying Collector(複製收集器)

複製收集器將內存分爲兩塊一樣大小空間,某一個時刻,只有一個空間處於活躍的狀態,當活躍的空間滿的時候,GC就會將活躍的對象複製到未使用的空間中去,原來不活躍的空間就變爲了活躍的空間。

複製收集器具體過程可以參考下圖:

優點:

只掃描可以到達的對象,不需要掃描所有的對象,從而減少了應用暫停的時間

缺點:

1需要額外的空間消耗,某一個時刻,總是有一塊內存處於未使用狀態

2複製對象需要一定的開銷

2.2.2.3 Mark-Compact Collector(標記-整理收集器)

標記整理收集器汲取了標記清除和複製收集器的優點,它分兩個階段執行,在第一個階段,首先掃描所有活躍的對象,並標記所有活躍的對象,第二個階段首先清除未標記的對象,然後將活躍的的對象複製到堆得底部。標記整理收集器的過程示意圖請參考下圖:

Mark-compact策略極大的減少了內存碎片,並且不需要像Copy Collector一樣需要兩倍的空間。

2.3 JVM的垃圾收集策略

   GC的執行時要耗費一定的CPU資源和時間的,因此在JDK1.2以後,JVM引入了分代收集的策略,其中對新生代採用"Mark-Compact"策略,而對老生代採用了“Mark-Sweep"的策略。其中新生代的垃圾收集器命名爲“minor gc”,老生代的GC命名爲"Full Gc 或者Major GC".其中用System.gc()強制執行的是Full Gc.

2.3.1 Serial Collector

Serial Collector是指任何時刻都只有一個線程進行垃圾收集,這種策略有一個名字“stop the whole world",它需要停止整個應用的執行。這種類型的收集器適合於單CPU的機器。

Serial Copying Collector

此種GC-XX:UseSerialGC選項配置,它只用於新生代對象的收集。1.5.0以後.

-XX:MaxTenuringThreshold來設置對象複製的次數。當eden空間不夠的時候,GC會將eden的活躍對象和一個名叫From survivor空間中尚不夠資格放入Old代的對象複製到另外一個名字叫To Survivor的空間。而此參數就是用來說明到底From survivor中的哪些對象不夠資格,假如這個參數設置爲31,那麼也就是說只有對象複製31次以後纔算是有資格的對象。

這裏需要注意幾個個問題:

Ø  From SurvivorTo survivor的角色是不斷的變化的,同一時間只有一塊空間處於使用狀態,這個空間就叫做From Survivor區,當複製一次後角色就發生了變化。

Ø  如果複製的過程中發現To survivor空間已經滿了,那麼就直接複製到old generation.

Ø  比較大的對象也會直接複製到Old generation,在開發中,我們應該儘量避免這種情況的發生。

Serial  Mark-Compact Collector

串行的標記-整理收集器是JDK5 update6之前默認的老生代的垃圾收集器,此收集使得內存碎片最少化,但是它需要暫停的時間比較長

2.3.2 Parallel Collector 

Parallel Collector主要是爲了應對多CPU,大數據量的環境。

Parallel Collector又可以分爲以下兩種:

Parallel Copying Collector

此種GC-XX:UseParNewGC參數配置,它主要用於新生代的收集,GC可以配合CMS一起使用。1.4.1以後

Parallel Mark-Compact Collector

此種GC-XX:UseParallelOldGC參數配置,此GC主要用於老生代對象的收集。1.6.0

Parallel scavenging Collector

此種GC-XX:UseParallelGC參數配置,它是對新生代對象的垃圾收集器,但是它不能和CMS配合使用,它適合於比較大新生代的情況,此收集器起始於jdk 1.4.0。它比較適合於對吞吐量高於暫停時間的場合。

Serial gcParallel gc可以用如下的圖來表示:

 

 

 

 

 

 

2.3.3 Concurrent Collector

Concurrent Collector通過並行的方式進行垃圾收集,這樣就減少了垃圾收集器收集一次的時間,這種GC在實時性要求高於吞吐量的時候比較有用。

此種GC可以用參數-XX:UseConcMarkSweepGC配置,此GC主要用於老生代Perm代的收集。

 垃圾收集策略配置

3.1 吞吐量優先

吞吐量是指GC的時間與運行總時間的比值,比如系統運行了100分鐘,而GC佔用了一分鐘,那麼吞吐量就是99%,吞吐量優先一般運用於對響應性要求不高的場合,比如web應用,因爲網絡傳輸本來就有延遲的問題,GC造成的短暫的暫停使得用戶以爲是網絡阻塞所致。

吞吐量優先可以通過-XX:GCTimeRatio來指定。

當通過-XX:GCTimeRatio不能滿足系統的要求以後,我們可以更加細緻的來對JVM進行調優。

首先因爲要求高吞吐量,這樣就需要一個較大的Young generation,此時就需要引入“Parallel scavenging Collector”,可以通過參數:-XX:UseParallelGC來配置。

 java -server -Xms3072m -Xmx3072m -XX:NewSize=2560m -XX:MaxNewSize=2560 XX:SurvivorRatio=2 -XX:+UseParallelGC 

當年輕代使用了"Parallel scavenge collector"後,老生代就不能使用"CMS"GC了,在JDK1.6之前,此時老生代只能採用串行收集,而JDK1.6引入了並行版本的老生代收集器,可以用參數-XX:UseParallelOldGC來配置

3.1.1 控制並行的線程數

缺省情況下,Parallel scavenging Collector 會開啓與cpu數量相同的線程進行並行的收集,但是也可以調節並行的線程數。假如你想用4個並行的線程去收集Young generation的話,那麼就可以配置-XX:ParallelGCThreads=4,此時JVM的配置參數如下:

 java -server -Xms3072m -Xmx3072m -XX:NewSize=2560m -XX:MaxNewSize=2560 XX:SurvivorRatio=2 -XX:+UseParallelGC -XX:ParallelGCThreads=4

3.1.2 自動調節新生代

在採用了"Parallel scavenge collector"後,此GC會根據運行時的情況自動調節survivor ratio來使得性能最優,因此"Parallel scavenge collector"應該總是開啓此參數。

此時JVM的參數配置如下:

java -server -Xms3072m -Xmx3072m -XX:+UseParallelGC    -XX:ParallelGCThreads=4 -XX:+UseAdaptiveSizePolicy

 

3.2 響應時間優先

響應時間優先是指GC每次運行的時間不能太久,這種情況一般使用與對及時性要求很高的系統,比如股票系統等。

響應時間優先可以通過參數-XX:MaxGCPauseMillis來配置,配置以後JVM將會自動調節年輕代,老生代的內存分配來滿足參數設置。

在一般情況下,JVM的默認配置就可以滿足要求,只有默認配置不能滿足系統的要求時候,纔會根據具體的情況來對JVM進行性能調優。如果採用默認的配置不能滿足系統的要求,那麼此時就可以自己動手來調節。

此時"Young generation"可以採用"Parallel copying collector",而"Old generation"則可以採用"Concurrent Collector",

舉個例子來說,以下參數設置了新生代用Parallel Copying Collector老生代採用CMS收集器。

java -server -Xms512m -Xmx512m  -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=2         -XX:+UseConcMarkSweepGC -XX:+UseParNewGC 

此時需要注意兩個問題:

如果沒有指定-XX:+UseParNewGC,則採用默認的非並行版本的copy collector.

2  如果在一個單CPU的系統上設置了-XX:+UseParNewGC ,則默認還是採用缺省的copy collector.

3.2.1 控制並行的線程數

默認情況下,Parallel copy collector啓動和CPU數量一樣的線程,也可以通過參數-XX:ParallelGCThreads來指定,比如你想用3個線程去進行併發的複製收集,那麼可以改變上述參數如下:

java -server -Xms512m -Xmx512m -XX:NewSize=64m  -XX:MaxNewSize=64m -XX:SurvivorRatio=2        -XX:ParallelGCThreads=4    -XX:+UseConcMarkSweepGC       -XX:+UseParNewGC 

3.2.2 控制併發收集的臨界值

默認情況下,CMS gc"old generation"空間佔用率高於68%的時候,就會進行垃圾收集,而如果想控制收集的臨界值,可以通過參數:-XX:CMSInitiatingOccupancyFraction來控制,比如改變上述的JVM配置如下:

java -server -Xms512m -Xmx512m -XX:NewSize=64m  -XX:MaxNewSize=64m -XX:SurvivorRatio=2        -XX:ParallelGCThreads=4    -XX:+UseConcMarkSweepGC       -XX:+UseParNewGC      -XX:CMSInitiatingOccupancyFraction=35

 

 GC觸發以及常見的內存錯誤

4.1 Minor GC的觸發

Minor GC主要負責收集Young GenerationMinor GC一般在新生代不夠用的情況下觸發,比如我們一次性創建了很多對象等。

List buffer = new ArrayList(); for(int i=0;i<8*1024;i++){

 

buffer.add(new byte[1024]);

}

以上代碼通過一個字節數組的List模擬觸發Minor gc,設置JVM參數如下:

-verbose:gc -Xmn10M -Xms64M -Xmx64M -XX:+PrintGC

設置以上參數以後,因爲-Xmn=10M,默認-XX:SurvivorRatio=8 ,則eden的空間大小爲8M,當eden對象大小超過8M的時候就會觸發Minor gc.

運行的結果如下:

[GC 8192K->8030K(64512K), 0.0243391 secs]

從運行結果可以看出,gc前和gc後的eden區的佔用情況,需要注意的是括號裏(64512)這個數值時63M,它不包括一塊Survivor 空間。

這裏需要注意的一點就是,如果創建的對象大於eden的大小,那麼將不會通過Survivor空間複製,直接轉移到old generation.

調整以上代碼如下:

List buffer = new ArrayList();

buffer.add(new byte[8*1024*1024]);

通過同樣的JVM參數運行,則發現不會觸發Minor gc,這是因爲對象超過了eden的大小,從而直接分配到了Old generation.

 

4.2 Major GC的觸發

4.2.1 Old Generation空間滿或者接近某一個比例

Old generation 空間滿是因爲Young generation提升到Old generation的對象+Old generation的本來的大小已經接近或者超過了Old generation的大小。對於CMS GC,當Old generation空間使用率接近某一個比例,可以通過參數-XX:CMS InitialingOccupancyFraction,此參數表示Old generation的使用率,默認爲68%

Young generation對象提升到Old generation對象有以下三種情況:

Ø 分配的對象大於eden空間的大小

Ø Young generation代中經過了-XX:MaxTenuringThreshold次複製任然存活的對象

Ø Minor gc的時候,放不進to survivor的對象

Major GC以後,如果還沒有足夠的空間可以用的話,此時就會拋出java.lang.OutOfMemoryjava heap space,當出現此錯誤的時候,說明可能存在內存泄露現象的,這時候就需要我們對程序進行檢查看看什麼地方存在內存泄露的。

我們可以通過以下代碼來模擬一下java.lang.OutOfMemory:java heap space的發生:

List buffer = new ArrayList();

buffer.add(new byte[10*1024*1024]);

以上代碼分配了一個10M的字節數組,我們通過以下的參數運行:

-verbose:gc -Xmn10M -Xms20M -Xmx20M -XX:+PrintGC

以上參數指定Young generation的空間大小爲10MOld generation空間大小爲10M

運行結果如下:

[GC 327K->134K(19456K), 0.0056516 secs]

[Full GC 134K->134K(19456K), 0.0178891 secs]

[Full GC 134K->131K(19456K), 0.0141412 secs]

Exception in thread "main" java.lang.OutOfMemoryError:   Java heap space

        at Test.main(Test.java:30)

從運行結果可以看出,JVM進行了一次Minor gc和兩次的Major gc,從Major gc的輸出可以看出,gc以後old區使用率爲134K,而字節數組爲10M,加起來大於了old generation的空間,所以拋出了異常,如果調整-Xms21M,-Xmx21M,那麼就不會觸發gc操作也不會出現異常了。

4.2.2 Perm Generation 空間滿

Perm Generation空間主要存放Class對象,Field,Method對象,當一次性加載太多的類或者在熱部署以後不卸載類的情況(比如在Jboss服務器中,如果經常熱部署一些應用就會出現Perm 空間溢出)就會造成Perm Generation被佔滿,此時就會出現:

java.lang.OutOfMemory:PermGen space,在出現此異常的時候,如果是因爲熱部署引起的,我們重新啓動AS就可以了,如果是因爲加載的類太多,此時可以通過-XX:PermSize-XX:MaxPermSize調整。

4.3 常見內存錯誤分析

4.3.1 StackOverflowError 

java.lang.StackOverflowError錯誤表示JVM棧溢出,出現這個錯誤的原因一般都是遞歸的層次太深,或者無限的遞歸造成的。出現這種錯誤的時候首先要對應用程序進行檢查,看看是那些代碼造成了棧溢出,如果是遞歸造成的可以改爲迭代方式實現。

JVM同樣也提供了一個參數來讓我們調節運行時棧空間的大小。-XX:Xss=256K表示棧空間最大爲256K.我們也可以調大,但是建議不要對此參數進行調節。

4.3.2 OutOfMemoryError: Java heap space.

java.lang.OutOfMemoryError: Java heap space這個錯誤表示JVM的新生代和老生代的內存不足。出現這個錯誤說明應用程序出現了內存溢出或者程序所需要的內存大於JVM的內存設置了。

遇到這個問題的時候,首先我們可以調節JVMHeap內存的大小,具體可以通過-Xmx -Xms來進行設置,如果設置大以後還是會出現內存溢出,那麼說明應用程序本身存在內存泄露,這個時候就需要我們對應用程序進行檢查,找出導致內存泄露的地方,然後修正。

4.3.3 OutOfMemory:PermGen space

java.lang.OutOfMemory:PermGen space錯誤是由Perm space空間不足。一般出現這個錯誤是由加載了太多的類或者大量使用了動態代理造成的。如果出現了這個錯誤,我們可以將Perm空間調大一點。

-XX:PermSize=16M  -XX:MaxPermSize=64M

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章