[Java性能剖析]Sun JVM內存管理和垃圾回收

內存管理和垃圾回收是JVM很是關鍵的點，對Java性能的剖析而言，瞭解內存管理和垃圾回收的基本策略很是重要。本篇對Sun JVM 6.0的內存管理和垃圾回收作大概的描述。

      1.內存管理
      在程序運行過程中，會建立大量的對象，這些對象，大部分是短週期的對象，小部分是長週期的對象，對於短週期的對象，須要頻繁地進行垃圾回收以保證無用對象儘早被釋放掉，對於長週期對象，則不須要頻率垃圾回收以確保無謂地垃圾掃描檢測。爲解決這種矛盾，Sun JVM的內存管理採用分代的策略。
      1）年輕代(Young Gen)：年輕代主要存放新建立的對象，內存大小相對會比較小，垃圾回收會比較頻繁。年輕代分紅1個Eden Space和2個Suvivor Space（命名爲A和B）
當對象在堆建立時，將進入年輕代的Eden Space。
垃圾回收器進行垃圾回收時，掃描Eden Space和A Suvivor Space，若是對象仍然存活，則複製到B Suvivor Space，若是B Suvivor Space已經滿，則複製 Old Gen
掃描A Suvivor Space時，若是對象已經通過了幾回的掃描仍然存活，JVM認爲其爲一個Old對象，則將其移到Old Gen。
掃描完畢後，JVM將Eden Space和A Suvivor Space清空，而後交換A和B的角色（即下次垃圾回收時會掃描Eden Space和BSuvivor Space。

      咱們能夠看到：Young Gen垃圾回收時，採用將存活對象複製到到空的Suvivor Space的方式來確保不存在內存碎片，採用空間換時間的方式來加速內存垃圾回收。
      2）年老代(Tenured Gen)：年老代主要存放JVM認爲比較old的對象（通過幾回的Young Gen的垃圾回收後仍然存在），內存大小相對會比較大，垃圾回收也相對沒有那麼頻繁（譬如可能幾個小時一次）。年老代主要採用壓縮的方式來避免內存碎片（將存活對象移動到內存片的一邊），固然，有些垃圾回收器（譬如CMS垃圾回收器）出於效率的緣由，可能會不進行壓縮。
      3）持久代(Perm Gen)：持久代主要存放類定義、字節碼和常量等不多會變動的信息

 

1. Heap設定與垃圾回收

Java Heap分爲3個區，Young，Old和Permanent。Young保存剛實例化的對象。當該區被填滿時，GC會將對象移到Old區。Permanent區則負責保存反射對象，本文不討論該區。

JVM的Heap分配可使用-X參數設定，

-Xms	初始Heap大小
-Xmx	java heap最大值
-Xmn	young generation的heap大小

JVM有2個GC線程。第一個線程負責回收Heap的Young區。第二個線程在Heap不足時，遍歷Heap，將Young 區升級爲Older區。Older區的大小等於-Xmx減去-Xmn，不能將-Xms的值設的過大，由於第二個線程被迫運行會下降JVM的性能。

爲何一些程序頻繁發生GC？有以下緣由：

l         程序內調用了System.gc()或Runtime.gc()。

l         一些中間件軟件調用本身的GC方法，此時須要設置參數禁止這些GC。

l         Java的Heap過小，通常默認的Heap值都很小。

l         頻繁實例化對象，Release對象。此時儘可能保存並重用對象，例如使用StringBuffer()和String()。

若是你發現每次GC後，Heap的剩餘空間會是總空間的50%，這表示你的Heap處於健康狀態。許多Server端的Java程序每次GC後最好能有65%的剩餘空間。

經驗之談：

1 ． Server 端 JVM 最好將 -Xms 和 -Xmx 設爲相同值。爲了優化 GC ，最好讓 -Xmn 值約等於 -Xmx 的 1/3[2] 。

2 ．一個 GUI 程序最好是每 10 到 20 秒間運行一次 GC ，每次在半秒以內完成 [2] 。

 

注意：

1．增長Heap的大小雖然會下降GC的頻率，但也增長了每次GC的時間。而且GC運行時，全部的用戶線程將暫停，也就是GC期間，Java應用程序不作任何工做。

2．Heap大小並不決定進程的內存使用量。進程的內存使用量要大於-Xmx定義的值，由於Java爲其餘任務分配內存，例如每一個線程的Stack等。

 

2．Stack的設定

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

-Xss	每一個線程的 Stack 大小

Stack的大小限制着線程的數量。若是Stack過大就好致使內存溢漏。-Xss參數決定Stack大小，例如-Xss1024K。若是Stack過小，也會致使Stack溢漏。

3．硬件環境

硬件環境也影響GC的效率，例如機器的種類，內存，swap空間，和CPU的數量。

若是你的程序須要頻繁建立不少transient對象，會致使JVM頻繁GC。這種狀況你能夠增長機器的內存，來減小Swap空間的使用[2]。

4．4種GC

第一種爲單線程GC，也是默認的GC。，該GC適用於單CPU機器。

第二種爲Throughput GC，是多線程的GC，適用於多CPU，使用大量線程的程序。第二種GC與第一種GC類似，不一樣在於GC在收集Young區是多線程的，但在Old區和第一種同樣，仍然採用單線程。-XX:+UseParallelGC參數啓動該GC。

第三種爲Concurrent Low Pause GC，相似於第一種，適用於多CPU，並要求縮短因GC形成程序停滯的時間。這種GC能夠在Old區的回收同時，運行應用程序。-XX:+UseConcMarkSweepGC參數啓動該GC。

第四種爲Incremental Low Pause GC，適用於要求縮短因GC形成程序停滯的時間。這種GC能夠在Young區回收的同時，回收一部分Old區對象。-Xincgc參數啓動該GC。

4種GC的具體描述參見[3]。

 

參考文章：

1. JVM Tuning. http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp#garbage-collection

2. Performance tuning Java: Tuning steps

http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1604,00.html

3. Tuning Garbage Collection with the 1.4.2 JavaTM Virtual Machine .

http://java.sun.com/docs/hotspot/gc1.4.2/