JVM学习-堆空间(三)

JVM在进行GC时，并非每次都对新生代、老年代、方法区(元空间)三个区域一起回收，大部分时间回收的都是新生代
针对Hotspot VM的实现，它里面的GC按照回收区域分两大类型：一种是部分收集(Partial GC)，一种是整堆收集(Full GC)

部分收集：不是完整收集整个Java堆的垃圾收集
- 新生代收集(Minor GC/Young GC)只回收新生代(Eden、S0,S1)
- 老年代收集(Major GC/Old GC)只回收老年代
  - 目前只有CMS GC会有单独收集老年代的行为
  - 注：很多时候Major GC和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收
- 混合收集：收集整个新生代和部分老年代的垃圾收集
  - 目前，只有G1 GC有这种行为
整堆收集：收集整个java堆和方法区的垃圾收集

年轻代GC(Minor GC)触发机制

当年轻代空间不足时，就会触发Minor GC，年轻代满指的是Eden区满，Survior满不会引发GC(每次Minor GC会清理年轻代的内存)
因为Java对象大多具备朝生夕死的特性，所以Minor GC非常频繁，一般回收速度比较快
Minor GC会引发STW(Stop The World)，暂停其它用户线程，等垃圾回收结束，用户线程才恢复执行

老年代GC(Major GC/Full GC)触发机制

指发生在老年代的GC，对象从老年代消失时，Major GC或Full GC发生
出现了Major GC，经常会伴随至少一次的Minor GC(非绝对，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程)
- 老年代空间不足时，会先触发Minor GC，如果之后空间还不足，则触发Major GC
Major GC的速度一般比Minor GC慢10倍以上，STW的时间更长
如果Major GC后，内存还不足，报OOM

Full GC触发机制

调用System.gc()时，系统建议执行Full GC，不必须执行
老年代空间不足
方法区空间不足
通过Minor GC后进入老年代的平均大小大于老年代的可用内存
由Eden区、survivor space0(From space)区向survivor space1(To space)区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小
注：Full GC是开发或调优中尽量避免的

/**
 * Administrator
 * 2024/5/18
 * 测试Minor GC，Major GC,Full GC
 * 执行参数 -Xms512m -Xmx512m -XX:+PrintGCDetails
 */
public class GCTest {
    public static void main(String[] args) {
        int i = 0;
        try {
            List<String> list = new ArrayList<>();
            String str = "lotus.com";
            while (true) {
                list.add(str);
                str += str;
                i++;
            }
        } catch (Throwable t) {
            t.printStackTrace();
            System.out.println("遍历次数：" + i);
        }
    }
}

//执行结果
[GC (Allocation Failure) [PSYoungGen: 117623K->20420K(153088K)] 117623K->74572K(502784K), 0.0395143 secs] [Times: user=0.03 sys=0.03, real=0.05 secs] 
[GC (Allocation Failure) [PSYoungGen: 133555K->1908K(153088K)] 408891K->314108K(502784K), 0.0160892 secs] [Times: user=0.08 sys=0.00, real=0.02 secs] 
[Full GC (Ergonomics) [PSYoungGen: 1908K->0K(153088K)] [ParOldGen: 312200K->221844K(349696K)] 314108K->221844K(502784K), [Metaspace: 3492K->3492K(1056768K)], 0.0218373 secs] [Times: user=0.16 sys=0.00, real=0.02 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(153088K)] 221844K->221844K(502784K), 0.0010237 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(153088K)] [ParOldGen: 221844K->221826K(349696K)] 221844K->221826K(502784K), [Metaspace: 3492K->3492K(1056768K)], 0.0046937 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
遍历次数：22
Heap
 PSYoungGen      total 153088K, used 6522K [0x00000000f5580000, 0x0000000100000000, 0x0000000100000000)
  eden space 131584K, 4% used [0x00000000f5580000,0x00000000f5bde8c0,0x00000000fd600000)
  from space 21504K, 0% used [0x00000000fd600000,0x00000000fd600000,0x00000000feb00000)
  to   space 21504K, 0% used [0x00000000feb00000,0x00000000feb00000,0x0000000100000000)
 ParOldGen       total 349696K, used 221826K [0x00000000e0000000, 0x00000000f5580000, 0x00000000f5580000)
  object space 349696K, 63% used [0x00000000e0000000,0x00000000ed8a08f0,0x00000000f5580000)
 Metaspace       used 3525K, capacity 4502K, committed 4864K, reserved 1056768K
  class space    used 391K, capacity 394K, committed 512K, reserved 1048576K
java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3332)
	at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
	at java.lang.StringBuilder.append(StringBuilder.java:136)
	at com.chapter06.GCTest.main(GCTest.java:19)

堆空间分代思想

经研究，不同对象的生命周期不同，70%-99%对象是临时对象

新生代：有Eden、两块大小相同的Survivor(又称为from/to,s0/s1)构成，to总为空
老年代：存放新生代中经历多次GC仍然存活的对象

为什么需要把Java堆分代？不分代不能正常工作吗？

其实不分代完全可以，分代的唯一理由就是优化GC性能，如果没有分代，那所有的对象都在一块，就如同把学校的所有人关在一个教室，GC的时候要找到哪些对象没用，这样就会对全堆所有区域进行扫描，而很多对象朝生夕死，如果分代的话，新创建的对象放在某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，就会腾出很大空间

内存分配策略

如果对象在Eden出生并经过第一次MinorGC后仍然存活，并且能被Survior容纳的话，将被移动到Survivor空间中，并将对象年龄设置为1，对象在Survivor区中每熬过一次MinorGC，年龄就加1岁，当它的年龄增加到一定程度(默认15岁，其实每个JVM，每个GC都有所不同)时，会被晋升到老年代中

对象晋升老年代的年龄阈值，可以通过选项 -XX:MaxTenuringThreshold来设置
针对不同年龄对象分配原则如下：

优先分配到Eden
大对象直接分配到老年代
- 尽量避免程序中出现过多大对象
长期存活的对象分配到老年代
动态对象年龄判断
- 如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄
空间分配担保
- -XX:HandlePromotionFailure

//测试大对象直接进入老年代
/**
 * Administrator
 * 2024/5/18
 * -Xms60m -Xmx60m -XX:+PrintGCDetails -XX:NewRatio=2 -XX:SurvivorRatio=8
 */
public class YoungOldAreaTest {
    public static void main(String[] args) {
        byte[] buffer = new byte[1024*1024*20];
    }
}
//执行结果
Heap
 PSYoungGen      total 18432K, used 2624K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
  eden space 16384K, 16% used [0x00000000fec00000,0x00000000fee90218,0x00000000ffc00000)
  from space 2048K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x0000000100000000)
  to   space 2048K, 0% used [0x00000000ffc00000,0x00000000ffc00000,0x00000000ffe00000)
 ParOldGen       total 40960K, used 20480K [0x00000000fc400000, 0x00000000fec00000, 0x00000000fec00000)
  object space 40960K, 50% used [0x00000000fc400000,0x00000000fd800010,0x00000000fec00000)
 Metaspace       used 3496K, capacity 4498K, committed 4864K, reserved 1056768K
  class space    used 387K, capacity 390K, committed 512K, reserved 1048576K

对象分配过程(TLAB)

从内存模型而不是垃圾收集的角度，对Eden区域继续进行划分，JVM为每个线程分配了一个私有缓存区域，它包含在Eden空间内
多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称为快速分配策略
据我所知所有OpenJDK衍生出来的JVM都提供了TLAB的设计

为什么要有TLAB(Thread Local Allocation Buffer)

堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据
由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区划分内存空间是线程不安全的
为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度
尽管不是所有的对象实例都能够在TLAB中成功分配内存，但JVM确实是将TLAB作为内存分配的首选
在程序中，开发人员可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间
默认情况下，TLAB空间内存非常小，仅占有整个Eden空间的1%，当然我们可以通过选项“-XX:TLABWasteTargetPercent”设置TLAB空间所占用Eden空间的百分比大小
一旦对象在TLAB空间分配内存失败时，JVM就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在Eden空间中分配内存