一文详解，jvm内存分代与垃圾回收原理

jvm运行时数据区

Java程序启动后，本质上就是启动一个jvm进程，jvm会将自己管理的内存划分为几个区域，每个区域都有自己的用途。在程序运行时的内存区域主要可以划分为五个，分别是：方法区、堆、虚拟机栈、本地方法栈、程序计数器。可以用下面的图来描述：

图1 jvm运行时数据区

jvm堆内存分代

我们创建的对象，都会进入Java堆内存中，堆内存的分代模型分为：年轻代、老年代、永久代。

其实大部分对象的存活周期都是极短的，比如我们在方法里创建一个对象，离开这个方法后，这个对象的生命周期就结束了。一旦这个对象没人使用了，就需要被jvm回收掉，释放内存空间。

少数对象是长期存活的，比如spring容器中创建的bean，一般都会一直存活在容器中。

每个对象的存活时间差别巨大，那么就需要差别化管理，就像城市规划中，会划分出生活区，商业区，制造业区。

于是jvm就有了分代模型，年轻代、老年代，jvm将堆内存分为了这两个区域。

年轻代，顾名思义，就是对象创建和使用完之后，很快就要回收的对象放在里面。

老年代呢，就是对象创建之后需要长期存在的对象放在里面，如下图：

图2 jvm堆内存分代

堆内存分为年轻代、老年代，这跟垃圾回收有关，对于年轻代里的对象，它们的特点是创建之后很快就会被回收，所以需要用一种垃圾回收算法。

对于老年代里的对象，他们的特点是需要长期存在，所以需要另外一种垃圾回收算法，所以需要分成两个区域来放不同的对象。

对象的分配与流转

一般来说，对象都是优先分配在年轻代的。

public class Server {    private static ConfigLoader loader = new ConfigLoader();    public static void main(String[] args) {        loadLocalConfig();        while (true) {         loadConfigFromRemote();            Thread.sleep(1000);        }    }        private static void loadLocalConfig() {        ConfigManager configManager = new ConfigManager();        configManager.load();    }    private static void loadConfigFromRemote() {        loader.load();    }}类静态变量loader引用的那个ConfigLoader对象，首先分配在年轻代，是长期存活在内存里的。loadLocalConfig方法中创建的configManager对象也是分配在新时代里的。

 图3 对象优先分配在新生代

什么时候触发新生代的垃圾回收？

当方法loadLocalConfig执行完后，这个方法堆栈出栈，就没有任何局部变量引用configManager对象了。

那么jvm就会立马回收掉分配给它的内存吗？

不会的！如果新生代的内存空间，几乎都被全部对象给占满了！此时假设我们代码继续运行，需要在新生代里去分配一个对象，发现内存不够了，这个时候就会触发一次新生代的内存回收。

新生代内存空间的垃圾回收，也称之为Minor GC或Young GC，它会尝试把新生代里没人引用的对象给回收掉。

对象是有年龄的，如果对象在一次垃圾回收后还存活，那么它的年龄就会加1。

默认情况下，如果成功躲过了15次垃圾回收，也就是15岁，还没被回收掉，然后它会被转移到Java堆内存的老年代中去，顾名思义，老年代就是放这些年龄很大的对象。

什么情况下一个对象会被回收掉？

简单来说一个对象不再被使用了，就会被垃圾回收掉，但jvm怎么判断一个对象是否会继续使用呢？

jvm使用了一种可达性分析的算法来判断对象是不是可以被回收掉。

可达性分析法，是通过从GCRoots出发，找出内存中的引用链，那么链中的对象表示可达，即不能被垃圾回收。引用链之外的对象即可作为垃圾回收。

jvm中GC Roots有这几种：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI（即一般说的native方法）中引用的对象

其中，局部变量和类静态变量比较常见。需要注意的是，类实例变量不是GC Roots。

年轻代的垃圾回收算法

新生代内存区域划分为三块：1个Eden区，2个Survivor区，默认情况下Eden区占80%内存空间，每一块Survivor区各占10%内存空间，

比如说新生代1G的内存，Eden区就有800MB内存，每一块Survivor区就有100MB内存，如下图。

图4 新生代内存划分

刚开始对象都是分配在Eden区内的，如果Eden区快满了，此时就会触发垃圾回收。

新生代使用的复制算法，此时就会把Eden区中的存活对象都一次性转移到一块空着的Survivor区。survivor的中文意思是存活，顾名思义，就是放垃圾回收后存活的对象的。

接着Eden区就会被清空，然后再次分配新对象就会继续分配到Eden区里，这样只有Eden区和一块Survivor区里是有对象的，其中Survivor区里放的是上一次Minor GC后存活的对象。新生代的垃圾回收就是这样来回倒腾的。

所以1G内存的新生代，平时可以使用的，就是Eden区和其中一块Survivor区，那么相当于有900MB的内存是可以使用。

这么做最大的好处，就是只有10%的内存空间是被闲置的，90%的内存都被用上了。新生代对象存活期很短，存活的对象也很少，所以survivor分配的区域也比较小。

对象何时进入老年代？

对象一般优先分配在年轻代，那么何时进入老年代呢？有这几种情况：

• 躲过15次垃圾回收后

具体多少岁进入老年代，可以通过JVM参数-XX:MaxTenuringThreshold来设置，默认是15岁。

• 动态年龄判断
  

他的大致规则就是，假如说当前存放对象的Survivor区域里，一批对象的总大小大于了这块Survivor区域的内存大小的50%，那么此时大于等于这批对象年龄的对象，就可以直接进入老年代了。

规则看起来比较晦涩，通俗理解就是：年龄1 年龄2 年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会把年龄n以上的对象都放入老年代。

• 大对象直接进入老年代

多大对象算大对象，可以通过JVM参数“-XX:PretenureSizeThreshold”来设置，可以把它的值设置为字节数，比如“1048576”字节，就是1MB。

之所以这么做，就是要避免新生代里出现那种大对象，屡次躲过GC，还得把他在两个Survivor区域里来回复制多次之后才能进入老年代，

• Minor GC后对象太多Survivor放不下，把这些对象直接转移到老年代去

有可能Eden区垃圾回收后，存活的对象太多，survivor放不下只能转移到老年代去。

空间分配担保机制

在发生Minor GC之前，JVM会先检查一下老年代最大可用的连续内存空间，是否大于新生代所有对象的总大小。

因为极端的情况下，可能新生代Minor GC过后，存活对象太多了，survivor放不下。

如果说发现老年代的内存大小是大于新生代所有对象的，此时就可以放心大胆的对新生代发起一次Minor GC了，因为即使Minor GC之后所有对象都存活，Survivor区放不下了，也可以转移到老年代去。

如果Minor GC之后新生代的对象全部存活下来，然后全部需要转移到老年代去，但是老年代空间又不够怎么办？

那么就要看看老年代的内存大小，是否大于之前每一次Minor GC后进入老年代的对象的平均大小。

如果老年代连续空闲空间大于新生代对象总大小，或者大于之前每一次Minor GC后进入老年代对象平均大小，就只触发Minor GC，否则就要触发Full GC。

假如此时进行Minor GC也有几种可能：

（1）Minor GC过后，剩余的存活对象的大小，是小于Survivor区的大小的，那么此时存活对象进入Survivor区域即可。

（2）Minor GC过后，剩余的存活对象的大小，是大于 Survivor区域的大小，但是是小于老年代可用内存大小的，此时就直接进入老年代即可。

（3）Minor GC过后，剩余的存活对象的大小，大于了Survivor区域的大小，也大于了老年代可用内存的大小。此时老年代都放不下这些存活对象了，就会发生Handle Promotion Failure的情况，这个时候就会触发一次Full GC。

如果要是Full GC过后，老年代还是没有足够的空间存放Minor GC过后的剩余存活对象，那么此时就会导致所谓的“OOM”内存溢出异常了。

这段规则有点绕，所以必须画个图梳理下：

图5 空间担保机制

另外需要注意的是，上面描述的空间担保机制是jdk6以后的，与java6之前稍稍不同。

总结下，老年代触发垃圾回收的时机：

（1）Minor GC之前，发现很可能Minor GC之后要进入老年代的对象太多了，老年代放不下，此时需要提前触发Full GC然后再带着进行Minor GC；

（2）Minor GC之后，发现剩余对象太多，老年代都放不下了。

老年代回收，一般使用的标记整理算法，首先标记出来老年代当前存活的对象。

接着会让这些存活对象在内存里进行移动，把存活对象尽量都挪动到一起去，让存活对象紧凑的靠在一起，避免垃圾回收过后出现过多的内存碎片，然后再一次性把垃圾对象都回收掉。

总结：

老年代存活对象比较多，存活对象比较大，所以老年代垃圾回收算法的速度至少比新生代的垃圾回收算法的速度慢10倍。

如果系统频繁出现老年代的Full GC垃圾回收，会导致系统性能被严重影响，出现频繁卡顿的情况。

所以所谓JVM优化，就是尽可能让对象都在新生代里分配和回收，尽量别让太多对象频繁进入老年代，避免频繁对老年代进行垃圾回收，同时给系统充足的内存大小，避免新生代频繁的进行垃圾回收。