JVM調優總結
一些概念
資料型別
Java虛擬機器中，資料型別可以分為兩類：基本型別和引用型別。基本型別的變數儲存原始值，即：他代表的值就是數值本身；而引用型別的變數儲存引用值。“引用值”代表了某個物件的引用，而不是物件本身，物件本身存放在這個引用值所表示的地址的位置。
基本型別包括：byte,short,int,long,char,float,double,Boolean,returnAddress
引用型別包括：類型別，介面型別和陣列。
堆與棧
堆和棧是程式執行的關鍵，很有必要把他們的關係說清楚。
棧是執行時的單位，而堆是儲存的單位。
棧解決程式的執行問題，即程式如何執行，或者說如何處理資料；堆解決的是資料儲存的問題，即資料怎麼放、放在哪兒。
在Java中一個執行緒就會相應有一個執行緒棧與之對應，這點很容易理解，因為不同的執行緒執行邏輯有所不同，因此需要一個獨立的執行緒棧。而堆則是所有執行緒共享的。棧因為是執行單位，因此裡面儲存的資訊都是跟當前執行緒（或程式）相關資訊的。包括區域性變數、程式執行狀態、方法返回值等等；而堆只負責儲存物件資訊。
為什麼要把堆和棧區分出來呢？棧中不是也可以儲存資料嗎？
第一，從軟體設計的角度看，棧代表了處理邏輯，而堆代表了資料。這樣分開，使得處理邏輯更為清晰。分而治之的思想。這種隔離、模組化的思想在軟體設計的方方面面都有體現。
第二，堆與棧的分離，使得堆中的內容可以被多個棧共享（也可以理解為多個執行緒訪問同一個物件）。這種共享的收益是很多的。一方面這種共享提供了一種有效的資料互動方式(如：共享記憶體)，另一方面，堆中的共享常量和快取可以被所有棧訪問，節省了空間。
第三，棧因為執行時的需要，比如儲存系統執行的上下文，需要進行地址段的劃分。由於棧只能向上增長，因此就會限制住棧儲存內容的能力。而堆不同，堆中的物件是可以根據需要動態增長的，因此棧和堆的拆分，使得動態增長成為可能，相應棧中只需記錄堆中的一個地址即可。
第四，面向物件就是堆和棧的完美結合。其實，面向物件方式的程式與以前結構化的程式在執行上沒有任何區別。但是，面向物件的引入，使得對待問題的思考方式發生了改變，而更接近於自然方式的思考。當我們把物件拆開，你會發現，物件的屬性其實就是資料，存放在堆中；而物件的行為（方法），就是執行邏輯，放在棧中。我們在編寫物件的時候，其實即編寫了資料結構，也編寫的處理資料的邏輯。不得不承認，面向物件的設計，確實很美。
在Java中，Main函式就是棧的起始點，也是程式的起始點。
程式要執行總是有一個起點的。同C語言一樣，java中的Main就是那個起點。無論什麼java程式，找到main就找到了程式執行的入口：）
堆中存什麼？棧中存什麼？
堆中存的是物件。棧中存的是基本資料型別和堆中物件的引用。一個物件的大小是不可估計的，或者說是可以動態變化的，但是在棧中，一個物件只對應了一個4btye的引用（堆疊分離的好處：））。
為什麼不把基本型別放堆中呢？因為其佔用的空間一般是1~8個位元組——需要空間比較少，而且因為是基本型別，所以不會出現動態增長的情況——長度固定，因此棧中儲存就夠了，如果把他存在堆中是沒有什麼意義的（還會浪費空間，後面說明）。可以這麼說，基本型別和物件的引用都是存放在棧中，而且都是幾個位元組的一個數，因此在程式執行時，他們的處理方式是統一的。但是基本型別、物件引用和物件本身就有所區別了，因為一個是棧中的資料一個是堆中的資料。最常見的一個問題就是，Java中引數傳遞時的問題。
Java中的引數傳遞時傳值呢？還是傳引用？
要說明這個問題，先要明確兩點：
1. 不要試圖與C進行類比，Java中沒有指標的概念
2. 程式執行永遠都是在棧中進行的，因而引數傳遞時，只存在傳遞基本型別和物件引用的問題。不會直接傳物件本身。
明確以上兩點後。Java在方法呼叫傳遞引數時，因為沒有指標，所以它都是進行傳值呼叫（這點可以參考C的傳值呼叫）。因此，很多書裡面都說Java是進行傳值呼叫，這點沒有問題，而且也簡化的C中複雜性。
但是傳引用的錯覺是如何造成的呢？在執行棧中，基本型別和引用的處理是一樣的，都是傳值，所以，如果是傳引用的方法呼叫，也同時可以理解為“傳引用值”的傳值呼叫，即引用的處理跟基本型別是完全一樣的。但是當進入被呼叫方法時，被傳遞的這個引用的值，被程式解釋（或者查詢）到堆中的物件，這個時候才對應到真正的物件。如果此時進行修改，修改的是引用對應的物件，而不是引用本身，即：修改的是堆中的資料。所以這個修改是可以保持的了。
物件，從某種意義上說，是由基本型別組成的。可以把一個物件看作為一棵樹，物件的屬性如果還是物件，則還是一顆樹（即非葉子節點），基本型別則為樹的葉子節點。程式引數傳遞時，被傳遞的值本身都是不能進行修改的，但是，如果這個值是一個非葉子節點（即一個物件引用），則可以修改這個節點下面的所有內容。
堆和棧中，棧是程式執行最根本的東西。程式執行可以沒有堆，但是不能沒有棧。而堆是為棧進行資料儲存服務，說白了堆就是一塊共享的記憶體。不過，正是因為堆和棧的分離的思想，才使得Java的垃圾回收成為可能。
Java中，棧的大小通過-Xss來設定，當棧中儲存資料比較多時，需要適當調大這個值，否則會出現java.lang.StackOverflowError異常。常見的出現這個異常的是無法返回的遞迴，因為此時棧中儲存的資訊都是方法返回的記錄點。
Java物件的大小
基本資料的型別的大小是固定的，這裡就不多說了。對於非基本型別的Java物件，其大小就值得商榷。
在Java中，一個空Object物件的大小是8byte，這個大小隻是儲存堆中一個沒有任何屬性的物件的大小。看下面語句：
Object ob = new Object();
這樣在程式中完成了一個Java物件的生命，但是它所佔的空間為：4byte+8byte。4byte是上面部分所說的Java棧中儲存引用的所需要的空間。而那8byte則是Java堆中物件的資訊。因為所有的Java非基本型別的物件都需要預設繼承Object物件，因此不論什麼樣的Java物件，其大小都必須是大於8byte。
有了Object物件的大小，我們就可以計算其他物件的大小了。
Class NewObject {
int count;
boolean flag;
Object ob;
}
其大小為：空物件大小(8byte)+int大小(4byte)+Boolean大小(1byte)+空Object引用的大小(4byte)=17byte。但是因為Java在對物件記憶體分配時都是以8的整數倍來分，因此大於17byte的最接近8的整數倍的是24，因此此物件的大小為24byte。
這裡需要注意一下基本型別的包裝型別的大小。因為這種包裝型別已經成為物件了，因此需要把他們作為物件來看待。包裝型別的大小至少是12byte（宣告一個空Object至少需要的空間），而且12byte沒有包含任何有效資訊，同時，因為Java物件大小是8的整數倍，因此一個基本型別包裝類的大小至少是16byte。這個記憶體佔用是很恐怖的，它是使用基本型別的N倍（N>2），有些型別的記憶體佔用更是誇張（隨便想下就知道了）。因此，可能的話應儘量少使用包裝類。在JDK5.0以後，因為加入了自動型別裝換，因此，Java虛擬機器會在儲存方面進行相應的優化。
引用型別
物件引用型別分為強引用、軟引用、弱引用和虛引用。
強引用:就是我們一般宣告物件是時虛擬機器生成的引用，強引用環境下，垃圾回收時需要嚴格判斷當前物件是否被強引用，如果被強引用，則不會被垃圾回收
軟引用:軟引用一般被做為快取來使用。與強引用的區別是，軟引用在垃圾回收時，虛擬機器會根據當前系統的剩餘記憶體來決定是否對軟引用進行回收。如果剩餘記憶體比較緊張，則虛擬機器會回收軟引用所引用的空間；如果剩餘記憶體相對富裕，則不會進行回收。換句話說，虛擬機器在發生OutOfMemory時，肯定是沒有軟引用存在的。
弱引用:弱引用與軟引用類似，都是作為快取來使用。但與軟引用不同，弱引用在進行垃圾回收時，是一定會被回收掉的，因此其生命週期只存在於一個垃圾回收週期內。
強引用不用說，我們系統一般在使用時都是用的強引用。而“軟引用”和“弱引用”比較少見。他們一般被作為快取使用，而且一般是在記憶體大小比較受限的情況下做為快取。因為如果記憶體足夠大的話，可以直接使用強引用作為快取即可，同時可控性更高。因而，他們常見的是被使用在桌面應用系統的快取。
可以從不同的的角度去劃分垃圾回收演算法：
按照基本回收策略分
引用計數（Reference Counting）:
比較古老的回收演算法。原理是此物件有一個引用，即增加一個計數，刪除一個引用則減少一個計數。垃圾回收時，只用收集計數為0的物件。此演算法最致命的是無法處理迴圈引用的問題。
標記-清除（Mark-Sweep）:
此演算法執行分兩階段。第一階段從引用根節點開始標記所有被引用的物件，第二階段遍歷整個堆，把未標記的物件清除。此演算法需要暫停整個應用，同時，會產生記憶體碎片。
複製（Copying）:
此演算法把記憶體空間劃為兩個相等的區域，每次只使用其中一個區域。垃圾回收時，遍歷當前使用區域，把正在使用中的物件複製到另外一個區域中。次演算法每次只處理正在使用中的物件，因此複製成本比較小，同時複製過去以後還能進行相應的記憶體整理，不會出現“碎片”問題。當然，此演算法的缺點也是很明顯的，就是需要兩倍記憶體空間。
標記-整理（Mark-Compact）:
此演算法結合了“標記-清除”和“複製”兩個演算法的優點。也是分兩階段，第一階段從根節點開始標記所有被引用物件，第二階段遍歷整個堆，把清除未標記物件並且把存活物件“壓縮”到堆的其中一塊，按順序排放。此演算法避免了“標記-清除”的碎片問題，同時也避免了“複製”演算法的空間問題。
按分割槽對待的方式分
增量收集（Incremental Collecting）:實時垃圾回收演算法，即：在應用進行的同時進行垃圾回收。不知道什麼原因JDK5.0中的收集器沒有使用這種演算法的。
分代收集（Generational Collecting）:基於對物件生命週期分析後得出的垃圾回收演算法。把物件分為年青代、年老代、持久代，對不同生命週期的物件使用不同的演算法（上述方式中的一個）進行回收。現在的垃圾回收器（從J2SE1.2開始）都是使用此演算法的。
按系統執行緒分
序列收集:序列收集使用單執行緒處理所有垃圾回收工作, 因為無需多執行緒互動，實現容易，而且效率比較高。但是，其侷限性也比較明顯，即無法使用多處理器的優勢，所以此收集適合單處理器機器。當然，此收集器也可以用在小資料量（100M左右）情況下的多處理器機器上。
並行收集:並行收集使用多執行緒處理垃圾回收工作，因而速度快，效率高。而且理論上CPU數目越多，越能體現出並行收集器的優勢。
併發收集:相對於序列收集和並行收集而言，前面兩個在進行垃圾回收工作時，需要暫停整個執行環境，而只有垃圾回收程式在執行，因此，系統在垃圾回收時會有明顯的暫停，而且暫停時間會因為堆越大而越長。
如何區分垃圾
上面說到的“引用計數”法，通過統計控制生成物件和刪除物件時的引用數來判斷。垃圾回收程式收集計數為0的物件即可。但是這種方法無法解決迴圈引用。所以，後來實現的垃圾判斷演算法中，都是從程式執行的根節點出發，遍歷整個物件引用，查詢存活的物件。那麼在這種方式的實現中，垃圾回收從哪兒開始的呢？即，從哪兒開始查詢哪些物件是正在被當前系統使用的。上面分析的堆和棧的區別，其中棧是真正進行程式執行地方，所以要獲取哪些物件正在被使用，則需要從Java棧開始。同時，一個棧是與一個執行緒對應的，因此，如果有多個執行緒的話，則必須對這些執行緒對應的所有的棧進行檢查。
同時，除了棧外，還有系統執行時的暫存器等，也是儲存程式執行資料的。這樣，以棧或暫存器中的引用為起點，我們可以找到堆中的物件，又從這些物件找到對堆中其他物件的引用，這種引用逐步擴充套件，最終以null引用或者基本型別結束，這樣就形成了一顆以Java棧中引用所對應的物件為根節點的一顆物件樹，如果棧中有多個引用，則最終會形成多顆物件樹。在這些物件樹上的物件，都是當前系統執行所需要的物件，不能被垃圾回收。而其他剩餘物件，則可以視為無法被引用到的物件，可以被當做垃圾進行回收。
因此，垃圾回收的起點是一些根物件（java棧, 靜態變數, 暫存器...）。而最簡單的Java棧就是Java程式執行的main函式。這種回收方式，也是上面提到的“標記-清除”的回收方式
如何處理碎片
由於不同Java物件存活時間是不一定的，因此，在程式執行一段時間以後，如果不進行記憶體整理，就會出現零散的記憶體碎片。碎片最直接的問題就是會導致無法分配大塊的記憶體空間，以及程式執行效率降低。所以，在上面提到的基本垃圾回收演算法中，“複製”方式和“標記-整理”方式，都可以解決碎片的問題。
如何解決同時存在的物件建立和物件回收問題
垃圾回收執行緒是回收記憶體的，而程式執行執行緒則是消耗（或分配）記憶體的，一個回收記憶體，一個分配記憶體，從這點看，兩者是矛盾的。因此，在現有的垃圾回收方式中，要進行垃圾回收前，一般都需要暫停整個應用（即：暫停記憶體的分配），然後進行垃圾回收，回收完成後再繼續應用。這種實現方式是最直接，而且最有效的解決二者矛盾的方式。
但是這種方式有一個很明顯的弊端，就是當堆空間持續增大時，垃圾回收的時間也將會相應的持續增大，對應應用暫停的時間也會相應的增大。一些對相應時間要求很高的應用，比如最大暫停時間要求是幾百毫秒，那麼當堆空間大於幾個G時，就很有可能超過這個限制，在這種情況下，垃圾回收將會成為系統執行的一個瓶頸。為解決這種矛盾，有了併發垃圾回收演算法，使用這種演算法，垃圾回收執行緒與程式執行執行緒同時執行。在這種方式下，解決了暫停的問題，但是因為需要在新生成物件的同時又要回收物件，演算法複雜性會大大增加，系統的處理能力也會相應降低，同時，“碎片”問題將會比較難解決。
為什麼要分代
分代的垃圾回收策略，是基於這樣一個事實：不同的物件的生命週期是不一樣的。因此，不同生命週期的物件可以採取不同的收集方式，以便提高回收效率。
在Java程式執行的過程中，會產生大量的物件，其中有些物件是與業務資訊相關，比如Http請求中的Session物件、執行緒、Socket連線，這類物件跟業務直接掛鉤，因此生命週期比較長。但是還有一些物件，主要是程式執行過程中生成的臨時變數，這些物件生命週期會比較短，比如：String物件，由於其不變類的特性，系統會產生大量的這些物件，有些物件甚至只用一次即可回收。
試想，在不進行物件存活時間區分的情況下，每次垃圾回收都是對整個堆空間進行回收，花費時間相對會長，同時，因為每次回收都需要遍歷所有存活物件，但實際上，對於生命週期長的物件而言，這種遍歷是沒有效果的，因為可能進行了很多次遍歷，但是他們依舊存在。因此，分代垃圾回收採用分治的思想，進行代的劃分，把不同生命週期的物件放在不同代上，不同代上採用最適合它的垃圾回收方式進行回收。
如何分代
如圖所示：
虛擬機器中的共劃分為三個代：年輕代（Young Generation）、年老點（Old Generation）和持久代（Permanent Generation）。其中持久代主要存放的是Java類的類資訊，與垃圾收集要收集的Java物件關係不大。年輕代和年老代的劃分是對垃圾收集影響比較大的。
年輕代:
所有新生成的物件首先都是放在年輕代的。年輕代的目標就是儘可能快速的收集掉那些生命週期短的物件。年輕代分三個區。一個Eden區，兩個Survivor區(一般而言)。大部分物件在Eden區中生成。當Eden區滿時，還存活的物件將被複制到Survivor區（兩個中的一個），當這個Survivor區滿時，此區的存活物件將被複制到另外一個Survivor區，當這個Survivor去也滿了的時候，從第一個Survivor區複製過來的並且此時還存活的物件，將被複制“年老區(Tenured)”。需要注意，Survivor的兩個區是對稱的，沒先後關係，所以同一個區中可能同時存在從Eden複製過來 物件，和從前一個Survivor複製過來的物件，而複製到年老區的只有從第一個Survivor去過來的物件。而且，Survivor區總有一個是空的。同時，根據程式需要，Survivor區是可以配置為多個的（多於兩個），這樣可以增加物件在年輕代中的存在時間，減少被放到年老代的可能。
年老代:
在年輕代中經歷了N次垃圾回收後仍然存活的物件，就會被放到年老代中。因此，可以認為年老代中存放的都是一些生命週期較長的物件。
持久代:
用於存放靜態檔案，如今Java類、方法等。持久代對垃圾回收沒有顯著影響，但是有些應用可能動態生成或者呼叫一些class，例如Hibernate等，在這種時候需要設定一個比較大的持久代空間來存放這些執行過程中新增的類。持久代大小通過-XX:MaxPermSize= 進行設定。
什麼情況下觸發垃圾回收
由於物件進行了分代處理，因此垃圾回收區域、時間也不一樣。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的各域分配策略動態變化
分代垃圾回收流程示意
選擇合適的垃圾收集演算法
用單執行緒處理所有垃圾回收工作，因為無需多執行緒互動，所以效率比較高。但是，也無法使用多處理器的優勢，所以此收集器適合單處理器機器。當然，此收集器也可以用在小資料量（100M左右）情況下的多處理器機器上。可以使用-XX:+UseSerialGC開啟。
對年輕代進行並行垃圾回收，因此可以減少垃圾回收時間。一般在多執行緒多處理器機器上使用。使用-XX:+UseParallelGC.開啟。並行收集器在J2SE5.0第六6更新上引入，在Java SE6.0中進行了增強--可以對年老代進行並行收集。如果年老代不使用併發收集的話，預設是使用單執行緒進行垃圾回收，因此會制約擴充套件能力。使用-XX:+UseParallelOldGC開啟。
使用-XX:ParallelGCThreads= 設定並行垃圾回收的執行緒數。此值可以設定與機器處理器數量相等。
此收集器可以進行如下配置：
最大垃圾回收暫停:指定垃圾回收時的最長暫停時間，通過-XX:MaxGCPauseMillis=\(
\)指定。>\( \)為毫秒.如果指定了此值的話，堆大小和垃圾回收相關引數會進行調整以達到指定值。設定此值可能會減少應用的吞吐量。 吞吐量:吞吐量為垃圾回收時間與非垃圾回收時間的比值，通過-XX:GCTimeRatio=\(
\)來設定，公>式為1/（1+N）。例如，-XX:GCTimeRatio=19時，表示5%的時間用於垃圾回收。預設情況為99，即>1%的時間用於垃圾回收。
併發收集器
可以保證大部分工作都併發進行（應用不停止），垃圾回收只暫停很少的時間，此收集器適合對響應時間要求比較高的中、大規模應用。使用-XX:+UseConcMarkSweepGC開啟。
併發收集器主要減少年老代的暫停時間，他在應用不停止的情況下使用獨立的垃圾回收執行緒，跟蹤可達物件。在每個年老代垃圾回收週期中，在收集初期併發收集器 會對整個應用進行簡短的暫停，在收集中還會再暫停一次。第二次暫停會比第一次稍長，在此過程中多個執行緒同時進行垃圾回收工作。
併發收集器使用處理器換來短暫的停頓時間。在一個N個處理器的系統上，併發收集部分使用K/N個可用處理器進行回收，一般情況下1<=K<=N/4。
在只有一個處理器的主機上使用併發收集器，設定為incremental mode模式也可獲得較短的停頓時間。
浮動垃圾：由於在應用執行的同時進行垃圾回收，所以有些垃圾可能在垃圾回收進行完成時產生，這樣就造成了“Floating Garbage”，這些垃圾需要在下次垃圾回收週期時才能回收掉。所以，併發收集器一般需要20%的預留空間用於這些浮動垃圾。
Concurrent Mode Failure：併發收集器在應用執行時進行收集，所以需要保證堆在垃圾回收的這段時間有足夠的空間供程式使用，否則，垃圾回收還未完成，堆空間先滿了。這種情況下將會發生“併發模式失敗”，此時整個應用將會暫停，進行垃圾回收。
啟動併發收集器：因為併發收集在應用執行時進行收集，所以必須保證收集完成之前有足夠的記憶體空間供程式使用，否則會出現“Concurrent Mode Failure”。通過設定-XX:CMSInitiatingOccupancyFraction= 指定還有多少剩餘堆時開始執行併發收集
小結
序列處理器：
- 適用情況：資料量比較小（100M左右）；單處理器下並且對響應時間無要求的應用。
- 缺點：只能用於小型應用
並行處理器：
- 適用情況：“對吞吐量有高要求”，多CPU、對應用響應時間無要求的中、大型應用。舉例：後臺處理、科學計算。
- 缺點：垃圾收集過程中應用響應時間可能加長
併發處理器：
- 適用情況：“對響應時間有高要求”，多CPU、對應用響應時間有較高要求的中、大型應用。舉例：Web伺服器/應用伺服器、電信交換、整合開發環境。
以下配置主要針對分代垃圾回收演算法而言。
堆大小設定
年輕代的設定很關鍵
JVM中最大堆大小有三方面限制：相關作業系統的資料模型（32-bt還是64-bit）限制；系統的可用虛擬記憶體限制；系統的可用實體記憶體限制。32位系統下，一般限制在1.5G~2G；64為作業系統對記憶體無限制。在Windows Server 2003 系統，3.5G實體記憶體，JDK5.0下測試，最大可設定為1478m。
典型設定：
java -Xmx3550m -Xms3550m -Xmn2g –Xss128k
-Xmx3550m：設定JVM最大可用記憶體為3550M。
-Xms3550m：設定JVM促使記憶體為3550m。此值可以設定與-Xmx相同，以避免每次垃圾回收完成後JVM重新分配記憶體。
-Xmn2g：設定年輕代大小為2G。整個堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m，所以增大年輕代後，將會減小年老代大小。此值對系統性能影響較大，Sun官方推薦配置為整個堆的3/8。
-Xss128k：設定每個執行緒的堆疊大小。JDK5.0以後每個執行緒堆疊大小為1M，以前每個執行緒堆疊大小為256K。更具應用的執行緒所需記憶體大小進行調整。在相同實體記憶體下，減小這個值能生成更多的執行緒。但是作業系統對一個程序內的執行緒數還是有限制的，不能無限生成，經驗值在3000~5000左右。
java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:設定年輕代（包括Eden和兩個Survivor區）與年老代的比值（除去持久代）。設定為4，則年輕代與年老代所佔比值為1：4，年輕代佔整個堆疊的1/5
-XX:SurvivorRatio=4：設定年輕代中Eden區與Survivor區的大小比值。設定為4，則兩個Survivor區與一個Eden區的比值為2:4，一個Survivor區佔整個年輕代的1/6
-XX:MaxPermSize=16m:設定持久代大小為16m。
-XX:MaxTenuringThreshold=0：設定垃圾最大年齡。如果設定為0的話，則年輕代物件不經過Survivor區，直接進入年老代。對於年老代比較多的應用，可以提高效率。如果將此值設定為一個較大值，則年輕代物件會在Survivor區進行多次複製，這樣可以增加物件再年輕代的存活時間，增加在年輕代即被回收的概論。
回收器選擇
JVM給了三種選擇：序列收集器、並行收集器、併發收集器，但是序列收集器只適用於小資料量的情況，所以這裡的選擇主要針對並行收集器和併發收集器。預設情況下，JDK5.0以前都是使用序列收集器，如果想使用其他收集器需要在啟動時加入相應引數。JDK5.0以後，JVM會根據當前[系統配置][Link 1]進行判斷。
吞吐量優先的並行收集器
如上文所述，並行收集器主要以到達一定的吞吐量為目標，適用於科學技術和後臺處理等。
典型配置：
java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC：選擇垃圾收集器為並行收集器。此配置僅對年輕代有效。即上述配置下，年輕代使用併發收集，而年老代仍舊使用序列收集。
-XX:ParallelGCThreads=20：配置並行收集器的執行緒數，即：同時多少個執行緒一起進行垃圾回收。此值最好配置與處理器數目相等。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC：配置年老代垃圾收集方式為並行收集。JDK6.0支援對年老代並行收集。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:設定每次年輕代垃圾回收的最長時間，如果無法滿足此時間，JVM會自動調整年輕代大小，以滿足此值。
n java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy：設定此選項後，並行收集器會自動選擇年輕代區大小和相應的Survivor區比例，以達到目標系統規定的最低相應時間或者收集頻率等，此值建議使用並行收集器時，一直開啟。
響應時間優先的併發收集器
如上文所述，併發收集器主要是保證系統的響應時間，減少垃圾收集時的停頓時間。適用於應用伺服器、電信領域等。
典型配置：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC：設定年老代為併發收集。測試中配置這個以後，-XX:NewRatio=4的配置失效了，原因不明。所以，此時年輕代大小最好用-Xmn設定。
-XX:+UseParNewGC: 設定年輕代為並行收集。可與CMS收集同時使用。JDK5.0以上，JVM會根據系統配置自行設定，所以無需再設定此值。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction：由於併發收集器不對記憶體空間進行壓縮、整理，所以執行一段時間以後會產生“碎片”，使得執行效率降低。此值設定執行多少次GC以後對記憶體空間進行壓縮、整理。
-XX:+UseCMSCompactAtFullCollection：開啟對年老代的壓縮。可能會影響效能，但是可以消除碎片
輔助資訊
JVM提供了大量命令列引數，列印資訊，供除錯使用。主要有以下一些：
-XX:+PrintGC：輸出形式：[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails：輸出形式：[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps可與上面兩個混合使用
輸出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationConcurrentTime：列印每次垃圾回收前，程式未中斷的執行時間。可與上面混合使用。輸出形式：Application time: 0.5291524 seconds
-XX:+PrintGCApplicationStoppedTime：列印垃圾回收期間程式暫停的時間。可與上面混合使用。輸出形式：Total time for which application threads were stopped: 0.0468229 seconds
-XX:PrintHeapAtGC: 列印GC前後的詳細堆疊資訊。輸出形式：
34.702: [GC {Heap before gc invocations=7:
def new generation total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K, 99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
from space 6144K, 55% used [0x221d0000, 0x22527e10, 0x227d0000)
to space 6144K, 0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
tenured generation total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K, 3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
def new generation total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K, 0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
from space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
to space 6144K, 0% used [0x221d0000, 0x221d0000, 0x227d0000)
tenured generation total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K, 4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}
, 0.0757599 secs]
-Xloggc:filename:與上面幾個配合使用，把相關日誌資訊記錄到檔案以便分析。
常見配置彙總
堆設定
-Xms:初始堆大小
-Xmx:最大堆大小
-XX:NewSize=n:設定年輕代大小
-XX:NewRatio=n:設定年輕代和年老代的比值。如:為3，表示年輕代與年老代比值為1：3，年輕代佔整個年輕代年老代和的1/4
-XX:SurvivorRatio=n:年輕代中Eden區與兩個Survivor區的比值。注意Survivor區有兩個。如：3，表示Eden：Survivor=3：2，一個Survivor區佔整個年輕代的1/5
-XX:MaxPermSize=n:設定持久代大小
收集器設定
-XX:+UseSerialGC:設定序列收集器
-XX:+UseParallelGC:設定並行收集器
-XX:+UseParalledlOldGC:設定並行年老代收集器
-XX:+UseConcMarkSweepGC:設定併發收集器
垃圾回收統計資訊
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename
並行收集器設定
-XX:ParallelGCThreads=n:設定並行收集器收集時使用的CPU數。並行收集執行緒數。
-XX:MaxGCPauseMillis=n:設定並行收集最大暫停時間
-XX:GCTimeRatio=n:設定垃圾回收時間佔程式執行時間的百分比。公式為1/(1+n)
併發收集器設定
-XX:+CMSIncrementalMode:設定為增量模式。適用於單CPU情況。
-XX:ParallelGCThreads=n:設定併發收集器年輕代收集方式為並行收集時，使用的CPU數。並行收集執行緒數。
調優總結
年輕代大小選擇
響應時間優先的應用：儘可能設大，直到接近系統的最低響應時間限制（根據實際情況選擇）。在此種情況下，年輕代收集發生的頻率也是最小的。同時，減少到達年老代的物件。
吞吐量優先的應用：儘可能的設定大，可能到達Gbit的程度。因為對響應時間沒有要求，垃圾收集可以並行進行，一般適合8CPU以上的應用。
年老代大小選擇
響應時間優先的應用：年老代使用併發收集器，所以其大小需要小心設定，一般要考慮併發會話率和會話持續時間等一些引數。如果堆設定小了，可以會造成記憶體碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式；如果堆大了，則需要較長的收集時間。最優化的方案，一般需要參考以下資料獲得：
- 併發垃圾收集資訊
- 持久代併發收集次數
- 傳統GC資訊
- 花在年輕代和年老代回收上的時間比例
減少年輕代和年老代花費的時間，一般會提高應用的效率
吞吐量優先的應用
一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。原因是，這樣可以儘可能回收掉大部分短期物件，減少中期的物件，而年老代盡存放長期存活物件。
較小堆引起的碎片問題
因為年老代的併發收集器使用標記、清除演算法，所以不會對堆進行壓縮。當收集器回收時，他會把相鄰的空間進行合併，這樣可以分配給較大的物件。但是，當堆空間較小時，執行一段時間以後，就會出現“碎片”，如果併發收集器找不到足夠的空間，那麼併發收集器將會停止，然後使用傳統的標記、清除方式進行回收。如果出現“碎片”，可能需要進行如下配置：
- -XX:+UseCMSCompactAtFullCollection：使用併發收集器時，開啟對年老代的壓縮。
- -XX:CMSFullGCsBeforeCompaction=0：上面配置開啟的情況下，這裡設定多少次Full GC後，對年老代進行壓縮
垃圾回收的瓶頸
傳統分代垃圾回收方式，已經在一定程度上把垃圾回收給應用帶來的負擔降到了最小，把應用的吞吐量推到了一個極限。但是他無法解決的一個問題，就是Full GC所帶來的應用暫停。在一些對實時性要求很高的應用場景下，GC暫停所帶來的請求堆積和請求失敗是無法接受的。這類應用可能要求請求的返回時間在幾百甚至幾十毫秒以內，如果分代垃圾回收方式要達到這個指標，只能把最大堆的設定限制在一個相對較小範圍內，但是這樣有限制了應用本身的處理能力，同樣也是不可接收的。
分代垃圾回收方式確實也考慮了實時性要求而提供了併發回收器，支援最大暫停時間的設定，但是受限於分代垃圾回收的記憶體劃分模型，其效果也不是很理想。
為了達到實時性的要求（其實Java語言最初的設計也是在嵌入式系統上的），一種新垃圾回收方式呼之欲出，它既支援短的暫停時間，又支援大的記憶體空間分配。可以很好的解決傳統分代方式帶來的問題。
增量收集的演進
增量收集的方式在理論上可以解決傳統分代方式帶來的問題。增量收集把對堆空間劃分成一系列記憶體塊，使用時，先使用其中一部分（不會全部用完），垃圾收集時把之前用掉的部分中的存活物件再放到後面沒有用的空間中，這樣可以實現一直邊使用邊收集的效果，避免了傳統分代方式整個使用完了再暫停的回收的情況。
當然，傳統分代收集方式也提供了併發收集，但是他有一個很致命的地方，就是把整個堆做為一個記憶體塊，這樣一方面會造成碎片（無法壓縮），另一方面他的每次收集都是對整個堆的收集，無法進行選擇，在暫停時間的控制上還是很弱。而增量方式，通過記憶體空間的分塊，恰恰可以解決上面問題。
Garbage Firest（G1）
這部分的內容主要參考[這裡][Link 2]，這篇文章算是對G1演算法論文的解讀。我也沒加什麼東西了。
目標
從設計目標看G1完全是為了大型應用而準備的。
支援很大的堆
高吞吐量
--支援多CPU和垃圾回收執行緒
--在主執行緒暫停的情況下，使用並行收集
--在主執行緒執行的情況下，使用併發收集
實時目標：可配置在N毫秒內最多隻佔用M毫秒的時間進行垃圾回收
當然G1要達到實時性的要求，相對傳統的分代回收演算法，在效能上會有一些損失。
演算法詳解
G1可謂博採眾家之長，力求到達一種完美。他吸取了增量收集優點，把整個堆劃分為一個一個等大小的區域（region）。記憶體的回收和劃分都以region為單位；同時，他也吸取了CMS的特點，把這個垃圾回收過程分為幾個階段，分散一個垃圾回收過程；而且，G1也認同分代垃圾回收的思想，認為不同物件的生命週期不同，可以採取不同收集方式，因此，它也支援分代的垃圾回收。為了達到對回收時間的可預計性，G1在掃描了region以後，對其中的活躍物件的大小進行排序，首先會收集那些活躍物件小的region，以便快速回收空間（要複製的活躍物件少了），因為活躍物件小，裡面可以認為多數都是垃圾，所以這種方式被稱為Garbage First（G1）的垃圾回收演算法，即：垃圾優先的回收。
回收步驟：
初始標記（Initial Marking）
G1對於每個region都儲存了兩個標識用的bitmap，一個為previous marking bitmap，一個為next marking bitmap，bitmap中包含了一個bit的地址資訊來指向物件的起始點。
開始Initial Marking之前，首先併發的清空next marking bitmap，然後停止所有應用執行緒，並掃描標識出每個region中root可直接訪問到的物件，將region中top的值放入next top at mark start（TAMS）中，之後恢復所有應用執行緒。
觸發這個步驟執行的條件為：
G1定義了一個JVM Heap大小的百分比的閥值，稱為h，另外還有一個H，H的值為(1-h)*Heap Size，目前這個h的值是固定的，後續G1也許會將其改為動態的，根據jvm的執行情況來動態的調整，在分代方式下，G1還定義了一個u以及soft limit，soft limit的值為H-u*Heap Size，當Heap中使用的記憶體超過了soft limit值時，就會在一次clean up執行完畢後在應用允許的GC暫停時間範圍內儘快的執行此步驟；
在pure方式下，G1將marking與clean up組成一個環，以便clean up能充分的使用marking的資訊，當clean up開始回收時，首先回收能夠帶來最多記憶體空間的regions，當經過多次的clean up，回收到沒多少空間的regions時，G1重新初始化一個新的marking與clean up構成的環。
併發標記（Concurrent Marking）
按照之前Initial Marking掃描到的物件進行遍歷，以識別這些物件的下層物件的活躍狀態，對於在此期間應用執行緒併發修改的物件的以來關係則記錄到remembered set logs中，新建立的物件則放入比top值更高的地址區間中，這些新建立的物件預設狀態即為活躍的，同時修改top值。
最終標記暫停（Final Marking Pause）
當應用執行緒的remembered set logs未滿時，是不會放入filled RS buffers中的，在這樣的情況下，這些remebered set logs中記錄的card的修改就會被更新了，因此需要這一步，這一步要做的就是把應用執行緒中存在的remembered set logs的內容進行處理，並相應的修改remembered sets，這一步需要暫停應用，並行的執行。
存活物件計算及清除（Live Data Counting and Cleanup）
值得注意的是，在G1中，並不是說Final Marking Pause執行完了，就肯定執行Cleanup這步的，由於這步需要暫停應用，G1為了能夠達到準實時的要求，需要根據使用者指定的最大的GC造成的暫停時間來合理的規劃什麼時候執行Cleanup，另外還有幾種情況也是會觸發這個步驟的執行的：
G1採用的是複製方法來進行收集，必須保證每次的”to space”的空間都是夠的，因此G1採取的策略是當已經使用的記憶體空間達到了H時，就執行Cleanup這個步驟；
對於full-young和partially-young的分代模式的G1而言，則還有情況會觸發Cleanup的執行，full-young模式下，G1根據應用可接受的暫停時間、回收young regions需要消耗的時間來估算出一個yound regions的數量值，當JVM中分配物件的young regions的數量達到此值時，Cleanup就會執行；partially-young模式下，則會盡量頻繁的在應用可接受的暫停時間範圍內執行Cleanup，並最大限度的去執行non-young regions的Cleanup。
展望
以後JVM的調優或許跟多需要針對G1演算法進行調優了。
JVM調優工具
Jconsole，jProfile，VisualVM
Jconsole : jdk自帶，功能簡單，但是可以在系統有一定負荷的情況下使用。對垃圾回收演算法有很詳細的跟蹤。
JProfiler：商業軟體，需要付費。功能強大。
VisualVM：JDK自帶，功能強大，與JProfiler類似。推薦。
如何調優
觀察記憶體釋放情況、集合類檢查、物件樹
上面這些調優工具都提供了強大的功能，但是總的來說一般分為以下幾類功能
堆資訊檢視
可檢視堆空間大小分配（年輕代、年老代、持久代分配）
提供即時的垃圾回收功能
垃圾監控（長時間監控回收情況）
檢視堆內類、物件資訊檢視：數量、型別等
物件引用情況檢視
有了堆資訊檢視方面的功能，我們一般可以順利解決以下問題：
- 年老代年輕代大小劃分是否合理
- 記憶體洩漏
- 垃圾回收演算法設定是否合理
執行緒監控
執行緒資訊監控：系統執行緒數量。
執行緒狀態監控：各個執行緒都處在什麼樣的狀態下
Dump執行緒詳細資訊：檢視執行緒內部執行情況
死鎖檢查
熱點分析
CPU熱點：檢查系統哪些方法佔用的大量CPU時間
記憶體熱點：檢查哪些物件在系統中數量最大（一定時間記憶體活物件和銷燬物件一起統計）
這兩個東西對於系統優化很有幫助。我們可以根據找到的熱點，有針對性的進行系統的瓶頸查詢和進行系統優化，而不是漫無目的的進行所有程式碼的優化。
快照
快照是系統執行到某一時刻的一個定格。在我們進行調優的時候，不可能用眼睛去跟蹤所有系統變化，依賴快照功能，我們就可以進行系統兩個不同執行時刻，物件（或類、執行緒等）的不同，以便快速找到問題
舉例說，我要檢查系統進行垃圾回收以後，是否還有該收回的物件被遺漏下來的了。那麼，我可以在進行垃圾回收前後，分別進行一次堆情況的快照，然後對比兩次快照的物件情況。
記憶體洩漏檢查
記憶體洩漏是比較常見的問題，而且解決方法也比較通用，這裡可以重點說一下，而執行緒、熱點方面的問題則是具體問題具體分析了。
記憶體洩漏一般可以理解為系統資源（各方面的資源，堆、棧、執行緒等）在錯誤使用的情況下，導致使用完畢的資源無法回收（或沒有回收），從而導致新的資源分配請求無法完成，引起系統錯誤。
記憶體洩漏對系統危害比較大，因為他可以直接導致系統的崩潰。
需要區別一下，記憶體洩漏和系統超負荷兩者是有區別的，雖然可能導致的最終結果是一樣的。記憶體洩漏是用完的資源沒有回收引起錯誤，而系統超負荷則是系統確實沒有那麼多資源可以分配了（其他的資源都在使用）。
年老代堆空間被佔滿
異常： java.lang.OutOfMemoryError: Java heap space
說明：
這是最典型的記憶體洩漏方式，簡單說就是所有堆空間都被無法回收的垃圾物件佔滿，虛擬機器無法再在分配新空間。
如上圖所示，這是非常典型的記憶體洩漏的垃圾回收情況圖。所有峰值部分都是一次垃圾回收點，所有谷底部分表示是一次垃圾回收後剩餘的記憶體。連線所有谷底的點，可以發現一條由底到高的線，這說明，隨時間的推移，系統的堆空間被不斷佔滿，最終會佔滿整個堆空間。因此可以初步認為系統內部可能有記憶體洩漏。（上面的圖僅供示例，在實際情況下收集資料的時間需要更長，比如幾個小時或者幾天）
解決：
這種方式解決起來也比較容易，一般就是根據垃圾回收前後情況對比，同時根據物件引用情況（常見的集合物件引用）分析，基本都可以找到洩漏點。
持久代被佔滿
異常：java.lang.OutOfMemoryError: PermGen space
說明：
Perm空間被佔滿。無法為新的class分配儲存空間而引發的異常。這個異常以前是沒有的，但是在Java反射大量使用的今天這個異常比較常見了。主要原因就是大量動態反射生成的類不斷被載入，最終導致Perm區被佔滿。
更可怕的是，不同的classLoader即便使用了相同的類，但是都會對其進行載入，相當於同一個東西，如果有N個classLoader那麼他將會被載入N次。因此，某些情況下，這個問題基本視為無解。當然，存在大量classLoader和大量反射類的情況其實也不多。
解決：
- -XX:MaxPermSize=16m
- 換用JDK。比如JRocket。
堆疊溢位
異常：java.lang.StackOverflowError
說明：這個就不多說了，一般就是遞迴沒返回，或者迴圈呼叫造成
執行緒堆疊滿
異常：Fatal: Stack size too small
說明：java中一個執行緒的空間大小是有限制的。JDK5.0以後這個值是1M。與這個執行緒相關的資料將會儲存在其中。但是當執行緒空間滿了以後，將會出現上面異常。
解決：增加執行緒棧大小。-Xss2m。但這個配置無法解決根本問題，還要看程式碼部分是否有造成洩漏的部分。
系統記憶體被佔滿
異常：java.lang.OutOfMemoryError: unable to create new native thread
說明：
這個異常是由於作業系統沒有足夠的資源來產生這個執行緒造成的。系統建立執行緒時，除了要在Java堆中分配記憶體外，作業系統本身也需要分配資源來建立執行緒。因此，當執行緒數量大到一定程度以後，堆中或許還有空間，但是作業系統分配不出資源來了，就出現這個異常了。
分配給Java虛擬機器的記憶體愈多，系統剩餘的資源就越少，因此，當系統記憶體固定時，分配給Java虛擬機器的記憶體越多，那麼，系統總共能夠產生的執行緒也就越少，兩者成反比的關係。同時，可以通過修改-Xss來減少分配給單個執行緒的空間，也可以增加系統總共內生產的執行緒數。
解決：
- 重新設計系統減少執行緒數量。
- 執行緒數量不能減少的情況下，通過-Xss減小單個執行緒大小。以便能生產更多的執行緒。
垃圾回收的悖論
所謂“成也蕭何敗蕭何”。Java的垃圾回收確實帶來了很多好處，為開發帶來了便利。但是在一些高效能、高併發的情況下，垃圾回收確成為了制約Java應用的瓶頸。目前JDK的垃圾回收演算法，始終無法解決垃圾回收時的暫停問題，因為這個暫停嚴重影響了程式的相應時間，造成擁塞或堆積。這也是後續JDK增加G1演算法的一個重要原因。
當然，上面是從技術角度出發解決垃圾回收帶來的問題，但是從系統設計方面我們就需要問一下了：
我們需要分配如此大的記憶體空間給應用嗎？
我們是否能夠通過有效使用記憶體而不是通過擴大記憶體的方式來設計我們的系統呢？
我們的記憶體中都放了什麼
記憶體中需要放什麼呢？個人認為，記憶體中需要放的是你的應用需要在不久的將來再次用到到的東西。想想看，如果你在將來不用這些東西，何必放記憶體呢？放檔案、資料庫不是更好？這些東西一般包括：
- 系統執行時業務相關的資料。比如web應用中的session、即時訊息的session等。這些資料一般在一個使用者訪問週期或者一個使用過程中都需要存在。
- 快取。快取就比較多了，你所要快速訪問的都可以放這裡面。其實上面的業務資料也可以理解為一種快取。
- 執行緒。
因此，我們是不是可以這麼認為，如果我們不把業務資料和快取放在JVM中，或者把他們獨立出來，那麼Java應用使用時所需的記憶體將會大大減少，同時垃圾回收時間也會相應減少。
我認為這是可能的。
解決之道
資料庫、檔案系統
把所有資料都放入資料庫或者檔案系統，這是一種最為簡單的方式。在這種方式下，Java應用的記憶體基本上等於處理一次峰值併發請求所需的記憶體。資料的獲取都在每次請求時從資料庫和檔案系統中獲取。也可以理解為，一次業務訪問以後，所有物件都可以進行回收了。
這是一種記憶體使用最有效的方式，但是從應用角度來說，這種方式很低效。
記憶體-硬碟對映
上面的問題是因為我們使用了檔案系統帶來了低效。但是如果我們不是讀寫硬碟，而是寫記憶體的話效率將會提高很多。
資料庫和檔案系統都是實實在在進行了持久化，但是當我們並不需要這樣持久化的時候，我們可以做一些變通——把記憶體當硬碟使。
記憶體-硬碟對映很好很強大，既用了快取又對Java應用的記憶體使用又沒有影響。Java應用還是Java應用，他只知道讀寫的還是檔案，但是實際上是記憶體。
這種方式兼得的Java應用與快取兩方面的好處。memcached的廣泛使用也正是這一類的代表。
同一機器部署多個JVM
這也是一種很好的方式，可以分為縱拆和橫拆。縱拆可以理解為把Java應用劃分為不同模組，各個模組使用一個獨立的Java程序。而橫拆則是同樣功能的應用部署多個JVM。
通過部署多個JVM，可以把每個JVM的記憶體控制一個垃圾回收可以忍受的範圍內即可。但是這相當於進行了分散式的處理，其額外帶來的複雜性也是需要評估的。另外，也有支援分散式的這種JVM可以考慮，不要要錢哦：）
程式控制的物件生命週期
這種方式是理想當中的方式，目前的虛擬機器還沒有，純屬假設。即：考慮由程式設計方式配置哪些物件在垃圾收集過程中可以直接跳過，減少垃圾回收執行緒遍歷標記的時間。
這種方式相當於在程式設計的時候告訴虛擬機器某些物件你可以在*時間後在進行收集或者由程式碼標識可以收集了（類似C、C++），在這之前你即便去遍歷他也是沒有效果的，他肯定是還在被引用的。
這種方式如果JVM可以實現，個人認為將是一個飛躍，Java即有了垃圾回收的優勢，又有了C、C++對記憶體的可控性。
執行緒分配
Java的阻塞式的執行緒模型基本上可以拋棄了，目前成熟的NIO框架也比較多了。阻塞式IO帶來的問題是執行緒數量的線性增長，而NIO則可以轉換成為常數執行緒。因此，對於服務端的應用而言，NIO還是唯一選擇。不過，JDK7中為我們帶來的AIO是否能讓人眼前一亮呢？我們拭目以待。
其他的JDK
本文說的都是Sun的JDK，目前常見的JDK還有JRocket和IBM的JDK。其中JRocket在IO方面比Sun的高很多，不過Sun JDK6.0以後提高也很大。而且JRocket在垃圾回收方面，也具有優勢，其可設定垃圾回收的最大暫停時間也是很吸引人的。不過，系統Sun的G1實現以後，在這方面會有一個質的飛躍。
能整理出上面一些東西，也是因為站在巨人的肩上。下面是一些參考資料，供大家學習，大家有更好的，可以繼續完善：）
· [Java 理論與實踐: 垃圾收集簡史][Java _]
· 《深入Java虛擬機器》。雖然過去了很多年，但這本書依舊是經典。
這裡是本系列的最後一篇了，很高興大家能夠喜歡這系列的文章。期間也提了很多問題，其中有些是我之前沒有想到的或者考慮欠妥的，感謝提出這些問題的朋友，我也學到的不少東西。
關注公眾號:java寶典