JVM基础（3）——JVM垃圾回收机制

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

一、简介

我们在 JVM内存模型一章中，介绍了JVM中的Java堆内存区域。该区域是JVM为Java对象分配内存的主要区域，本章我们主要针对该块区域讲解JVM的垃圾回收机制。

我们先通过一个示例，回顾下对象的分配与引用：

    public class Kafka {
        public static void main(String[] args) {
            loadReplicaFromDisk();
        }
    
        private static void loadReplicaFromDisk() {
            ReplicaManager replicaManager = new ReplicaManager();
            replicaManager.load();
        }
    }

首先，main线程会执行main()方法里面的代码，它会把main()方法的栈帧压入自己的Java虚拟机栈中：

接着，main()方法内部调用了loadReplicaFromDisk()方法，就会创建一个loadReplicaFromDisk()方法对应的栈帧，同时在栈帧中存入一个局部变量replicaManager：

接着，loadReplicaFromDisk()方法内部创建了一个ReplicaManager对象，此时就会在Java堆内存中为该实例对象分配内存空间，并让局部变量replicaManager指向该实例对象：

最后，执行实例对象的load()方法，完成我们的业务逻辑。那么，这里思考一个问题，load方法执行完毕后会发生什么？我们上一章中提到过，方法执行完毕后对应的栈帧就会出栈，而一旦栈帧出栈，“replicaManager”局部变量也就没有了，此时就没有任何一个变量指向Java堆内存里的ReplicaManager实例对象了：

Java堆内存里面的资源是有限的，所以对于上述ReplicaManager这类孤立的对象，必须要有一种机制去清理它们，JVM会有一个在后台运行的垃圾回收线程，去分析和处理这些垃圾对象，这就是本章要讲的 JVM垃圾回收机制 。

二、分代回收

在正式讲解JVM垃圾回收机制前，我们先来了解下JVM内存分代模型、： 新生代 、 老年代 、 永久代 。

2.1 新生代

还是通过一个代码示例来讲解：

    public class Kafka {
        public static void main(String[] args) throws InterruptedException {
            while (true){
                loadReplicaFromDisk();
                Thread.sleep(1000);
            }
        }
    
        private static void loadReplicaFromDisk() {
            ReplicaManager replicaManager = new ReplicaManager();
            replicaManager.load();
        }
    }

上述代码中，当main线程执行main()方法后，会进入一个永久循环，执行完第一遍后，JVM中的数据结构大致如下图：

当进入下一次循环再执行loadReplicaFromDisk()时，会再构造一个ReplicaManager对象实例放入Java堆内存中，原来的那个就会被JVM垃圾回收线程给回收掉，如此循环往复，ReplicaManager对象的生命周期非常短，频繁地被创建和回收：

像ReplicaManager这种“朝生暮死”的小对象，通常都会在Java堆内存区域的"新生代"进行分配。但是，并不是每次JVM都会进行回收，默认情况下当新生代的内存空间快被占满时，会触发一次 “Minor GC” ，此时才会进行回收。

2.2 老年代

我们对2.1中的代码进行改造，此时fetcher是一个静态变量，其实例对象ReplicaFetcher会一直被该静态变量引用，而ReplicaManager对象则一直“朝生暮死”：

    public class Kafka {
        private static ReplicaFetcher fetcher = new ReplicaFetcher();
    
        public static void main(String[] args) throws InterruptedException {
            loadReplicaFromDisk();
            while (true) {
                fetcheReplicaFromRemote();
                Thread.sleep(1000);
            }
        }
    
        private static void loadReplicaFromDisk() {
            ReplicaManager replicaManager = new ReplicaManager();
            replicaManager.load();
        }
    
        private static void fetcheReplicaFromRemote() {
            fetcher.fetch();
        }
    }

最初时，ReplicaFetcher对象和ReplicaManager对象都被分配在新生代：

根据Java虚拟机规范， 如果一个实例对象在新生代中，成功的在15次垃圾回收之后，还是没有被回收到，那么就会被转移到老年代 ，所以ReplicaFetcher这个对象会首先在“年轻代”驻留一会儿，但是最终会进入老年代：

而ReplicaManager对象，当loadReplicaFromDisk()方法执行完成后，栈帧就会出栈，所以年轻代里的ReplicaManager会被垃圾回收线程清理掉：

老年代也有类似"Minor GC"的机制，另外，对于一些大对象，会直接在“老年代“分配；在一次”Minor GC“之后，如果新生代中的存活对象过多，即使这些对象年龄没有达到15，也会直接进入老年代。这些细节，后面我们会专门讲解。

2.3 永久代

永久代就是我们在JVM内存模型中提到到“方法区”，方法区中存储着类的信息，当满足以下三个条件时，方法区里的类会被回收：

该类的所有实例对象已经从Java堆内存中被回收；
加载这个类的ClassLoader已经被回收；
对该类的Class对象没有任何引用。

三、JVM参数

3.1 核心参数

先来看一些核心的参数，通过这些参数可以设置上述提到的新生代、老年代、永久代的内存区域大小：

-Xms ：Java堆内存区域的大小；

-Xmx ：Java堆内存区域的最大大小；

-Xmn ：Java堆内存区域的新生代大小，扣除新生代剩下的就是老年代的大小；

-XX:PermSize ：永久代大小；

-XX:MaxPermSize ：永久代的最大大小；

-Xss ：每个线程的栈内存大小。

-Xms和-Xmx，分别用于设置Java堆内存的初始大小和最大大小，一般设置为相同值就可以，这样就限定了Java堆内存的总大小。

同理，-XX:PermSize和-XX:MaxPermSize配合使用可以限定永久代的大小。

最后，每个线程都有自己的虚拟机栈，-Xss就是限定了每个线程的虚拟机栈内存的大小。

JDK1.8以后，方法区变成了“元数据区”，-XX:PermSize和-XX:MaxPermSize这两个参数，也相应的变成了-XX:MetaspaceSize和-XX:MaxMetaspaceSize。

3.2 新生代配置

我们来看一个线上示例，更好的理解下如何合理的设置JVM参数。下图是一个电商系统的大致流程，我们重点分析用户提交支付订单-支付系统这一块：

对于支付系统，其系统压力来自很多方面，包括高并发访问、大量日订单数据存储、高可用保障等等，抛开这些系统架构层面的东西，我们只看JVM层面，系统最大的压力来自于 频繁的创建和销毁支付订单 ，所以就需要根据以下情况来估计每台机器的JVM参数设置：

支付联机系统的部署机器数量
每台机器的内存
每台机器的JVM堆内存大小

并发量估算

首先，我们先从系统日交易量入手，估算下每秒平均交易量。以笔者曾经做过的某银行核心支付平台为例，除去双11之类促活日外，系统日平均交易量为6000万笔，根据“二八定律”，80%的交易发生在20%的时间内，再乘以经验因子3，峰值每秒交易量大约为9000笔：
$$
TPS = 60000000 80\% / (2460600.2) * 3≈ 9000
$$
假设我们部署20台机器，每台机器每秒大概处理450笔订单：