垃圾回收是Java最大的特點之一，由于垃圾回收是java虛擬機自動進行，在代碼開發中不用去管理垃圾什么時候回收。而且現在集群部署及機器物理內存可擴增，內存問題在很多開發場景都被忽略，都是讓Java虛擬機自己管理。
怎么確定一個對象可以被回收
最主要的兩個垃圾回收算法就是引用計數和跟蹤搜索算法，引用計數算法就是給對象添加一個計數器，當被引用時就加1，引用失效時就減1，在任何情況下都為0時，該對象就可以被回收；但這種算法難以解決對象環狀循環引用的問題。
跟蹤搜索算法在《深入理解Java虛擬機》書中定義為：通過一系列命名為“GC Root”的節點向下搜索，當一個對象到“GC Root”節點沒有任何引用，即到“GC Root”節點不可達，則該對象就可以被回收。
"GC Root”節點定義
- 虛擬機棧（棧幀中的本地變量表）中的引用的對象。
- 方法區中的類靜態屬性引用的對象。
- 方法區中的常量引用的對象。
- 本地方法棧中JNI（即一般說的Native方法）的引用的對象。
垃圾回收方式
標記清除算法（Mark-Sweep）
顧名思義，先將需要回收的對象進行一一標記，完成之后進行統一的回收。這是最基本垃圾回收算法，但是在最初標記的時候以及清除垃圾的時候效率都不高，并且在清除后以前被占用的內存就變成了不連續的內存碎片，在存放大對象時很可以為因為連續的內存不夠而引發Full GC。
復制算法
復制算法為了解決效率，將內存劃分為相同的兩快，每次存放時只存放一邊，內存滿了之后就將存貨的復制到另一邊，然后對剩下的進行垃圾清理，每次回收時只用移動對象內存指針，按照順序分配，且不用考慮內存碎片的問題，簡單高效。現在的分代收集算法中新生代基本就是按照這種算法實現。但對存放時間長的對象，每次就要進行多次復制，而且還需要額外的空間擔保，所以并不適用于老年代。
標記整理算法
與標記清楚算法前部分一樣，在清理對象時，將存活的對象移動并按順序排列，完成后將存貨對象界限意外的刪除，這種多用于老年代收集。
分代收集算法
將內存根據對象不同的生命周期劃分為幾塊，一般分為新生代、老年代、持久區等，然后每個分區選擇當前最合適的垃圾回收算法。
垃圾回收測試
在單元測試的run configuration 中添加：
-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+PrintGCTimeStamps
意思是運行的初始和最大內存為jvm20m，新生代使用10m。-XX:SurvivorRatio=8 表示新生代中eden和survivor的比例，由于survivor是同時存在2個，所以為8:1:1，-XX:+PrintGCDetails打印GC日志， -XX:+PrintGCTimeStamps 打印時間
測試代碼
public class JavaOOMError {
private static byte[] bts = null;
public static void init(){
bts = new byte[3 * 1024 * 1024];
}
public static void main(String[] args) {
init();
byte[] bts1 = new byte[1 * 1024 * 1024];
System.out.println("-----" + 1);
byte[] bts2 = new byte[2 * 1024 * 1024];
System.out.println("-----" + 2);
byte[] bts3 = new byte[3 * 1024 * 1024];
System.out.println("-----" + 3);
byte[] bts4 = new byte[4 * 1024 * 1024];
System.out.println("-----" + 4);
byte[] bts5 = new byte[5 * 1024 * 1024];
System.out.println("-----" + 5);
}
}
運行結果
-----1
-----2
0.644: [GC (Allocation Failure) 0.645: [DefNew: 6807K->482K(9216K), 0.0102920 secs] 6807K->6626K(19456K), 0.0109738 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
-----3
-----4
0.658: [GC (Allocation Failure) 0.658: [DefNew: 7812K->7812K(9216K), 0.0000349 secs]0.658: [Tenured: 6144K->9216K(10240K), 0.0090041 secs] 13956K->13793K(19456K), [Metaspace: 1636K->1636K(4480K)], 0.0095951 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
0.667: [Full GC (Allocation Failure) 0.667: [Tenured: 9216K->9216K(10240K), 0.0030476 secs] 13793K->13782K(19456K), [Metaspace: 1636K->1636K(4480K)], 0.0031219 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.test.gc.JavaOOMError.main(JavaOOMError.java:51)
Heap
def new generation total 9216K, used 4893K [0x03e00000, 0x04800000, 0x04800000)
eden space 8192K, 59% used [0x03e00000, 0x042c7458, 0x04600000)
from space 1024K, 0% used [0x04700000, 0x04700000, 0x04800000)
to space 1024K, 0% used [0x04600000, 0x04600000, 0x04700000)
tenured generation total 10240K, used 9216K [0x04800000, 0x05200000, 0x05200000)
the space 10240K, 90% used [0x04800000, 0x05100090, 0x05100200, 0x05200000)
Metaspace used 1654K, capacity 2242K, committed 2368K, reserved 4480K
在打印3前新生代執行一次Minor GC，由于初始化的靜態變量占了3M，后面用
new了1和2 共3M對象，所以第三次執行新生代剩余的不足2M，后面的在new一個3M大對象無法存放時，就會執行一次垃圾會后，回收后新生代空間6807K->482K(9216K），之前的6m就被放到老年代（之所以不能被清除，是因為所有的對象根據跟蹤搜索算法還存在）；在3和4被執行后，執行5時，由于此時5的需要的空間為5M，新生代已被占用7M，空間不足，會執行垃圾回收，執行minor GC后，將3放到老年代中
Tenured: 6144K->9216K(10240K)，但是新生代發現內存還是不夠，執行Full GC，最后還是沒有可連續的5M內存空間，就只能報OutOfMemoryError: Java heap space異常。從上面可以看出，java垃圾回收的一個具體信息，在上面代碼中，如果添加
bts4 = null;再次執行
添加位置如下
System.out.println("-----" + 4);
bts4 = null;
byte[] bts5 = new byte[5 * 1024 * 1024];
運行結果：
-----1
-----2
0.757: [GC (Allocation Failure) 0.758: [DefNew: 6807K->482K(9216K), 0.0059942 secs] 6807K->6626K(19456K), 0.0066999 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
-----3
-----4
0.765: [GC (Allocation Failure) 0.765: [DefNew: 7812K->7812K(9216K), 0.0000312 secs]0.765: [Tenured: 6144K->9697K(10240K), 0.0050508 secs] 13956K->9697K(19456K), [Metaspace: 1636K->1636K(4480K)], 0.0051905 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
-----5
Heap
def new generation total 9216K, used 5446K [0x03e00000, 0x04800000, 0x04800000)
eden space 8192K, 66% used [0x03e00000, 0x04351af0, 0x04600000)
from space 1024K, 0% used [0x04700000, 0x04700000, 0x04800000)
to space 1024K, 0% used [0x04600000, 0x04600000, 0x04700000)
tenured generation total 10240K, used 9697K [0x04800000, 0x05200000, 0x05200000)
the space 10240K, 94% used [0x04800000, 0x05178440, 0x05178600, 0x05200000)
Metaspace used 1640K, capacity 2242K, committed 2368K, reserved 4480K
此次執行并沒有報出異常，主要在放入4后，執行5時，內存不夠執行垃圾回收，由于此時4已經屬于不存活對象，被回收掉，3轉到了老年代；此時新生代的空間足夠放入5，所以并不會執行Full GC。
