JVM之垃圾回收

对象的软、弱和虚引用

1：强引用（StrongReference）
这是Java程序中最常见的引用方式。程序创建一个对象，并把这个对象赋给一个引用变量，程序通过该引用变量来操作实际的对象。当一个对象被一个或一个以上的引用变量所引用时，它处于可达状态，不可能被系统垃圾回收机制回收；

2：软引用（SoftReference）
软引用需要通过SoftReference类来实现，当一个对象只有软引用时，它有可能被垃圾回收机制回收。对于只有软引用的对象而言，当系统内存空间足够时，它不会被系统回收，程序也可使用该对象；当系统内存空间不足时，系统可能会回收它。软引用通常用于堆内存敏感的程序中；

弱引用（WeakReference）
弱引用通过WeakReference类实现，弱引用和软引用很像，但弱引用的引用级别更低。对于只有弱引用的对象而言，当系统垃圾回收机制运行时，不管系统内存是否足够，总会回收该对象所占的内存。当然，并不是说当一个对象只有弱引用时，它就会立即被回收----正如那些失去引用的对象一样，必须等到垃圾回收机制运行时才会被回收；

虚引用（PhantomReference）
虚引用通过PhantomReference类实现，虚引用完全类似于没有引用。虚引用对对象本身没有太大影响，对象甚至感觉不到虚引用的存在。如果一个对象只有一个虚引用时，那么它和没有引用的效果大致相同。虚引用主要用于跟踪对象被垃圾回收的状态，虚引用不能单独使用，虚引用必须和引用队列（ReferenceQueue）联合使用；

上面三个引用类都包含了一个get()方法，用于获取被它们所引用的对象；

引用队列由java.lang.ref.ReferenceQueue类表示，它用于保存被回收后对象的使用。

软引用和弱引用可以单独使用，但虚引用不能单独使用，单独使用虚引用没有太大的意义。虚引用的主要作用就是跟踪对象被垃圾回收的状态，程序可以通过检查与虚引用关联的引用队列中是否已经包含了该虚引用，从而了解虚引用所引用的对象是否立即回收；

弱引用示例：

public class TestReference
{
	public static void main(String[] args) throws Exception
	{
		//创建一个字符串对象
		String str = new String("Struts2权威指南");
		//创建一个弱引用，让此弱引用引用到"Struts2权威指南"字符串
		WeakReference wr = new WeakReference(str);
		//切断str引用和"Struts2权威指南"字符串之间的引用
		str = null;
		//取出弱引用所引用的对象，由于此程序不会导致内存紧张，所以通常还不会进行垃圾回收弱引用wr所引用的对象。
		System.out.println(wr.get());
		//强制垃圾回收
		System.gc();
		System.runFinalization();
		//再次取出弱引用所引用的对象
		System.out.println(wr.get());
	}
}

//输出
Struts2权威指南
null

虚引用示例：

public class TestPhantomReference
{
	public static void main(String[] args) throws Exception
	{
		//创建一个字符串对象
		String str = new String("Struts2权威指南");
		//创建一个引用队列
		ReferenceQueue rq = new ReferenceQueue();
		//创建一个虚引用，让此虚引用引用到"Struts2权威指南"字符串
		PhantomReference  pr = new PhantomReference (str , rq);
		//切断str引用和"Struts2权威指南"字符串之间的引用
		str = null;
		//取出虚引用所引用的对象，并不能通过虚引用访问被引用的对象，所以此处输出null
		System.out.println(pr.get());
		//强制垃圾回收
		System.gc();
		System.runFinalization();
		//取出引用队列中最先进入队列中引用与pr进行比较
		System.out.println(rq.poll() == pr);
	}
}
//输出
null
true

当被引用的对象回收后，对应的虚引用将被添加到关联的引用队列中，因而程序最后看到输出true；

判断对象是否属于垃圾？

垃圾收集器在对堆进行回收前，第一件事情就是确定这些对象之中哪些还“活着”，哪些已经“死去”。

引用计数算法

给对象添加一个引用计数器，每当一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减一；任何时刻计数器值为0的对象就是不可能再被使用的。
客观的说，引用计数算法的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法。但是，至少主流的Java 虚拟机里面没有选用引用计数算法来管理内存，其中主要的原因是它很难解决对象之间相互循环引用的问题。

例如：

A对象引用了B对象，B对象的引用计数为1。同时B对象也引用了A对象，那A对象的引用计数也是1。假设没有什么对象再引用A、B，因为AB两个对象的引用计数都是1，所以AB对象永远不会被垃圾回收。

可达性分析算法

在主流的商用程序语言（Java、C#）的主流实现中，都是称通过可达性分析来判定对象是否存活的。这个算法的基本思想就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。
如图3-1所示，对象 object5、 object6、 object7 虽然相互关联，但是它们到 GC Roots 是不可达的，所以它们将会被判定是可回收的对象。

在 Java 语言中，可作为 GC Roots 的对象包括以下几种：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象；
• 方法区中类静态属性引用的对象；
• 方法中区中常量引用的对象；
• 本地方法栈中 JNI （即一般说的 Native 方法）引用的对象；

便于理解的例子：葡萄，连在根上的这些葡萄就是不能被回收的对象，因为有根来引用它们。而与根断开的就是可以作为垃圾被回收的对象

扩展—查看有哪些GC Roots对象？

工具：Memory Analyzer (MAT)
地址：https://www.eclipse.org/mat/

示例代码：

/**
 * 演示GC Roots
 */
public class Demo2_2 {

    public static void main(String[] args) throws InterruptedException, IOException {
        List<Object> list1 = new ArrayList<>();
        list1.add("a");
        list1.add("b");
        System.out.println(1);
        System.in.read();

        list1 = null;
        System.out.println(2);
        System.in.read();
        System.out.println("end...");
    }
}

第一次等待输入时执行命令：
jmap -dump:format=b,live,file=1.bin [pid]

第二次等待输入时执行命令：
jmap -dump:format=b,live,file=2.bin [pid]

参数：
-dump：堆内存当前运行时的状态抓取转储为一个文件
format：转储文件的格式
b：表示二进制格式
live：抓取时只关注存活对象，并且在抓取前主动执行一次垃圾回收
file：文件生成地址

打开生成的.bin文件，如下操作查看：

垃圾回收前1.bin：

垃圾回收后2.bin：

finalize()方法

protected void finalize() throws Throwable

即使在可达性分析算法种不可达的对象，也并非是 “非死不可”的，这时候它们暂时处于“缓邢” 阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：

• 如果对象在进行可达性分析后发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize() 方法。当对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，虚拟机将这两种情况都视为 “没有必要执行”；
• 如果这个对象被判定为有必要执行 finalize() 方法，那么这个对象将会被放置在一个叫做 F-Queue 的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的 Finalizer 线程去执行它。这里所谓的 “执行” 是指虚拟机会触发这个方法，但并不承诺会等待它运行结束（这样做的原因是，如果一个对象在 finalize() 方法中执行缓慢，或者发生了死循环，将很可能会导致 F-Queue 队列中其它对象永久处于等待，甚至导致整个内存回收系统崩溃）finalize() 方法是对象逃脱死亡命运的最后一次机会，稍后 GC 将对 F-Queue 中的对象进行第二次小规模的标记，如果对象要在 finalize() 中成功拯救自己-----------只要重新与引用链上的任何一个对象建立关系即可，那在第二次标记时它将被移除出 “即将回收” 的集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了；

当finalize()方法返回后，对象消失，垃圾回收机制开始执行；

任何Java类都可以重写Object类的finalize()方法，在该方法中清理该对象占用的资源。如果程序终止之前始终没有进行垃圾回收，则不会调用失去引用对象的finalize()方法来清理资源；

垃圾回收机制何时调用对象的finalize()方法是完全透明的，只有当程序认为需要更多的额外内存时，垃圾回收机制才会进行垃圾回收。例如，某个失去引用的对象只占用了少量内存，而且系统没有产生严重的内存需求，因此垃圾回收机制并没有试图回收该对象所占用的资源，所以该对象的finalize()方法方法也不会得到调用；

finalize()方法具有如下4个特点：

• 永远不要主动调用某个对象的finalize()方法，该方法应交给垃圾回收机制调用；
• finalize()方法何时被调用，是否被调用具有不确定性，不要把finalize()方法方法当成一定会被执行的方法；
• 当JVM执行可恢复对象的finalize()方法时，可能使该对象或系统中其他对象重新变成可达状态；
• 当JVM执行finalize()方法时出现异常时，垃圾回收机制不会报告异常，程序继续执行；

public class TestFinalize
{
	private static TestFinalize tf = null;
	public void info()
	{
		System.out.println("测试资源清理的finalize方法");
	}
	public static void main(String[] args) throws Exception
	{
		//创建TestFinalize对象立即进入去活状态
		new TestFinalize();
		//通知系统进行资源回收
		System.gc();
		System.runFinalization();
		//Thread.sleep(2000);
		tf.info();
	}
	public void finalize()
	{
		//让tf引用到试图回收的去活对象，即去活对象重新变成激活
		tf = this;
	}
}

如果程序仅执行System.gc();代码，而不执行System.runFinalization();代码--------由于JVM垃圾回收机制的不确定性，JVM往往并不立即调用可恢复对象的finalize()方法，这样TestFinalize的ft类变量可能依然为null，可能依然会导致空指针异常；

回收方法区

很多人认为方法区（或者 HotSpot 虚拟机中的永久代）是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且在方法区中进行垃圾收集的 “性价比” 一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收 70%~90%的空间，而永久代的垃圾收集效率远低于此；

永久代的的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收 Java 堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串 “abc” 已经进入了常量池中，但是当前系统没有任何一个 String 对象是叫做 “abc” 的，换句话说，就是没有任何 String 对象引用常量池中的 “abc” 常量，也没有其它地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个 “abc” 常量就会被系统清理出常量池。常量池中的其它类（接口）、方法、字段的符号引用也与此类似；
判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是 “无用的类” 的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是 “无用的类”：

• 该类所有的实例都已经被回收，也就是 Java堆中不存在该类的任何实例；
• 加载该类的 ClassLoader 已经被回收；
• 该类对应的 java.lang.Class 对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法；

虚拟机可以对满足上述3个条件的无用类进行回收，这里说的仅仅是 “可以” ，而并不是和对象一样，不使用了就必然会回收。是否对类进行回收，HotSpot 虚拟机提供了 -Xnoclassgc参数进行控制；

强制垃圾回收

程序无法精确控制Java垃圾回收的时机，但依然可以强制系统进行垃圾回收----这种强制只是通知系统进行垃圾回收，但系统是否进行垃圾回收依然不确定。大部分时候，程序强制系统垃圾回收后总会有一些效果。强制系统垃圾回收有如下两种方式：

• 调用System类的gc()静态方法：System.gc()；
• 调用Runtime对象的gc()实例方法：Runtime.getRuntime().gc()；

TestGc.java

public class TestGc
{
	private double height;
	public static void main(String[] args) 
	{
		for (int i = 0 ; i < 4; i++)
		{
			new TestGc();
		}
	}
	public void finalize()
	{
		System.out.println("系统正在清理TestGc对象的资源...");
	}
}

编译、运行上面程序，看不到任何输出，可见直到系统退出，系统都不曾调用TestGc对象的finalize()方法。但将程序改为如下形式：

public class TestGc
{
	private double height;
	public static void main(String[] args) 
	{
		for (int i = 0 ; i < 4; i++)
		{
			new TestGc();
			//System.gc();
			Runtime.getRuntime().gc();
		}
	}
	public void finalize()
	{
		System.out.println("系统正在清理TestGc对象的资源...");
	}
}

//输出系统正在清理TestGc对象的资源...

可见系统垃圾回收机制还是有所动作的；

新生代、老年代、永久代

为什么需要把堆分代？-------------------分代的唯一理由就是优化GC性能。

如果没有分代，那我们所有的对象都在一块，GC的时候我们要找到哪些对象没用，这样就会对堆的所有区域进行扫描。
而我们的很多对象都是朝生夕死的，如果分代的话，我们把新创建的对象放到某一地方，
当GC的时候先把这块存“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。

• 新生代：新生代主要存放的是哪些很快就会被GC回收掉的或者不是特别大的对象；
• 老年代：老年代则是存放那些在程序中经历了好几次回收仍然还活着或者特别大的对象；
• 永久代：JVM的方法区，也被称为永久代。在这里都是放着一些被虚拟机加载的类信息，静态变量，常量等数据。这个区中的东西比老年代和新生代更不容易回收；

垃圾收集算法

标记-清除算法

最基础的收集算法是 “标记-清除”算法，如同它的名字一样，算法分为 “标记” 和 “清除” 两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
它的主要不足有两个：

• 效率问题：标记和清除两个过程的效率都不高；
• 空间问题：标记清除之后会产出大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作；

复制算法

为了解决效率问题，一种称为 “复制” 的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的空间一次清理掉。这样使得每次都是对整个半区进行垃圾回收，内存分配的时候也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。
只是这个算法的代价是将内存缩小为了原来的一半，未免太高了一点；

现在的商业虚拟机都采用这种收集算法来回收新生代，新生代中的对象 98%是朝生夕死的，所以并不需要按照 1：1 的比例来划分内存空间，而是将内存划分为一块较大的 Eden（伊甸园） 空间和两块较小的 Survivor （幸存区）空间，每次使用 Eden 和其中一块 Survivor。当回收时，将 Eden 和 Survivor 中还存活着的对象一次性复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8 ：1 ，也就是每次新生代中可用内存空间为整个新生代容量的 90%（80% + 10%），只有10% 的内存会被 “浪费”;

标记-整理算法

复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费 50% 的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法；

根据老年代的特点，有人提出了另一种 “标记-整理” 算法，标记过程仍然与 “标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

分代收集算法

当前商业虚拟机的垃圾收集都采用 "分代收集"算法，根据对象存活周期的不同将内存划分为几块。一般把 Java 堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。

• 新生代（复制算法）：在新生代中，每次垃圾收集时都发现有大批对象死去，只要少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集；
• 老年代（标记–清除或者标记–整理算法）：老年代中对象存活率较高、没有额外空间对它进行分配担保，就必须使用标记–清除或者标记–整理算法来进行回收；

相关 VM 参数

作用	参数
堆初始大小	-Xms
堆最大大小	-Xmx 或 -XX:MaxHeapSize=size
新生代大小	-Xmn 或 (-XX:NewSize=size + -XX:MaxNewSize=size )
幸存区比例（动态）	-XX:InitialSurvivorRatio=ratio 和 -XX:+UseAdaptiveSizePolicy
幸存区比例	-XX:SurvivorRatio=ratio
晋升阈值	-XX:MaxTenuringThreshold=threshold
晋升详情	-XX:+PrintTenuringDistribution
GC详情	-XX:+PrintGCDetails -verbose:gc
FullGC 前 MinorGC	-XX:+ScavengeBeforeFullGC

垃圾收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现；

垃圾收集器分为三类：

串行

• 单线程；
• 适合场景堆内存较小，适合个人电脑；

吞吐量优先

• 多线程；
• 适合场景堆内存较大，多核 cpu；
• 尽可能让单位时间内STW 的时间最短；垃圾回收时间占比最低，这样就称吞吐量高

响用时间优先

• 多线程；
• 适合场景堆内存较大，多核 cpu；
• 尽可能让单次 STW 的时间最短；（单位时间内可能会发生多次垃圾回收）

STW 是什么？
Java中Stop-The-World机制简称STW，是在执行垃圾收集算法时，Java应用程序的其他所有线程都被挂起（除了垃圾收集帮助器之外）。

Java中一种全局暂停现象，全局停顿，所有Java代码停止，native代码可以执行，但不能与JVM交互；这些现象多半是由于gc引起。

图3-5展示了 7 种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。

串行与并行的区别

再接用知乎上的回答，比较好理解些：

Serial收集器、Serial Old 收集器----串行（单线程）

Serial翻译过来就是串行的意思；

Serial收集器是最基本、发展历史最悠久的收集器。Serial Old 是 Serial 收集器的老年代版本。

//可以在启动时vm参数添加指定收集器
 -XX:+UseSerialGC = Serial + SerialOld

总结：

• Serial：工作在新生代，采用的是复制算法
• SerialOld：工作在老年代，采用的是标记整理算法
• 垃圾回收的时候此线程不阻塞，其他线程都处于阻塞状态

Parallel Scavenge 收集器、Parallel Old 收集器----吞吐量优先（并行多线程）

Parallel翻译过来就是并行的意思；

并发与并行的区别：

知乎这个例子也挺好理解的：

所谓吞吐量就是CPU 用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间），虚拟机总共运行了 100 分钟，其中垃圾收集花了 1 分钟，那吞吐量就是 99%；

总结：

• Parallel Scavenge ：是一个新生代收集器，使用复制算法的收集器
• Parallel Old ：是 Parallel Scavenge 收集器的老年代版本，使用“标记–整理”算法。这个收集器是在 JDK1.6中才开始提供的。

CMS（Concurrent Mark Sweep）收集器、ParNew收集器----响应时间优先

Concurrent翻译过来就是并发的意思；

从名字来看（Mark Sweep）上就可以看出，CMS收集器是基于 “标记–清除”算法实现的，它的运作过程相对于前面几种更复杂一些，整个过程分为4个步骤，包括：

• 初始标记（CMS initial mark）
• 并发标记（CMS concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS concurrent sweep）

其中，初始标记、重新标记这两个步骤仍然需要 暂停用户线程。初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，并发标记阶段就是进行 GC Roots Tracing 的过程，而重新标记阶段是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短；

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

但CMS还远达不到完美的程度，它有以下 3 个明显的缺点：

• CMS收集器对CPU资源非常敏感；
• CMS收集器无法处理浮动垃圾，可能出现 Concurrent Mode Failure 失败而导致另一次 Full GC 的产生；
• CMS收集器是基于 “标记–清除”算法实现的收集器，可能会产生大量空间碎片。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次 Full GC。

ParNew收集器其实就是 Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余行为都一样。在实际上，这两种收集器也共用了相当多的代码，除了Serial收集器外，目前只有它能与CMS收集器配合工作。

G1 收集器

G1（Garbage-First）收集器是当今收集技术发展的最前沿成果之一。与其它 GC 收集器相比，G1具备如下特点：

• 并行与并发
• 分代收集
• 空间整合
• 可预测的停顿

查看当前java版本使用的垃圾收集器

cmd命令输入：

java -XX:+PrintCommandLineFlags -version

内存分配与回收策略

对象优先在Eden分配

大多数情况下，对象在新生代 Eden 区中分配；

大对象直接进入老年代

所谓的大对象是指，需要大量连续内存空间的 Java 对象，最典型的大对象就是那种很长的字符串以及数组。大对象对虚拟机的内存分配来说就是一个坏消息（比遇到一个大对象更加坏的消息就是遇到一群“朝生夕灭”的“短命大对象”）经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集器以获得足够的连续空间来安置它们；

长期存活的对象将进入老年代

虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在 Ebden出生并经过第一次 Minor GC 后仍然存活，并且能被 Survivor容纳的话，将被移动到 Survivor 空间中，并且对象年龄设为1.对象在 Survivor 区中每“熬过” 一次 Minor GC ，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就会被晋升到老年代中，对象晋升老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold设置；

动态对象年龄判定

为了更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了 MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 空间中相同年龄所有对象大小的总合大于 Survivor 空间的一般，年龄大于或等于该年龄的对象就可以直接进入老年代，无需等到 MaxTenuringThreshold 中要求的年龄；

以上都是学习所做的笔记，以供日后没事可以看看，复习复习；
书籍：深入理解 Java 虚拟机 JVM高级特性与最佳实践-------周志明著 ；