JVM运行时数据区-堆

在HotSpot中，Eden空间和另外两个Survivor空间缺省所占的比例是：8:1:1
- -XX:SurvivorRatio调整这个空间比例
Eden与Survivor区的比例
- 实际是6:1:1，因为有自适应机制
  - -XX:-UseAdaptiveSizePolicy：-表示关闭自适应，实际没有用。直接用Ratio分配即可

几乎所有的Java对象都是在Eden区被new出来的。

Eden放不了的大对象，直接进入老年代了。

IBM研究表明，新生代80%的对象都是朝生夕死

-Xmn：洗面奶，设置新生代最大内存大小，如果同时设置了新生代比例与此参数冲突，则以此参数为准。

hotspot为什么要分为新生代和老年代？

因为分代的唯一理由就是优化GC的性能。大多数的对象都是朝生夕死，如果没有进行分代，那所有的对象都在一块，GC的时候要找到哪些对象可以回收就需要对所有对象都进行扫描，性能开销较大。而如果分代的话，新创建的对象放到某一地方，当GC的时候先把这块存储"朝生夕死"对象的区域进行回收，这样就能够以较高的效率释放空间。

设置比例不同可能导致的结果

1）新生代设置过小

一是新生代GC次数非常频繁，增大系统消耗；二是导致大对象直接进入旧生代，占据了旧生代剩余空间，诱发Full GC

2）新生代设置过大

一是新生代设置过大会导致老年代过小（堆总量一定），从而诱发Full GC；二是新生代GC耗时大幅度增加

一般说来新生代占整个堆1/3比较合适

3）Survivor设置过小

导致对象从eden直接到达旧生代，降低了在新生代的存活时间

4）Survivor设置过大

导致eden过小，增加了GC频率

另外，通过-XX:MaxTenuringThreshold=n来控制新生代存活时间，尽量让对象在新生代被回收

四、图解对象分配一般过程

1、new的对象先放在Eden区，此区有大小限制

2、当创建新对象，Eden空间填满时，会触发Minor GC，将Eden不再被其他对象引用的对象进行销毁。再加载新的对象放到Eden区

3、将Eden中剩余的对象移到幸存者0区

4、再次触发垃圾回收，此时上次幸存者下来的，放在幸存者0区的，如果没有回收，就会放到幸存者1区

5、再次经历垃圾回收，又会将幸存者重新放回幸存者0区，依次类推

6、可以设置一个次数，默认是15次，超过15次，则会将幸存者区幸存下来的转去老年区

-XX:MaxTenuringThreshold=N进行设置

总结：

针对幸存者s0，s1区的总结：复制之后有交换，谁空谁是to

频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间搜集

五、对象分配特殊过程

触发YGC，幸存者区就会进行回收，不会主动进行回收

超大对象eden放不下，就要看Old区大小是否可以放下。如果Old区放得下，就直接放到Old区。如果也放不下，需要FullGC（MajorGC），这两GC概念还是有区别的。下面详解

六、常用调优工具

JDK命令行
Eclipse：Memory Analyzer Tool
Jconsole
VisualVM
Jprofiler
Java Flight Recorder

七、MinorGC，MajorGC，FullGC

针对 HotSpot VM 的实现，它里面的 GC 其实准确分类只有两大种：

部分收集 (Partial GC)：

新生代收集（Minor GC / Young GC）：只对新生代进行垃圾收集；
老年代收集（Major GC / Old GC）：只对老年代进行垃圾收集。需要注意的是 Major GC 在有的语境中也用于指代整堆收集；
混合收集（Mixed GC）：对整个新生代和部分老年代进行垃圾收集。

整堆收集 (Full GC)：收集整个 Java 堆和方法区。

（一）MinorGC的触发条件

当年轻代空间不足时，就会触发MinorGC，这里的年轻代指的是Eden满，Survivor满不会触发GC。每次MinorGC会清理年轻代的内存

因为Java对象大多朝生夕灭，所以MinorGC非常频繁。MinorGC会引发STW（stop the world即停止用户线程，让GC线程运行）

（二）老年代GC（MajorGC/FullGC）触发条件

指发生在老年代的GC，对象从老年代消失，我们说"MajorGC""FullGC"发生了

出现了MajorGC，经常会伴随至少一次MinorGC

但是并非绝对，在Parallel Scavenge收集器的收集策略里就直接进行MajorGC的策略选择过程，也就是老年代空间不足，会先尝试触发MinorGC，如果之后空间还不足，则触发MajorGC

MajorGC的速度比MinorGC慢10倍以上，STW的时间更长

如果MajorGC后，内存还不足，就报OOM了

（三）FullGC的触发条件

1、调用System.gc()时，系统建议执行FullGC，但是不必然执行

2、老年代空间不足

3、方法区空间不足

4、通过MinorGC后进入老年代的平均大小，大于老年代的可用内存

5、由Eden区，Survivor 0区向Survivor 1区复制时，对象的大小大于ToSpace可用内存，则把改对象转存到老年代，且老年代的可用内存小于该对象的大小

FullGC是开发或调优中尽量要避免的，这样暂停时间会短一些。

八、内存分配策略

1、如果对象再Eden出生并经过第一次MinorGC后仍然存活，并且能被Survivor区容纳，则被移动到Survivor空间中，并将对象年龄设置为1，对象再Survivor区每熬过一次MinorGC，年龄就+1，当年龄增加到一定程度（默认为15，不同Jvm，GC都所有不同）时，就会被晋升到老年代中

可以通过参数 -XX:MaxTenuringThreshold 设置阈值

2、如果大对象Eden放不下，会直接分配到老年代

我们应尽量避免程序中出现过多的大对象

3、动态对象年龄分配

如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄

4、空间分配担保机制

在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间，是否大于新生代所有对象的总空间
- 如果大于，则此次MinorGC是安全的
- 如果小于，则查看-XX:HandlePromotionFailure设置是否允许担保失败
  - true
    - 会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小
    - 大于，则尝试进行一次MinorGC，但是这次MinorGC依然是有风险的
    - 小于，则改为进行一次FullGC
  - false
    - 则改为进行一次FullGC
jdk6update24之后，这个参数不会再影响到虚拟机的空间分配担保策略。规则改为只要老年代的连续空间大于新生代对象总大小，或者历次晋升的平均大小，就会进行MinorGC；否则进行FullGC

通过 -XX:HandlePromotionFailure=true/false 进行设置是否允许担保失败

九、为对象分配内存TLAB

堆区是线程共享区域，任何线程都可以访问到堆区的共享数据。由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的。为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。

于是TLAB(Thread Local Allocation Buffer)出现了

从内存模型而不是垃圾收集的角度，对Eden区域进行划分，JVM为每个线程分配了一个私有缓存区域，包含在Eden空间中

多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们将这种内存分配方式称为快速分配策略

1、尽管不是所有的对象实例都能够在TLAB中成功分配内存，但是JVM确实是将TLAB作为内存分配的首选

2、开发人员通过-XX:UseTLAB设置是否开启TLAB空间

3、默认情况下，TLAB空间内存非常小，仅占有整个Eden空间的1%，通过-XX:TLABWasteTargetPercent设置TLAB空间所占用Eden空间的百分比大小

4、一旦对象在TLAB空间分配内存失败，JVM就会尝试通过使用加锁机制确保数据操作的原子性，从而直接在Eden空间中分配内存