在Java中，它的記憶體管理包括兩方面：記憶體分配（建立Java物件的時候）和記憶體回收，這兩方面工作都是由JVM自動完成的，降低了Java程式設計師的學習難度，避免了像C/C++直接操作記憶體的危險。但是，也正因為記憶體管理完全由JVM負責，所以也使Java很多程式設計師不再關心記憶體分配，導致很多程式低效，耗記憶體。因此就有了Java程式設計師到最後應該去了解JVM，才能寫出更高效，充分利用有限的記憶體的程式。
1.Java在記憶體中的狀態
首先我們先寫一個程式碼為例子：
Person.java
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
package test; import java.io.Serializable; public class Person implements Serializable { static final long serialVersionUID = 1L; String name; // 姓名 Person friend; //朋友 public Person() {} public Person(String name) { super(); this.name = name; } } |
Test.java
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
package test; public class Test{ public static void main(String[] args) { Person p1 = new Person("Kevin"); Person p2 = new Person("Rain"); Person p3 = new Person("Sunny"); p1.friend = p2; p3 = p2; p2 = null; } } |
把上面Test.java中main方面裡面的物件引用畫成一個從main方法開始的物件引用圖的話就是這樣的（頂點是物件和引用，有向邊是引用關係）：
當程式執行起來之後，把它在記憶體中的狀態看成是有向圖後，可以分為三種：
1）可達狀態：在一個物件建立後，有一個以上的引用變數引用它。在有向圖中可以從起始頂點導航到該物件，那它就處於可達狀態。
2）可恢復狀態：如果程式中某個物件不再有任何的引用變數引用它，它將先進入可恢復狀態，此時從有向圖的起始頂點不能再導航到該物件。在這個狀態下，系統的垃圾回收機制準備回收該物件的所佔用的記憶體，在回收之前，系統會呼叫finalize()方法進行資源清理，如果資源整理後重新讓一個以上引用變數引用該物件，則這個物件會再次變為可達狀態；否則就會進入不可達狀態。
3）不可達狀態：當物件的所有關聯都被切斷，且系統呼叫finalize()方法進行資源清理後依舊沒有使該物件變為可達狀態，則這個物件將永久性失去引用並且變成不可達狀態，系統才會真正的去回收該物件所佔用的資源。
上述三種狀態的轉換圖如下：
2.Java對物件的4種引用
1）強引用 ：建立一個物件並把這個物件直接賦給一個變數，eg ：Person person = new Person(“sunny”); 不管系統資源有麼的緊張，強引用的物件都絕對不會被回收，即使他以後不會再用到。
2）軟引用 ：通過SoftReference類實現，eg : SoftReference<Person> p = new SoftReference<Person>(new Person(“Rain”));,記憶體非常緊張的時候會被回收，其他時候不會被回收，所以在使用之前要判斷是否為null從而判斷他是否已經被回收了。
3）弱引用 ：通過WeakReference類實現，eg : WeakReference<Person> p = new WeakReference<Person>(new Person(“Rain”));不管記憶體是否足夠，系統垃圾回收時必定會回收。
4）虛引用 ：不能單獨使用，主要是用於追蹤物件被垃圾回收的狀態。通過PhantomReference類和引用佇列ReferenceQueue類聯合使用實現，eg ：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
package test; import java.lang.ref.PhantomReference; import java.lang.ref.ReferenceQueue; public class Test{ public static void main(String[] args) { //建立一個物件 Person person = new Person("Sunny"); //建立一個引用佇列 ReferenceQueue<Person> rq = new ReferenceQueue<Person>(); //建立一個虛引用，讓此虛引用引用到person物件 PhantomReference<Person> pr = new PhantomReference<Person>(person, rq); //切斷person引用變數和物件的引用 person = null; //試圖取出虛引用所引用的物件 //發現程式並不能通過虛引用訪問被引用物件，所以此處輸出為null System.out.println(pr.get()); //強制垃圾回收 System.gc(); System.runFinalization(); //因為一旦虛引用中的物件被回收後，該虛引用就會進入引用佇列中 //所以用佇列中最先進入佇列中引用與pr進行比較，輸出true System.out.println(rq.poll() == pr); } } |
執行結果：
3.Java垃圾回收機制
其實Java垃圾回收主要做的是兩件事：1）記憶體回收 2）碎片整理
3.1垃圾回收演算法
1）序列回收（只用一個CPU）和並行回收（多個CPU才有用）：序列回收是不管系統有多少個CPU，始終只用一個CPU來執行垃圾回收操作，而並行回收就是把整個回收工作拆分成多個部分，每個部分由一個CPU負責，從而讓多個CPU並行回收。並行回收的執行效率很高，但複雜度增加，另外也有一些副作用，如記憶體隨便增加。
2）併發執行和應用程式停止 ：應用程式停止（Stop-the-world）顧名思義，其垃圾回收方式在執行垃圾回收的同時會導致應用程式的暫停。併發執行的垃圾回收雖然不會導致應用程式的暫停，但由於併發執行垃圾需要解決和應用程式的執行衝突（應用程式可能在垃圾回收的過程修改物件），因此併發執行垃圾回收的系統開銷比Stop-the-world高，而且執行時需要更多的堆記憶體。
3）壓縮和不壓縮和複製 ：
①支援壓縮的垃圾回收器（標記-壓縮 = 標記清除+壓縮）會把所有的可達物件搬遷到一起，然後將之前佔用的記憶體全部回收，減少了記憶體碎片。
②不壓縮的垃圾回收器（標記-清除）要遍歷兩次，第一次先從跟開始訪問所有可達物件，並將他們標記為可達狀態，第二次便利整個記憶體區域，對未標記可達狀態的物件進行回收處理。這種回收方式不壓縮，不需要額外記憶體，但要兩次遍歷，會產生碎片
③複製式的垃圾回收器：將堆記憶體分成兩個相同空間，從根（類似於前面的有向圖起始頂點）開始訪問每一個關聯的可達物件，將空間A的全部可達物件複製到空間B，然後一次性回收空間A。對於該演算法而言，因為只需訪問所有的可達物件，將所有的可達物件複製走之後就直接回收整個空間，完全不用理會不可達物件，所以遍歷空間的成本較小，但需要巨大的複製成本和較多的記憶體。
3.2堆記憶體的分代回收
1）分代回收的依據：
①物件生存時間的長短：大部分物件在Young期間就被回收
②不同代採取不同的垃圾回收策略：新（生存時間短）老（生存時間長）物件之間很少存在引用
2) 堆記憶體的分代：
①Young代 ：
Ⅰ回收機制 ：因為物件數量少，所以採用複製回收。
Ⅱ組成區域 ：由1個Eden區和2個Survivor區構成，同一時間的兩個Survivor區，一個用來儲存物件，另一個是空的；每次進行Young代垃圾回收的時候，就把Eden，From中的可達物件複製到To區域中，一些生存時間長的就複製到了老年代，接著清除Eden，From空間，最後原來的To空間變為From空間，原來的From空間變為To空間。
Ⅲ物件來源 ：絕大多數物件先分配到Eden區，一些大的物件會直接被分配到Old代中。
Ⅳ回收頻率 ：因為Young代物件大部分很快進入不可達狀態，因此回收頻率高且回收速度快
②Old代 ：
Ⅰ回收機制 ：採用標記壓縮演算法回收。
Ⅱ物件來源 ：1.物件大直接進入老年代。
2.Young代中生存時間長的可達物件
Ⅲ回收頻率 ：因為很少物件會死掉，所以執行頻率不高，而且需要較長時間來完成。
③Permanent代 ：
Ⅰ用 途 ：用來裝載Class，方法等資訊，預設為64M，不會被回收
Ⅱ物件來源 ：eg：對於像Hibernate，Spring這類喜歡AOP動態生成類的框架，往往會生成大量的動態代理類，因此需要更多的Permanent代記憶體。所以我們經常在除錯Hibernate，Spring的時候經常遇到java.lang.OutOfMemoryError:PermGen space的錯誤，這就是Permanent代記憶體耗盡所導致的錯誤。
Ⅲ回收頻率 ：不會被回收
3.3常見的垃圾回收器
1）序列回收器（只使用一個CPU）：Young代採用序列復制演算法；Old代使用序列標記壓縮演算法（三個階段：標記mark—清除sweep—壓縮compact），回收期間程式會產生暫停，
2）並行回收器：對Young代採用的演算法和序列回收器一樣，只是增加了多CPU並行處理； 對Old代的處理和序列回收器完全一樣，依舊是單執行緒。
3）並行壓縮回收器：對Young代處理採用與並行回收器完全一樣的演算法；只是對Old代採用了不同的演算法，其實就是劃分不同的區域，然後進行標記壓縮演算法：
① 將Old代劃分成幾個固定區域；
② mark階段（多執行緒並行），標記可達物件；
③ summary階段（序列執行），從最左邊開始檢驗知道找到某個達到數值（可達物件密度小）的區域時，此區域及其右邊區域進行壓縮回收，其左端為密集區域
④ compact階段（多執行緒並行），識別出需要裝填的區域，多執行緒並行的把資料複製到這些區域中。經此過程後，Old代一端密集存在大量活動物件，另一端則存在大塊空間。
4）併發標識—清理回收（CMS）：對Young代處理採用與並行回收器完全一樣的演算法；只是對Old代採用了不同的演算法，但歸根待地還是標記清理演算法：
① 初始標識（程式暫停）：標記被直接引用的物件(一級物件)；
② 併發標識（程式執行）：通過一級物件尋找其他可達物件；
③ 再標記（程式暫停）：多執行緒並行的重新標記之前可能因為併發而漏掉的物件（簡單的說就是防遺漏）
④ 併發清理（程式執行）
4.記憶體管理小技巧
1）儘量使用直接量，eg：String javaStr = “小學徒的成長曆程”;
2）使用StringBuilder和StringBuffer進行字串連線等操作;
3）儘早釋放無用物件;
4）儘量少使用靜態變數;
5）快取常用的物件:可以使用開源的開源快取實現，eg：OSCache，Ehcache;
6）儘量不使用finalize()方法;
7）在必要的時候可以考慮使用軟引用SoftReference。