Java記憶體分配和回收的機制概括的說，就是：分代分配，分代回收。 對象將根據存活的時間被分為：年輕代（Young Generation）、年老代（Old Generation）、永久代（Permanent Generation，也就是方法區）。 java中每新new一個對象所占用的記憶體空間就是年輕代 ...
Java記憶體分配和回收的機制概括的說，就是：分代分配，分代回收。
對象將根據存活的時間被分為：年輕代（Young Generation）、年老代（Old Generation）、永久代（Permanent Generation，也就是方法區）。
java中每新new一個對象所占用的記憶體空間就是年輕代的空間，當java垃圾回收機制對堆區進行資源回收後，那些年輕代中沒有被回收的資源將被轉移到中生代，中生代的被轉移到老生代。
記憶體由 Perm 和 Heap 組成. 其中
Heap = {Old + NEW = { Eden , from, to } }
JVM記憶體模型中Heap區分兩大塊，一塊是 NEW Generation（年輕代）, 另一塊是Old Generation（年老代）.
在New Generation中，有一個叫Eden的空間，主要是用來存放新生的對象，還有兩個Survivor Spaces（from,to）, 它們用來存放每次垃圾回收後存活下來的對象。
在Old Generation中，主要存放應用程式中生命周期長的記憶體對象。
在Permanent Generation中，主要用來放JVM自己的反射對象，比如類對象和方法對象等。
在NewGeneration塊中，垃圾回收一般用Copying的演算法，速度快。每次GC的時候，存活下來的對象首先由Eden拷貝到某個SurvivorSpace, 當Survivor Space空間滿了後, 剩下的live對象就被直接拷貝到OldGeneration中去。因此，每次GC後，Eden記憶體塊會被清空。在OldGeneration塊中，垃圾回收一般用mark-compact的演算法，速度慢些，但減少記憶體要求.
垃圾回收分多級，0級為全部(Full)的垃圾回收，會回收OLD段中的垃圾；1級或以上為部分垃圾回收，只會回收NEW中的垃圾，記憶體溢出通常發生於OLD段或Perm段垃圾回收後，仍然無記憶體空間容納新的Java對象的情況。
當一個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錯誤”
JVM記憶體的幾種參數:
配置堆區的參數：（-Xms 、-Xmx、-XX:newSize、-XX:MaxnewSize、-Xmn）
1、-Xms ：表示java虛擬機堆區記憶體初始記憶體分配的大小，通常為操作系統可用記憶體的1/64大小即可，但仍需按照實際情況進行分配。
2、-Xmx： 表示java虛擬機堆區記憶體可被分配的最大上限，通常為操作系統可用記憶體的1/4大小。但是開發過程中，通常會將 -Xms 與 -Xmx兩個參數的配置相同的值，其目的是為了能夠在java垃圾回收機制清理完堆區後不需要重新分隔計算堆區的大小而浪費資源。
-XX:newSize、-XX:MaxnewSize、-Xmn 是對堆區的進一步細化分：新生代、中生代、老生代。java中每新new一個對象所占用的記憶體空間就是新生代的空間，當java垃圾回收機制對堆區進行資源回收後，那些新生代中沒有被回收的資源將被轉移到中生代，中生代的被轉移到老生代。而接下來要講述的三個參數是用來控制新生代記憶體大小的。
1、-XX:newSize：表示新生代初始記憶體的大小，應該小於 -Xms的值；
2、-XX:MaxnewSize：表示新生代可被分配的記憶體的最大上限；當然這個值應該小於 -Xmx的值；
3、-Xmn：至於這個參數則是對 -XX:newSize、-XX:MaxnewSize兩個參數的同時配置，也就是說如果通過-Xmn來配置新生代的記憶體大小，那麼-XX:newSize = -XX:MaxnewSize = -Xmn，雖然會很方便，但需要註意的是這個參數是在JDK1.4版本以後才使用的。
配置非堆區的參數：（-XX:PermSize、-XX:MaxPermSize）
1、-XX:PermSize：表示非堆區初始記憶體分配大小，其縮寫為permanent size（持久化記憶體）
2、-XX:MaxPermSize：表示對非堆區分配的記憶體的最大上限。
這裡面非常要註意的一點是：在配置之前一定要慎重的考慮一下自身軟體所需要的非堆區記憶體大小，因為此處記憶體是不會被java垃圾回收機制進行處理的地方。並且更加要註意的是 最大堆記憶體與最大非堆記憶體的和絕對不能夠超出操作系統的可用記憶體。
JVM調優建議:
ms/mx：定義YOUNG+OLD段的總尺寸，ms為JVM啟動時YOUNG+OLD的記憶體大小；mx為最大可占用的YOUNG+OLD記憶體大小。在用戶生產環境上一般將這兩個值設為相同，以減少運行期間系統在記憶體申請上所花的開銷。
NewSize/MaxNewSize：定義YOUNG段的尺寸，NewSize為JVM啟動時YOUNG的記憶體大小；MaxNewSize為最大可占用的YOUNG記憶體大小。在用戶生產環境上一般將這兩個值設為相同，以減少運行期間系統在記憶體申請上所花的開銷。
PermSize/MaxPermSize：定義Perm段的尺寸，PermSize為JVM啟動時Perm的記憶體大小；MaxPermSize為最大可占用的Perm記憶體大小。在用戶生產環境上一般將這兩個值設為相同，以減少運行期間系統在記憶體申請上所花的開銷。
SurvivorRatio：設置Survivor空間和Eden空間的比例
記憶體溢出的可能性:
1. OLD段溢出
這種記憶體溢出是最常見的情況之一，產生的原因可能是：
1) 設置的記憶體參數過小(ms/mx, NewSize/MaxNewSize)
2) 程式問題
單個程式持續進行消耗記憶體的處理，如迴圈幾千次的字元串處理，對字元串處理應建議使用StringBuffer。此時不會報記憶體溢出錯，卻會使系統持續垃圾收集，無法處理其它請求，相關問題程式可通過Thread Dump獲取（見系統問題診斷一章）單個程式所申請記憶體過大，有的程式會申請幾十乃至幾百兆記憶體，此時JVM也會因無法申請到資源而出現記憶體溢出，對此首先要找到相關功能，然後交予程式員修改，要找到相關程式，必須在Apache日誌中尋找。
當Java對象使用完畢後，其所引用的對象卻沒有銷毀，使得JVM認為他還是活躍的對象而不進行回收，這樣累計占用了大量記憶體而無法釋放。由於目前市面上還沒有對系統影響小的記憶體分析工具，故此時只能和程式員一起定位。
2. Perm段溢出
通常由於Perm段裝載了大量的Servlet類而導致溢出，目前的解決辦法：
1) 將PermSize擴大，一般256M能夠滿足要求
2) 若別無選擇，則只能將servlet的路徑加到CLASSPATH中，但一般不建議這麼處理
3. C Heap溢出
系統對C Heap沒有限制，故C Heap發生問題時，Java進程所占記憶體會持續增長，直到占用所有可用系統記憶體
其他：
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
年輕代:
所有新生成的對象首先都是放在年輕代的。年輕代的目標就是儘可能快速的收集掉那些生命周期短的對象。年輕代分三個區。一個Eden區，兩個Survivor區(一般而言)。大部分對象在Eden區中生成。當Eden區滿時，還存活的對象將被覆制到Survivor區（兩個中的一個），當這個Survivor區滿時，此區的存活對象將被覆制到另外一個Survivor區，當這個Survivor區也滿了的時候，從第一個Survivor區複製過來的並且此時還存活的對象，將被覆制“年老區(Tenured)”。需要註意，Survivor的兩個區是對稱的，沒先後關係，所以同一個區中可能同時存在從Eden複製過來 對象，和從前一個Survivor複製過來的對象，而複製到年老區的只有從第一個Survivor去過來的對象。而且，Survivor區總有一個是空的。同時，根據程式需要，Survivor區是可以配置為多個的（多於兩個），這樣可以增加對象在年輕代中的存在時間，減少被放到年老代的可能。
年老代:
在年輕代中經歷了N次垃圾回收後仍然存活的對象，就會被放到年老代中。因此，可以認為年老代中存放的都是一些生命周期較長的對象。
持久代:
用於存放靜態文件，如今Java類、方法等。持久代對垃圾回收沒有顯著影響，但是有些應用可能動態生成或者調用一些class，例如Hibernate等，在這種時候需要設置一個比較大的持久代空間來存放這些運行過程中新增的類。持久代大小通過-XX:MaxPermSize=<N>進行設置。
什麼情況下觸發垃圾回收
由於對象進行了分代處理，因此垃圾回收區域、時間也不一樣。GC有兩種類型：Scavenge GC和Full GC。
Scavenge GC
一般情況下，當新對象生成，並且在Eden申請空間失敗時，就會觸發Scavenge GC，對Eden區域進行GC，清除非存活對象，並且把尚且存活的對象移動到Survivor區。然後整理Survivor的兩個區。這種方式的GC是對年輕代的Eden區進行，不會影響到年老代。因為大部分對象都是從Eden區開始的，同時Eden區不會分配的很大，所以Eden區的GC會頻繁進行。因而，一般在這裡需要使用速度快、效率高的演算法，使Eden去能儘快空閑出來。
Full GC
對整個堆進行整理，包括Young、Tenured和Perm。Full GC因為需要對整個對進行回收，所以比Scavenge GC要慢，因此應該儘可能減少Full GC的次數。在對JVM調優的過程中，很大一部分工作就是對於FullGC的調節。有如下原因可能導致Full GC：
· 年老代（Tenured）被寫滿
· 持久代（Perm）被寫滿
· System.gc()被顯示調用
·上一次GC之後Heap的各域分配策略動態變化
參考資料：http://www.cnblogs.com/hnrainll/archive/2013/11/06/3410042.html
