Java GC系列：Java垃圾回收详解
Java的内存分配与回收全部由JVM垃圾回收进程自动完成。与C语言不同，Java开发者不需要自己编写代码实现垃圾回收。这是Java深受大家欢迎的众多特性之一，能够帮助程序员更好地编写Java程序。
下面四篇教程是了解Java 垃圾回收（GC）的基础：
- 垃圾回收简介
- 圾回收是如何工作的？
- 垃圾回收的类别
-
垃圾回收监视和分析
这篇教程是系列第一部分。首先会解释基本的术语，比如JDK、JVM、JRE和HotSpotVM。接着会介绍JVM结构和Java 堆内存结构。理解这些基础对于理解后面的垃圾回收知识很重要。
Java GC系列（1）：Java垃圾回收简介
Java关键术语
- JavaAPI：一系列帮助开发者创建Java应用程序的封装好的库。
- Java 开发工具包 （JDK）：一系列工具帮助开发者创建Java应用程序。JDK包含工具编译、运行、打包、分发和监视Java应用程序。
- Java 虚拟机（JVM）：JVM是一个抽象的计算机结构。Java程序根据JVM的特性编写。JVM针对特定于操作系统并且可以将Java指令翻译成底层系统的指令并执行。JVM确保了Java的平台无关性。
- Java 运行环境（JRE）：JRE包含JVM实现和Java API。
Java HotSpot 虚拟机
每种JVM实现可能采用不同的方法实现垃圾回收机制。在收购SUN之前，Oracle使用的是JRockit JVM，收购之后使用HotSpot JVM。目前Oracle拥有两种JVM实现并且一段时间后两个JVM实现会合二为一。
HotSpot JVM是目前Oracle SE平台标准核心组件的一部分。在这篇垃圾回收教程中，我们将会了解基于HotSpot虚拟机的垃圾回收原则。
JVM体系结构
下面图片总结了JVM的关键组件。在JVM体系结构中，与垃圾回收相关的两个主要组件是堆内存和垃圾回收器。堆内存是内存数据区，用来保存运行时的对象实例。垃圾回收器也会在这里操作。现在我们知道这些组件是如何在框架中工作的。
Java堆内存
我们有必要了解堆内存在JVM内存模型的角色。在运行时，Java的实例被存放在堆内存区域。当一个对象不再被引用时，满足条件就会从堆内存移除。在垃圾回收进程中，这些对象将会从堆内存移除并且内存空间被回收。堆内存以下三个主要区域：
- 新生代（Young Generation）
- Eden空间（Eden space，任何实例都通过Eden空间进入运行时内存区域）
- S0 Survivor空间（S0 Survivor space，存在时间长的实例将会从Eden空间移动到S0 Survivor空间）
- S1 Survivor空间 （存在时间更长的实例将会从S0 Survivor空间移动到S1 Survivor空间）
- 老年代（Old Generation）实例将从S1提升到Tenured（终身代）
- 永久代（Permanent Generation）包含类、方法等细节的元信息
永久代空间在Java SE8特性中已经被移除。
Java GC系列（2）：Java垃圾回收是如何工作的？
Java 垃圾回收是一项自动化的过程，用来管理程序所使用的运行时内存。通过这一自动化过程，JVM 解除了程序员在程序中分配和释放内存资源的开销。
启动Java垃圾回收
作为一个自动的过程，程序员不需要在代码中显示地启动垃圾回收过程。System.gc()和Runtime.gc()用来请求JVM启动垃圾回收。
虽然这个请求机制提供给程序员一个启动 GC 过程的机会，但是启动由 JVM负责。JVM可以拒绝这个请求，所以并不保证这些调用都将执行垃圾回收。启动时机的选择由JVM决定，并且取决于堆内存中Eden区是否可用。 JVM将这个选择留给了Java规范的实现，不同实现具体使用的算法不尽相同。
毋庸置疑，我们知道垃圾回收过程是不能被强制执行的。我刚刚发现了一个调用System.gc()有意义的场景。通过这篇文章了解一下适合调用System.gc() 这种极端情况。
Java垃圾回收过程
垃圾回收是一种回收无用内存空间并使其对未来实例可用的过程。
Eden 区：当一个实例被创建了，首先会被存储在堆内存年轻代的 Eden 区中。
注意：如果你不能理解这些词汇，我建议你阅读这篇 垃圾回收介绍 ，这篇教程详细地介绍了内存模型、JVM 架构以及这些术语。
Survivor 区（S0 和 S1）：作为年轻代 GC（Minor GC）周期的一部分，存活的对象（仍然被引用的）从 Eden 区被移动到 Survivor 区的 S0 中。类似的，垃圾回收器会扫描 S0 然后将存活的实例移动到 S1 中。
（译注：此处不应该是Eden和S0中存活的都移到S1么，为什么会先移到S0再从S0移到S1？）
死亡的实例（不再被引用）被标记为垃圾回收。根据垃圾回收器（有四种常用的垃圾回收器，将在下一教程中介绍它们）选择的不同，要么被标记的实例都会不停地从内存中移除，要么回收过程会在一个单独的进程中完成。
老年代： 老年代（Old or tenured generation）是堆内存中的第二块逻辑区。当垃圾回收器执行 Minor GC 周期时，在 S1 Survivor 区中的存活实例将会被晋升到老年代，而未被引用的对象被标记为回收。
老年代 GC（Major GC）：相对于 Java 垃圾回收过程，老年代是实例生命周期的最后阶段。Major GC 扫描老年代的垃圾回收过程。如果实例不再被引用，那么它们会被标记为回收，否则它们会继续留在老年代中。
内存碎片：一旦实例从堆内存中被删除，其位置就会变空并且可用于未来实例的分配。这些空出的空间将会使整个内存区域碎片化。为了实例的快速分配，需要进行碎片整理。基于垃圾回收器的不同选择，回收的内存区域要么被不停地被整理，要么在一个单独的GC进程中完成。
垃圾回收中实例的终结
在释放一个实例和回收内存空间之前，Java 垃圾回收器会调用实例各自的 finalize() 方法，从而该实例有机会释放所持有的资源。虽然可以保证 finalize() 会在回收内存空间之前被调用，但是没有指定的顺序和时间。多个实例间的顺序是无法被预知，甚至可能会并行发生。程序不应该预先调整实例之间的顺序并使用 finalize() 方法回收资源。
- 任何在 finalize过程中未被捕获的异常会自动被忽略，然后该实例的 finalize 过程被取消。
- JVM 规范中并没有讨论关于弱引用的垃圾回收机制，也没有很明确的要求。具体的实现都由实现方决定。
- 垃圾回收是由一个守护线程完成的。
对象什么时候符合垃圾回收的条件？
- 所有实例都没有活动线程访问。
- 没有被其他任何实例访问的循环引用实例。
Java 中有不同的引用类型。判断实例是否符合垃圾收集的条件都依赖于它的引用类型。
| 引用类型 | 垃圾收集 |
|---|---|
| 强引用（Strong Reference） | 不符合垃圾收集 |
| 软引用（Soft Reference） | 垃圾收集可能会执行，但会作为最后的选择 |
| 弱引用（Weak Reference） | 符合垃圾收集 |
| 虚引用（Phantom Reference） | 符合垃圾收集 |
在编译过程中作为一种优化技术，Java 编译器能选择给实例赋 null 值，从而标记实例为可回收。
|
1
2
3
4
5
6
7
8
9
10
|
classAnimal {
publicstaticvoidmain(String[] args) {
Animal lion =newAnimal();
System.out.println("Main is completed.");
}
protectedvoidfinalize() {
System.out.println("Rest in Peace!");
}
}
|
在上面的类中，lion 对象在实例化行后从未被使用过。因此 Java 编译器作为一种优化措施可以直接在实例化行后赋值lion = null。因此，即使在 SOP 输出之前， finalize 函数也能够打印出 'Rest in Peace!'。我们不能证明这确定会发生，因为它依赖JVM的实现方式和运行时使用的内存。然而，我们还能学习到一点：如果编译器看到该实例在未来再也不会被引用，能够选择并提早释放实例空间。
- 关于对象什么时候符合垃圾回收有一个更好的例子。实例的所有属性能被存储在寄存器中，随后寄存器将被访问并读取内容。无一例外，这些值将被写回到实例中。虽然这些值在将来能被使用，这个实例仍然能被标记为符合垃圾回收。这是一个很经典的例子，不是吗？
- 当被赋值为null时，这是很简单的一个符合垃圾回收的示例。当然，复杂的情况可以像上面的几点。这是由 JVM 实现者所做的选择。目的是留下尽可能小的内存占用，加快响应速度，提高吞吐量。为了实现这一目标， JVM 的实现者可以选择一个更好的方案或算法在垃圾回收过程中回收内存空间。
- 当 finalize() 方法被调用时，JVM 会释放该线程上的所有同步锁。
GC Scope 示例程序
|
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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
Class GCScope {
GCScope t;
staticinti =1;
publicstaticvoidmain(String args[]) {
GCScope t1 =newGCScope();
GCScope t2 =newGCScope();
GCScope t3 =newGCScope();
// No Object Is Eligible for GC
t1.t = t2;// No Object Is Eligible for GC
t2.t = t3;// No Object Is Eligible for GC
t3.t = t1;// No Object Is Eligible for GC
t1 =null;
// No Object Is Eligible for GC (t3.t still has a reference to t1)
t2 =null;
// No Object Is Eligible for GC (t3.t.t still has a reference to t2)
t3 =null;
// All the 3 Object Is Eligible for GC (None of them have a reference.
// only the variable t of the objects are referring each other in a
// rounded fashion forming the Island of objects with out any external
// reference)
}
protectedvoidfinalize() {
System.out.println("Garbage collected from object"+ i);
i++;
}
classGCScope {
GCScope t;
staticinti =1;
publicstaticvoidmain(String args[]) {
GCScope t1 =newGCScope();
GCScope t2 =newGCScope();
GCScope t3 =newGCScope();
// 没有对象符合GC
t1.t = t2;// 没有对象符合GC
t2.t = t3;// 没有对象符合GC
t3.t = t1;// 没有对象符合GC
t1 =null;
// 没有对象符合GC (t3.t 仍然有一个到 t1 的引用)
t2 =null;
// 没有对象符合GC (t3.t.t 仍然有一个到 t2 的引用)
t3 =null;
// 所有三个对象都符合GC (它们中没有一个拥有引用。
// 只有各对象的变量 t 还指向了彼此，
// 形成了一个由对象组成的环形的岛，而没有任何外部的引用。)
}
protectedvoidfinalize() {
System.out.println("Garbage collected from object"+ i);
i++;
}
|
GC OutOfMemoryError 的示例程序
GC并不保证内存溢出问题的安全性，粗心写下的代码会导致 OutOfMemoryError。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
importjava.util.LinkedList;
importjava.util.List;
publicclassGC {
publicstaticvoidmain(String[] main) {
List l =newLinkedList();
// Enter infinite loop which will add a String to the list: l on each
// iteration.
do{
l.add(newString("Hello, World"));
}while(true);
}
}
|
输出：
|
1
2
3
4
|
Exceptioninthread"main"java.lang.OutOfMemoryError: Java heap space
at java.util.LinkedList.linkLast(LinkedList.java:142)
at java.util.LinkedList.add(LinkedList.java:338)
at com.javapapers.java.GCScope.main(GCScope.java:12)
|
Java GC系列（3）：垃圾回收器种类
Java有四种类型的垃圾回收器：
- 串行垃圾回收器（Serial Garbage Collector）
- 并行垃圾回收器（Parallel Garbage Collector）
- 并发标记扫描垃圾回收器（CMS Garbage Collector）
- G1垃圾回收器（G1 Garbage Collector）
每种类型都有自己的优势与劣势。重要的是，我们编程的时候可以通过JVM选择垃圾回收器类型。我们通过向JVM传递参数进行选择。每种类型在很大程 度上有 所不同并且可以为我们提供完全不同的应用程序性能。理解每种类型的垃圾回收器并且根据应用程序选择进行正确的选择是非常重要的。
1、串行垃圾回收器
串行垃圾回收器通过持有应用程序所有的线程进行工作。它为单线程环境设计，只使用一个单独的线程进行垃圾回收，通过冻结所有应用程序线程进行工作，所以可能不适合服务器环境。它最适合的是简单的命令行程序。
通过JVM参数-XX:+UseSerialGC可以使用串行垃圾回收器。
2、并行垃圾回收器
并行垃圾回收器也叫做 throughput collector 。它是JVM的默认垃圾回收器。与串行垃圾回收器不同，它使用多线程进行垃圾回收。相似的是，它也会冻结所有的应用程序线程当执行垃圾回收的时候
3、并发标记扫描垃圾回收器
并发标记垃圾回收使用多线程扫描堆内存，标记需要清理的实例并且清理被标记过的实例。并发标记垃圾回收器只会在下面两种情况持有应用程序所有线程。
- 当标记的引用对象在tenured区域；
- 在进行垃圾回收的时候，堆内存的数据被并发的改变。
相比并行垃圾回收器，并发标记扫描垃圾回收器使用更多的CPU来确保程序的吞吐量。如果我们可以为了更好的程序性能分配更多的CPU，那么并发标记上扫描垃圾回收器是更好的选择相比并发垃圾回收器。
通过JVM参数 XX:+USeParNewGC 打开并发标记扫描垃圾回收器。
4、G1垃圾回收器
G1垃圾回收器适用于堆内存很大的情况，他将堆内存分割成不同的区域，并且并发的对其进行垃圾回收。G1也可以在回收内存之后对剩余的堆内存空间进行压缩。并发扫描标记垃圾回收器在STW情况下压缩内存。G1垃圾回收会优先选择第一块垃圾最多的区域
通过JVM参数 –XX:+UseG1GC 使用G1垃圾回收器
Java 8 的新特性
在使用G1垃圾回收器的时候，通过 JVM参数 -XX:+UseStringDeduplication 。 我们可以通过删除重复的字符串，只保留一个char[]来优化堆内存。这个选择在Java 8 u 20被引入。
我们给出了全部的四种Java垃圾回收器，需要根据应用场景，硬件性能和吞吐量需求来决定使用哪一种。
垃圾回收的JVM配置
下面的JVM关键配置都与Java垃圾回收有关。
运行的垃圾回收器类型
| 配置 | 描述 |
|---|---|
| -XX:+UseSerialGC | 串行垃圾回收器 |
| -XX:+UseParallelGC | 并行垃圾回收器 |
| -XX:+UseConcMarkSweepGC | 并发标记扫描垃圾回收器 |
| -XX:ParallelCMSThreads= | 并发标记扫描垃圾回收器 =为使用的线程数量 |
| -XX:+UseG1GC | G1垃圾回收器 |
GC的优化配置
| 配置 | 描述 |
|---|---|
| -Xms | 初始化堆内存大小 |
| -Xmx | 堆内存最大值 |
| -Xmn | 新生代大小 |
| -XX:PermSize | 初始化永久代大小 |
| -XX:MaxPermSize | 永久代最大容量 |
使用JVM GC参数的例子
java -Xmx12m -Xms3m -Xmn1m -XX:PermSize=20m -XX:MaxPermSize=20m -XX:+UseSerialGC -jar java-application.jar
Java GC系列（4）：垃圾回收监视和分析
Java GC监视和分析工具
下面是一些可用的工具，每个都有自己的优势和缺点。我们可以通过选择正确的工具并分析，来提升应用程序的性能。这篇教程中，我们选用Java VisualVM。
- Java VisualVM
- Naarad
- GCViewer
- IBM Pattern Modeling and Analysis Tool for Java Garbage Collector
- HPjmeter
- IBM Monitoring and Diagnostic Tools for Java-Garbage Collection and Memory
- Visualizer
- Verbose GC Analyzer
Java VisualVM
Java VisualVM使用是免费的，其需要安装Java SE SDK。看一下Java JDK的bin文件夹中（路径：\Java\jdk1.8.0\bin），这里面有很多javac和java工具，jvisualvm就是其中之一。
Java VisualVM能够被用于：
- 生成并分析堆的内存转储；
- 在MBeans上观察并操作；
- 监视垃圾回收；
- 内存和CPU性能分析；
1、启动VisualVM
jvisualvm位于JDK bin文件夹下，直接点击就可以。
2、安装可视化GC插件
我们需要安装可视化GC插件，以便在Java GC过程中有良好的视觉感受。
3、监视GC
现在，是时候监视垃圾回收进程了，开启你的Java程序，它将自动被检测到并显示到Java VisualVM界面，左侧“Application”（应用程序）窗口下，“Local”（本地节点）下，所有本地运行的Java程序都会被列出。
Java VisualVM是一个Java应用程序，因此它也会被列在其中，教程的意图在于使用VisualVM来监视它自己的GC进程。
双击“Local”（本地）下的VisualVM图标。
现在，程序监控窗口在右侧打开，这有许多不同关于应用程序性能的相关监视指数的tab页，目前为止，我们最感兴趣的是“Visual GC”，点击它。
上面图片显示在Old、Eden、S0和S1上空间利用情况，下图显示了每部分空间的分配和释放情况。它按照指定的刷新率保持持续刷新。
上面图片所展示的是正常运行程序的情况，当出现内存泄露或者反常的行为时，它会在图表中明确的显示出来。最少我们能理解他是与对象内存分配和垃圾回收相关的事情。随后，通过其他tab页（像“Threads”）和Thread Dump的帮助，我们能够减少这个问题。
在“Monitor”tab页中，我们能够监控并定时展示所有堆内存使用情况图。通过“Perform GC”按钮可以启动垃圾回收进程。
在“Sampler”tab页中，我们能够启动内存和CPU性能分析，它将显示详细每个实例使用的实时报告，它将帮助我们明确性能问题。
触发主GC（Garbage Collector）的条件
JVM进行次GC的频率很高,但因为这种GC占用时间极短,所以对系统产生的影响不大。更值得关注的是主GC的触发条件,因为它对系统影响很明显。总的来说,有两个条件会触发主GC:
1)当应用程序空闲时,即没有应用线程在运行时,GC会被调用。因为GC在优先级最低的线程中进行,所以当应用忙时,GC线程就不会被调用,但以下条件除外。
2)Java堆内存不足时,GC会被调用。当应用线程在运行,并在运行过程中创建新对象,若这时内存空间不足,JVM就会强制地调用GC线程,以便回收内存用于新的分配。若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要求,则 JVM将报“out of memory”的错误,Java应用将停止。
由于是否进行主GC由JVM根据系统环境决定,而系统环境在不断的变化当中,所以主GC的运行具有不确定性,无法预计它何时必然出现,但可以确定的是对一个长期运行的应用来说,其主GC是反复进行的。
减少GC开销的措施
根据上述GC的机制,程序的运行会直接影响系统环境的变化,从而影响GC的触发。若不针对GC的特点进行设计和编码,就会出现内存驻留等一系列负面影响。为了避免这些影响,基本的原则就是尽可能地减少垃圾和减少GC过程中的开销。具体措施包括以下几个方面:
(1)不要显式调用System.gc()
此函数建议JVM进行主GC,虽然只是建议而非一定,但很多情况下它会触发主GC,从而增加主GC的频率,也即增加了间歇性停顿的次数。
(2)尽量减少临时对象的使用
临时对象在跳出函数调用后,会成为垃圾,少用临时变量就相当于减少了垃圾的产生,从而延长了出现上述第二个触发条件出现的时间,减少了主GC的机会。
(3)对象不用时最好显式置为Null
一般而言,为Null的对象都会被作为垃圾处理,所以将不用的对象显式地设为Null,有利于GC收集器判定垃圾,从而提高了GC的效率。
(4)尽量使用StringBuffer,而不用String来累加字符串
由于String是固定长的字符串对象,累加String对象时,并非在一个String对象中扩增,而是重新创建新的String对象,如Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建新的String对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。避免这种情况可以改用StringBuffer来累加字符串,因StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象。
(5)能用基本类型如Int,Long,就不用Integer,Long对象
基本类型变量占用的内存资源比相应对象占用的少得多,如果没有必要,最好使用基本变量。
(6)尽量少用静态对象变量
静态变量属于全局变量,不会被GC回收,它们会一直占用内存。
(7)分散对象创建或删除的时间
集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM在面临这种情况时,只能进行主GC,以回收内存或整合内存碎片,从而增加主GC的频率。集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主GC的机会。