young GC 和 full GC分别是什么？ 对象什么时候在栈上分配？对象进入老年代的机制是怎样的？

很长时间没有更新了，不是偷懒了，是偷偷学习了。我呢把我比较感兴趣的部分，复述一遍，当然会有错误。并不是权威，希望大家指正，共同进步。

---

前言

其实整个JVM参数的调优，大体上就是围绕着如何去减少垃圾回收的次数。尽可能地不要让full GC发生。因为不管是哪一种垃圾收集器，都会有STW（Stop The Word）发生，就会影响用户体验。因此本次呢是先和大家一起学习下对象的分配规则，了解young GC 和 full GC分别是什么，有何种关系，以及对象进入老年代的一些机制等等。

一、对象在栈上分配

当创建出来的对象没有被引用的时候就变成了垃圾，需要依靠GC进行回收，去释放堆内存，如果对象数量较多的时候，会给GC带来较大压力，也间接影响了应用的性能。
为了减少临时对象在堆内分配的数量，JVM通过逃逸分析确定该对象不会被外部访问。如果不会逃逸可以将该对象在栈上分配内存，这样该对象所占用的内存空间就可以随栈帧出栈而销毁，就减轻了垃圾回收的压力。
对象逃逸分析： 就是分析对象动态作用域，当一个对象在方法中被定义后，它可能被外部方法所引用，则说明该对象会逃逸，不能让它跟着栈帧一起销毁。

成功逃逸：

public User getUser(){
        User u = new User();
        return u;
    }

User对象通过return传出这个方法外，显然这个对象的作用域范围不确定，就得在堆上创建了。

逃逸失败：

public User getUser(){
        User u = new User();
    }

可以确定当方法结束这个User对象就是无效对象了，对于这样的对象可以将其分配在栈内存里，让其在方法结束时跟随栈内存一起被回收掉。
当然，这个功能是可配置的，不喜欢你可以不要，恨了你可以抛弃。
JVM对于这种情况可以通过开启逃逸分析参数

(-XX:+DoEscapeAnalysis)

来优化对象内存分配位置，使其通过标量替换优先分配在栈上(栈上分配)，JDK7之后默认开启逃逸分析，关闭使用参数

( -XX:-DoEscapeAnalysis)

标量替换： 通过逃逸分析确定该对象不会被外部访问，并且对象可以被进一步分解时，JVM不会创建该对象，而是将该对象成员变量分解若干个被这个方法使用的成员变量所代替，这些代替的成员变量在栈帧或寄存器上分配空间，这样就不会因为没有一大块连续空间导致对象内存不够分配。

开启标量替换参数(**-XX:+EliminateAllocations**)，JDK7之后默认开启。

标量与聚合量： 标量即不可被进一步分解的量，而JAVA的基本数据类型就是标量（如：int，long等基本数据类型以及reference类型等），标量的对立就是可以被进一步分解的量，而这种量称之为聚合量。而在JAVA中对象就是可以被进一步分解的聚合量。

二、对象在EDEN分配

有的人一定和我一样，看到EDEN这个名词就很陌生，这什么鬼，这什么东西。其实就是堆中给分配的一块区域。前面说了对象分配在栈上，如果不被分配到栈上那就只能分配在堆里了。那么EDEN又是堆中的…的…区域。

（妈的，…什么鬼？）
先请你看一下这张图，这是堆中新生代的的区域，你也可以说是年轻代。对立面就是老年代了，简单地理解一下，年轻代嘛，放年轻的对象（刚创建的对象），老年代就放创建比较久的对象。那么为什么要做这样的区分？ 这个后面3.2做出了解释。下面会说到什么样的算创建比较久的对象，或者说年龄比较大的对象。

那么，在新生代中，又分有EDEN区和两个survivor区，Eden与Survivor区默认8:1:1。为什么是

因为新生代的对象几乎都是朝生夕死的（创建完很快就没用了），存活时间很短，所以JVM默认的8:1:1的比例是很合适的，让eden区尽量的大，survivor区够用即可，JVM默认有这个参数

-XX:+UseAdaptiveSizePolicy

(默认开启)，会导致这个8:1:1比例自动变化，如果不想这个比例有变化可以设置参数

-XX:-UseAdaptiveSizePolicy

三、 minor GC 和 full GC

minor GC: 当大量的对象被分配在eden区，eden区满了年轻代就会触发垃圾回收 - minor gc（，可能会有99%以上的对象成为垃圾被回收掉，剩余存活的对象会被挪到为空的那块survivor区，下一次eden区满了后又会触发minor gc，把eden区和上一次用到的survivor区垃圾对象回收，把剩余存活的对象一次性挪动到另外一块为空的survivor区，以此循环，使得整个年轻代的空间可以重复使用。

full GC: 有没有可能一个survivor区装不下依然存活的对象，那么默认需要存活的对象超过survivor区的一半，就会将这些对象提前转移到老年代。而老年代空间存满之后发生的垃圾回收就叫做full GC

区域	GC	速度
年轻代	minor GC	快
老年代	full GC	慢

其实JVM调优部分参数也是围绕着一个问题，如何尽量减少提前送养老的事情发生，因为 minor gc 是比较快的多得多的一种垃圾回收。一直送到老年代的话，老年代满了是需要full GC的，这是比较慢的，会影响性能。

四、 对象进入老年代

3.1大对象直接进入老年代

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。
JVM参数

 -XX:PretenureSizeThreshold 

可以设置大对象的大小，如果对象超过设置大小会直接进入老年代，不会进入年轻代，这个参数只在 Serial 和 ParNew两个收集器下有效。
比如设置JVM参数：

-XX:PretenureSizeThreshold=1000000 (单位是字节) -XX:+UseSerialGC 

应该有人会问，为什么要直接进入老年代。刚才不还是说尽量减少对象提前送到老年代么？这怎么不等minor GC 就直接送进老年代了呢？
试想一下，如果好几个大对象生成在年轻代，且在minor GC时，都还存在，大小一下子就超过了survivor区得一半，这样就会带着这几个大对象以及其他存活得对象一起到老年代。显然，如果提前把大块头送走，其他对象有可能不会超过一半就不用送到老年代了。

3.2长期存活的对象将进入老年代

虚拟机采用分代得思想分配内存，这种思想的目的是，有的对象存活比较久甚至永远存在，这类对象每次参与GC的筛选等一系列操作，显然也会占用一定的时间，所以这类对象放在老年代也省去了一直在复制到survivor区的动作可以提高性能，减少折腾。

那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。

如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor空间中，并将对象年龄设为1。对象在 Survivor 中每熬过一次 MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，CMS收集器默认6岁，不同的垃圾收集器会略微有点不同），就会被晋升到老年代中（想想我要65岁才能退休，太惨了吧，我可以也15岁退休吗？）。
对象晋升到老年代的年龄阈值，可以通过参数 来设置。

 -XX:MaxTenuringThreshold 

3.3对象动态年龄判断

Survivor区域里现在有一批对象，年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，
这个百分比有参数可以指定

-XX:TargetSurvivorRatio

此时就会把年龄n(含)以上的对象都放入老年代。
这个规则其实是希望那些可能是长期存活的对象，尽早进入老年代。这有什么好处呢，就不用一股脑，超过50%，就把年轻的老的全抓去养老院。这样养老院也不会那么容易满就不容易导致full GC的发生。

3.4老年代空间分配担保机制

年轻代每次minor gc之前JVM都会计算下老年代剩余可用空间
如果这个可用空间小于年轻代里现有的所有对象大小之和(包括垃圾对象)
就会看老年代的可用内存大小，是否大于之前每一次minor gc后进入老年代的对象的平均大小。
如果上一步结果是小于或者之前说的参数没有设置，那么就会触发一次Full gc，对老年代和年轻代一起回收一次垃圾。

如果回收完还是没有足够空间存放新的对象就会发生"OOM"
当然，如果minor gc之后剩余存活的需要挪动到老年代的对象大小还是大于老年代可用空间，那么也会触发full gc，fullgc完之后如果还是没有空间放minor gc之后的存活对象，则也会发生“OOM”
老年代空间分配担保机制可以通过参数配置是否生效

-XX:-HandlePromotionFailure

(jdk1.8默认就设置了)

五、 对象头

这里想给大家看一下对象头的一张表，暂时只先看下这张图里的这个分代年龄，也就是说每个对象前面都跟着头部，去记录它的状态，我们前面提到的对象年龄就是它每经历一次minor GC 分代年龄就会+1.这个对象头的内容，我想，慢慢的在每次用到的时候介绍一点，会更容易接受吧，因此这一次就介绍这么个分代年龄好了。

好了，我的笔记结束，下期再见！