深入理解java垃圾回收机制

最新推荐文章于 2024-08-16 20:01:07 发布

NFMSR

最新推荐文章于 2024-08-16 20:01:07 发布

阅读量463

点赞数 1

分类专栏： javaSE 文章标签： java 垃圾回收 GC 分代内存泄露

本文链接：https://blog.csdn.net/NFMSR/article/details/78628965

版权

javaSE 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

深入理解java垃圾回收机制

一、垃圾回收机制的意义

Java语言中一个显著的特点就是引入了垃圾回收机制，使c++程序员最头疼的内存管理的问题迎刃而解，它使得Java程序员在编写程序的时候不再需要考虑内存管理。由于有个垃圾回收机制，Java中的对象不再有“作用域”的概念，只有对象的引用才有“作用域”。垃圾回收可以有效的防止内存泄露，有效的使用空闲的内存。

ps: 内存泄露是指该内存空间使用完毕之后未回收，在不涉及复杂数据结构的一般情况下，Java 的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度，我们有时也将其称为“对象游离”。

二、垃圾回收机制的设计

垃圾回收要解决的问题

垃圾收集（Garbage Collection，GC），要设计一个GC，需要考虑解决下面三件事情：

（1）哪些内存需要回收？

（2）什么时候回收？

（3）如何回收？

下面仔细逐一分析上面三个问题：

哪些内存需要回收（回收区域）

java内存模型中，程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，因此这几个区域的内存分配和回收都具备确定性，故这几个区域就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟着回收了。

对于java堆和方法区则不一样，java堆是存放实例对象的地方，我们只有在程序运行期间才能知道会创建哪些对象，这部分内存的分配和回收是动态的，因此，垃圾收集器所关注的就是这一部分。

对于方法区（或者说HotSpot（JAVA）虚拟机中的永久代），垃圾回收主要是回收这两部分内容：废弃常量和无用的类。对于废弃常量，主要是判断当前系统中有没有对象引用这个常量；对于无用类则比较严格，需要满足下面三个条件：

（1）该类的所有实例都已经被回收，即堆中不存在该类任何势力；

（2）加载该类的ClassLoader已经被回收；

（3）对类对应的java.lang.Class对象没有在任何地方被引用，无法再任何地方通过反射访问该类的方法；

满足了上面三个条件也仅仅是“可以”进行回收了，还要根据HotSpot（JAVA虚拟机）的一些配置参数综合考虑。

什么时候回收？（回收对象）

既然垃圾收集器的任务是回收垃圾对象所占的空间供新的对象使用，那么垃圾收集器如何确定某个对象是“垃圾”？—即通过什么方法判断一个对象可以被回收了。

判断对象是否存活的算法：

1) 引用计数算法

给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1，当引用失效时，计数器值就减1；任何时刻计数器值都为0时对象就表示它不可能被使用了。引用计数算法实现简单，判定效率也很高，大部分情况下是一个不错的算法。但有一个比较重要的缺点：很难解决对象之间相互循环引用的问题。因此在Java中并没有采用这种方式（Python采用的是引用计数法）。看下面这段代码：

public class Main {
    public static void main(String[] args) {
        MyObject object1 = new MyObject();
        MyObject object2 = new MyObject();
          
        object1.object = object2;
        object2.object = object1;
          
        object1 = null;
        object2 = null;
    }
}

最后面两句将object1和object2赋值为null，也就是说object1和object2指向的对象已经不可能再被访问，但是由于它们互相引用对方，导致它们的引用计数器都不为0，那么垃圾收集器就永远不会回收它们。
2)可达性分析算法
目前主流的虚拟机，如java默认虚拟机HotSpot就是用的这种方式。算法基本思路为：通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时（或者说从GC Roots到这个对象不可达），则证明此对象是不可用的。

java中可作为GC Root的对象有:

1.虚拟机栈中引用的对象（本地变量表）
2.方法区中静态属性引用的对象
3. 方法区中常量final引用的对象
4.本地方法栈中引用的对象（Native对象）

总结一下平常遇到的比较常见的将对象判定为可回收对象的情况：

a）显示地将某个引用赋值为null或者将已经指向某个对象的引用指向新的对象，比如下面的代码：

Object obj = new Object();
obj = null;
Object obj1 = new Object();
Object obj2 = new Object();
obj1 = obj2;

obj对象和obj1原来指向的那个对象都会被回收。。

b）局部引用所指向的对象，比如下面这段代码

void fun() {
 
.....
    for(int i=0;i<10;i++) {
        Object obj = new Object();
        System.out.println(obj.getClass());
    }   
}

循环每执行完一次，生成的Object对象都会成为可回收的对象。

c）只有弱引用与其关联的对象，比如：

WeakReference<String> wr = new WeakReference<String>(new String("world"));

这点我还不太明白。。是String 对象将被回收？

最后需要注意的是，即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过（也就是说对象的finalize()方法只能被调用一次），虚拟机将这两种情况都视为“没有必要执行”。

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它（即去执行对象的finalize()方法，这里所谓的“执行”是值虚拟机会触发这个方法，但并不承若会等待它运行结束，主要是为了防止对象的finalize方法执行缓慢或发生死循环，导致其他对象不能被执行的，从而引起内存回收系统崩溃）。

如何回收？（垃圾回收算法）

在确定了哪些垃圾可以被回收后，垃圾收集器要做的事情就是开始进行垃圾回收，但是这里面涉及到一个问题是：如何高效地进行垃圾回收。由于Java虚拟机规范并没有对如何实现垃圾收集器做出明确的规定，因此各个厂商的虚拟机可以采用不同的方式来实现垃圾收集器，所以在此只讨论几种常见的垃圾收集算法的核心思想。

1. Mark-Sweep（标记-清除）算法

算法：分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。标记过程就是上面可达性分析算法中所讲的二次标记过程。标记-清除算法的执行过程如下图所示：

回收前状态：

回收后状态：

标记-清除实现起来很简单，可以容易地回收循环的结构，并且不像引用计数那样增加编译器或者赋值函数的负担。但是它也有不足 ―― 收集暂停可能会很长，在清除阶段整个堆都是可访问的，这对于可能有页面交换的堆的虚拟内存系统有非常负面的性能影响。

标记-清除的最大问题是，每一个活跃的（即已分配的）对象，不管是不是可到达的，在清除阶段都是可以访问的。因为很多对象都可能成为垃圾，这意思着收集器花费大量精力去检查并处理垃圾。标记-清除收集器还容易使堆产生碎片，这会产生区域性问题并可以造成分配失败，即使看来有足够的自由内存可用。此算法需要暂停整个应用，同时，会产生内存碎片。

总结缺点：

（1）效率问题：标记和清除的两个过程效率都不高；

（2）空间问题：标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后需要分配较大对象时，无法找到足够的连续内存而不得不提前出发另一次垃圾收集动作；

2.Copying（复制）算法

为了解决上面算法的效率问题，复制算法出现。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存使用完了，就将还存活的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
复制算法的优点：
（1）每次都是对整个半区进行内存回收，实现简单、运行也高效；
（2）在那块使用内存上进行内存分配时，不用考虑内存碎片的问题，只要移动堆顶指针，按顺序分配内存即可；
缺点：
将内存缩小为原来的一半，代价较高。

复制算法的执行过程如下：

回收前的状态：

回收后的状态：

3.Compacting（标记整理）算法

复制算法如果在对象存活率较高时，就需要进行较多次的复制操作，效率也会变低。而对于老年代中的对象，一般存活率都较高，因此需要选用其他收集算法：标记 - 整理算法。
此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，标记完成后并不直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。

回收前状态;

回收后状态：

4. generation （分代收集）算法(Generational Collector)

分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的回收算法，以便提高回收效率。

将堆分成新生代（Eden, From Survivor, To Survivor）和老年代，在新生代中使用复制算法，即Minor-GC，当一些对象经过多次的Minor-GC后还留在新生代，则会被搬移到老年代中。而老年代中使用标记-清理或标记-整理算法，即Major GC/Full GC。

年轻代（Young Generation）

1.所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。

2.新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空，如此往复。

3.当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。或者对象在survivor空间存活多次（15）之后，则会搬移到老年代

若是老年代也满了就会触发一次Full GC，也就是新生代、老年代都进行回收

4.新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)

年老代（Old Generation）

1.在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

2.内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC或Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。

持久代（Permanent Generation）

用于存放静态文件，如Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate 等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。

三．GC（垃圾收集器）

关于垃圾回收器的详细介绍可以看参考链接第二篇博客

如果说上面介绍的收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现，按照上面的介绍，目前垃圾收集器基本都采用分代收集，因此一个垃圾收集器中一般都存在多种垃圾回收算法。不同的虚拟机提供的垃圾收集器也有很大差异，如下是HotSpot虚拟机基于JDK1.7版本所包含的所有垃圾收集器。

HotSpot中共有7中不同的垃圾收集器，如果两个收集器之间存在连线，说明它们之间可以搭配使用，其中，Serial、ParNew、Parallel Scavenge属于新生代收集器，CMS、Serial Old、Parallel Old属于老年代收集器，G1是最新的一种收集器，在新生代和老年代中都可使用。

Serial收集器（复制算法)

新生代单线程收集器，标记和清理都是单线程，优点是简单高效。

Serial Old收集器(标记-整理算法)

老年代单线程收集器，Serial收集器的老年代版本。

ParNew收集器(停止-复制算法)　一种典型的基于coping算法的垃圾回收是stop-and-copy算法

新生代收集器，可以认为是Serial收集器的多线程版本,在多核CPU环境下有着比Serial更好的表现。

Parallel Scavenge收集器(停止-复制算法)

并行收集器，追求高吞吐量，高效利用CPU。吞吐量一般为99%，吞吐量= 用户线程时间/(用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。

Parallel Old收集器(停止-复制算法)

Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量优先

CMS(Concurrent Mark Sweep)收集器（标记-清理算法）

高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，响应时间快，停顿时间短，多核cpu 追求高响应时间的选择

四、GC的执行机制

由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。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：

1.年老代（Tenured）被写满

2.持久代（Perm）被写满

3.System.gc()被显示调用

4.上一次GC之后Heap的各域分配策略动态变化

五、Java有了GC同样会出现内存泄露问题

1.静态集合类像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，所有的对象Object也不能被释放，因为他们也将一直被Vector等应用着。

Static Vector v = new Vector(); 
for (int i = 1; i<100; i++) 
{ 
    Object o = new Object(); 
    v.add(o); 
    o = null; 
}

在这个例子中，代码栈中存在Vector 对象的引用 v 和 Object 对象的引用 o 。在 For 循环中，我们不断的生成新的对象，然后将其添加到 Vector 对象中，之后将 o 引用置空。问题是当 o 引用被置空后，如果发生 GC，我们创建的 Object 对象是否能够被 GC 回收呢？答案是否定的。因为， GC 在跟踪代码栈中的引用时，会发现 v 引用，而继续往下跟踪，就会发现 v 引用指向的内存空间中又存在指向 Object 对象的引用。也就是说尽管o 引用已经被置空，但是 Object 对象仍然存在其他的引用，是可以被访问到的，所以 GC 无法将其释放掉。如果在此循环之后， Object 对象对程序已经没有任何作用，那么我们就认为此 Java 程序发生了内存泄漏。

2.各种连接，数据库连接，网络连接，IO连接等没有显示调用close关闭，不被GC回收导致内存泄露。

3.监听器的使用，在释放对象的同时没有相应删除监听器的时候也可能导致内存泄露

参考博客：

http://www.importnew.com/16173.html

http://blog.csdn.net/shakespeare001/article/details/51749788

http://blog.csdn.net/csh624366188/article/details/8042649