垃圾回收是什么？从运行时数据区看垃圾回收到底回收哪块区域？

JVM内存模型认识的差不多了，就应该思考，什么样的内存模型适合什么样的GC策略，包括垃圾回收为什么会出现。实际上，很多东西都是相对应版本的JVM强加上去的。那么垃圾回收是什么？到底回收哪块区域？如何去回收？

这个时候观察运行时数据区来进行分析。
线程私有的区域是完全没有必要回收的，因为方法消亡就消亡了，它的生命周期很短，会伴随着你的方法的退出而消亡，因此不必关心它的回收，而且类文件结构确定之后，就知道整个方法当中字节码指令流转的一个情况了，所以不需要对这块区域进行关心。

线程共享的区域是方法区和堆这两块区域，而方法区MetaSpace中，实际上它的回收有没有呢？有的，但是很少，或者说回收的效率并不高，因为方法区当中的数据是静态变量，常量，字符串常量池，类信息，即时编译后的代码，它的生命周期一般都很长，随着程序运行一段时间之后，它占用方法区的那一块内存会趋于稳定，因为这些东西不回收，所以回收重点关注的地方还是堆这个区域。因为Java是一门面向对象的一门高级语言，所以对象的创建以及回收才是最重要的。而我们的GC，或者说所谓的垃圾回收，更多的是对于堆内存这块区域的回收，来进行讨论。

那么堆要进行回收的话，到底要怎么去进行回收呢？

垃圾回收如何去回收？

首先需要考虑的第一个问题：什么样的场景下适合使用什么样的垃圾回收策略。

这里注意策略和算法是不一样的，算法是真正落地的实现，而策略不一定要落地。

回收策略按照我们的思想去设计优化的话，首先肯定要关注内存的使用情况，因为垃圾回收本身就是一种穷人策略，因为没有那么多内存共我们去挥霍，所以才会想尽办法提高我们垃圾回收的效率。

垃圾回收策略

收的多： 收的多，意味着收的久。尽可能每次多回收一些对象，尽可能多腾出一些内存，而收的多意味着收的久。
收的快： 收的快，意味着每次收的少需要多次回收。最好可以将时间缩短到一次网络延迟，哪怕回收次数很多都可以容忍，这样收再多次都是无所谓的。

因此会在垃圾回收的时间上和CPU的效率上有个抉择，假设CPU使用率过高，那么可以尽可能的去调低垃圾回收的一个频率，使得CPU的使用率能够在我们接受的范围内，也就是可控性回收。

比如我们平时收拾屋子，那么首先就是确定屋子多大，然后哪些东西是垃圾。程序亦是如此，hotsport的开发者也会有这样的想法，它需要有一套判断当前对象是垃圾的依据(或者叫算法)。那么在程序当中，所有的执行逻辑、判断逻辑都可以称之为算法，因为程序就是逻辑＋数据组成的。

为什么回收选取操作性较高的数据？

举个例子，你在家里扫垃圾，肯定也是选择比较容易清理的哪些东西叫做垃圾，不好拿的和好拿的肯定先选好拿的。那么在当前的场景中，我们操作性较高的数据是对象，因此是根据对象去进行一个讨论。

而在Java中，引用和对象显然是有关联的，如果要操作对象，必然是会引用来去执行，那么这个时候，最显然的一个办法就是通过引用计数来判断对象是否可以回收，简单的来说，如果一个对象没有任何与之相关联的引用，即它们的引用计数都为0的情况下，也就是说，这个对象没有任何场景下可能会使用到它了，那这个对象就是可回收对象，这就是引用计数法。但是现在Java主流算法并不是这个，因为它难以解决循环引用的问题。

引用计数算法及循环引用问题

java 复制代码

/**
 * 引用计数法难以解决循环引用问题
 */
public class CircularReferenceDemo {

    public static void main(String[] args) {

        CircularReferenceObject obj1 = new CircularReferenceObject();
        CircularReferenceObject obj2 = new CircularReferenceObject();
        /**
         * 这两句代码表示：
         * 第一步：虚拟机栈有两个东西obj1、obj2，它是虚拟机栈中的局部变量表中的元素
         * 第二步：new两个CircularReferenceObject对象，这两个对象是不同的CircularReferenceObject实例，在堆当中共开辟两个内存地址
         * 第三步：obj1指向堆中的实例1，obj2指向堆中的实例2
         *
         * 此时此刻，堆中的这两个实例的引用计数应该各自+1=1
         */

        obj1.instance = obj2;
        obj2.instance = obj1;
        /**
         * 让堆中的两个实例互相引用，obj1指向obj2，obj2指向obj1
         *
         * 此时此刻，堆中的这两个实例的引用计数应该各自再+1=2
         */

        obj1 = null;
        obj2 = null;
        /**
         * 赋值为null，表示不再指向任何数据，即栈中元素不再指向堆中实例
         *
         * 此时此刻，堆中的这两个实例的引用计数应该各自-1=1
         *
         * 这个时候，循环引用问腿就来了：按照引用计数法，堆中这两个实例各自的引用计数都不为0，也就是说这两个实例所占用的堆内存空间无法释放
         *
         * 系统给到实例内存空间但是无法释放的这种情况称之为内存泄露，如果这种情况一直发生，最终会导致内存溢出，因此主流的JVM已经摒弃了这种算法
         */
    }

    static class CircularReferenceObject {
        public Object instance = null;
    }
}

对于对象之间的循环引用问题，其实引用计数法它会有策略进行解决，但是这个不是Java应该关心的事情。Java中已经摒弃了引用计数法这种算法，python还在用，引用计数法这种算法的效率会比另一种算法快的多，既然主流的JVM已经摒弃了这种算法，那么必然会出现一种新的算法对它进行替代，来解决循环引用的问题，最少也是让所谓循环引用的问题带来的影响没那么大，那么另一种算法横空出世，就是可达性分析算法。

可达性分析算法

可达性分析算法，也被称为根搜索算法，目前主流的JVM都是采用的这种算法，比如Sun公司的hotsport。
这个算法的核心是从所谓的GC root进行出发，也就是从一个所谓的根进行出发，利用数学中的图论(Graph Theory)知识，从根触发，单条引用链能够到达的对象，便是存活对象，反之即为不可达对象，不可达对象就是需要回收的垃圾。

这里面涉及到两个概念根(所谓的GC root)和可达性。所谓的根、GC root只是一种引用，它并不是对象，它只是告诉你地址，让你知道如何找对象。

哪些可以作为GC root的对象？