java面试——垃圾回收机制

垃圾回收机制：——GC

　　初学java时。最经典的一句话是“java不像C，需要担心处理不用的内存，他有自己的垃圾回收，会自己处理的”，这是当时老师上课提过的一嘴，随后就没有了下文，后面发现这玩意面试时还是挺爱问的。

　　顾名思义，垃圾回收就是释放垃圾占用的空间。在Java中，程序员不需要去关心内存动态分配和垃圾回收的问题，这一切都交给了JVM来处理。

1、如何得知垃圾是什么？

　　计算机不像人脑，可以自主的识别垃圾是哪些，他只会依靠自己收到的指令去完成。那么他是怎么识别内存中的“垃圾呢”？

　　首先有一个引入计数法——对一个对象添加引用计数器。每当有地方引用它时，计数器值加1；当引用失效时，计数器值减1.而当计数器的值为0时这个对象就不会再被使用，判断为已死。是不是简单又直观。然而，很遗憾。这种做法是错误的！为什么是错的呢？事实上，用引用计数法确实在大部分情况下是一个不错的解决方案，而在实际的应用中也有不少案例，但它却无法解决对象之间的循环引用问题。比如对象A中有一个字段指向了对象B，而对象B中也有一个字段指向了对象A，而事实上他们俩都不再使用，但计数器的值永远都不可能为0，也就不会被回收，然后就发生了内存泄露。

　　接着有一个可达性分析——所有生成的对象都是一个称为"GC Roots"的根的子树。从GC Roots开始向下搜索，搜索所经过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链可以到达时，就称这个对象是不可达的（不可引用的），也就是可以被GC回收了。此算法解决了上述循环引用的问题。如A的对象和B的对象互相引用，但是他们都没有一个GC Roots的引用链可以到达，可以进行垃圾回收！

　　　　　　　　　　　　　　　　

　　

1.1、可达性分析算法

不可达的对象将暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程

1. 如果对象在进行可达性分析后发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize() 方法。
2. 当对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，直接进行第二次标记。
3. 如果这个对象被判定为有必要执行 finalize() 方法，那么这个对象将会放置在一个叫做 F-Queue 的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的 Finalizer 线程去执行它。

　　这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，因为如果一个对象在 finalize() 方法中执行缓慢，将很可能会一直阻塞 F-Queue 队列，甚至导致整个内存回收系统崩溃。

public class FinalizerTest {
    public static FinalizerTest object;
    public void isAlive() {
        System.out.println("I'm alive");
    }
 
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("method finalize is running");
        object = this;
    }
 
    public static void main(String[] args) throws Exception {
        object = new FinalizerTest();
        // 第一次执行，finalize方法会自救
        object = null;
        System.gc();//告诉他尽快回收‘垃圾’
 
        Thread.sleep(500);
        if (object != null) {
            object.isAlive();
        } else {
            System.out.println("I'm dead");
        }
 
        // 第二次执行，finalize方法已经执行过
        object = null;
        System.gc();
 
        Thread.sleep(500);
        if (object != null) {
            object.isAlive();
        } else {
            System.out.println("I'm dead");
        }
    }
}

输出如下：

method finalize is running
I'm alive
I'm dead

如果不重写 finalize()，输出将会是：

I'm dead
I'm dead

从执行结果可以看出：
第一次发生 GC 时，finalize() 方法的确执行了，并且在被回收之前成功逃脱；
第二次发生 GC 时，由于 finalize() 方法只会被 JVM 调用一次，object 被回收。

finalize()是Object里面的一个方法，当一个堆空间中的对象没有被栈空间变量指向的时候，这个对象会等待被java回收：jdk里面是这样实现的：

protected void finalize() throws Throwable { }
}

值得注意的是，使用 finalize() 方法来“拯救”对象是不值得提倡的，它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序。finalize() 能做的工作，使用 try-finally 或者其它方法都更适合、及时。

本段程序引用自 Java GC的那些事（上）

看不懂的话可以看看https://blog.csdn.net/qq_37823003/article/details/107333386，我觉得挺简单明了的

1.2、垃圾回收的特点

• 当对象不再被程序所使用的时候，垃圾回收器将会将其回收
• 垃圾回收是在后台运行的，我们无法命令垃圾回收器马上回收资源，但是我们可以告诉他可以尽快回收资源（System.gc()和Runtime.getRuntime().gc()）
• 垃圾回收器在回收某个对象的时候，首先会调用该对象的finalize()方法
• GC主要针对堆内存
• 单例模式的缺点

无论是引用计数器还是可达性分析，判定对象是否存活都与引用有关，那么如何定义对象的引用呢？

2、对象的引用

　　当内存空间还够时，能够保存在内存中；如果进行了垃圾回收之后内存空间仍旧非常紧张，则可以抛弃这些对象。所以根据不同的需求，给出如下四种引用，根据引用类型的不同，GC回收时也会有不同的操作。引用可分为强、软、弱、虚引用

 

 

1. 强引用：就是指在程序代码之中普遍存在的，类似"Object obj=new Object()"这类的引用，垃圾收集器永远不会回收存活的强引用对象。
2. 软引用：还有用但并非必需的对象。在系统 将要发生内存溢出异常之前 ，将会把这些对象列进回收范围之中进行第二次回收（即系统将会发生内存溢出了，才会对他们进行回收）
3. 弱引用：程度比软引用还要弱一些，也是用来描述非必需对象的，被弱引用关联的对象只能生存到下一次垃圾收集发生之前 。（即当垃圾收集器工作时，无论内存是否足够，都会回收掉只被弱引用关联的对象。）
4. 虚引用：是最弱的一种引用关系。无法通过虚引用来取得一个对象实例 。一个对象是否存在虚引用，完全不会对其生存时间构成影响。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知

3、垃圾回收算法

　　在确定了哪些垃圾可以被回收后，垃圾收集器要做的事情就是开始进行垃圾回收。

一共有 4 种：

1. 标记-清除算法
2. 复制算法
3. 标记整理算法
4. 分代收集算法

3.1、Mark-Sweep（标记-清除）算法

　　最基础的垃圾回收算法，标记-清除算法分为两个阶段：标记阶段和清除阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。具体过程如下图所示：（黑色的就是标记的对象）

它的主要不足有两个：

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

3.2、Copying（复制）算法

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

3.3、Mark-Compact（标记-整理）算法

 

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

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

 

 

3.4、Generational Collection（分代收集）算法

 

 　　分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。

　　目前大部分垃圾收集器对于新生代都采取Copying算法，因为新生代中每次垃圾回收都要回收大部分对象，也就是说需要复制的操作次数较少，但是实际中并不是按照1：1的比例来划分新生代的空间的，一般来说是将新生代划分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden空间和其中的一块Survivor空间，当进行回收时，将Eden和Survivor中还存活的对象复制到另一块Survivor空间中，然后清理掉Eden和刚才使用过的Survivor空间。

　　而由于老年代的特点是每次回收都只回收少量对象，一般使用的是Mark-Compact算法。

　　注意，在堆区之外还有一个代就是永久代（Permanet Generation），它用来存储class类、常量、方法描述等。对永久代的回收主要回收两部分内容：废弃常量和无用的类。

4、既然有GC机制，为什么还会有内存泄露的情况?

　　理论上Java因为有垃圾回收机制（GC）不会存在内存泄露问题（这也是Java被广泛使用于服务器端编程的一个重要原因）。然而在实际开发中，可能会存在无用但可达的对象，这些对象不能被GC回收，因此也会导致内存泄露的发生。

 　　例如hibernate的Session（一级缓存）中的对象属于持久态，垃圾回收器是不会回收这些对象的，然而这些对象中可能存在无用的垃圾对象，如果不及时关闭（close）或清空（flush）一级缓存就可能导致内存泄露。

下面例子中的代码也会导致内存泄露。

import java.util.Arrays;
import java.util.EmptyStackException;
public class MyStack<T> {
    private T[] elements;
    private int size = 0;
    private static final int INIT_CAPACITY = 16;
    public MyStack() {
        elements = (T[]) new Object[INIT_CAPACITY];
    }
    public void push(T elem) {
        ensureCapacity();
        elements[size++] = elem;
    }
    public T pop() {
        if (size == 0) throw new EmptyStackException();
        return elements[--size];
    }

    private void ensureCapacity() {
        if (elements.length == size) {
            elements = Arrays.copyOf(elements,2 * size + 1);
        }
    }
}

　　上面的代码实现了一个栈（先进后出（FILO））结构，乍看之下似乎没有什么明显的问题，它甚至可以通过你编写的各种单元测试。然而其中的pop方法却存在内存泄露的问题，当我们用pop方法弹出栈中的对象时，该对象不会被当作垃圾回收，即使使用栈的程序不再引用这些对象，因为栈内部维护着对这些对象的过期引用（obsolete reference）。在支持垃圾回收的语言中，内存泄露是很隐蔽的，这种内存泄露其实就是无意识的对象保持。如果一个对象引用被无意识的保留起来了，那么垃圾回收器不会处理这个对象，也不会处理该对象引用的其他对象，即使这样的对象只有少数几个，也可能会导致很多的对象被排除在垃圾回收之外，从而对性能造成重大影响，极端情况下会引发Disk Paging（物理内存与硬盘的虚拟内存交换数据），甚至造成OutOfMemoryError。