本文原创,内容结合视频 黑马程序员JVM完整教程,Java虚拟机快速入门,全程干货不拖沓_哔哩哔哩_bilibili 和 周志明 - 《深入理解Java虚拟机》而作,同步发于个人博客:JVM-垃圾回收篇 - Karos (wzl1.top) 与 腾讯云开发者社区:JVM-垃圾回收篇笔记 - 腾讯云开发者社区-腾讯云 (tencent.com),部分图片来源已添加链接 垃圾回收
早期Python虚拟机采用
当对象被引用时,引用计数器++,取消引用时--
无法解决问题:相互循环引用
通过一系列成为GC Roots的根对象作为起始节点集,从GCRoots开始向下搜索,搜索的路径为”引用链“,如果没有引用链,也就是不可达,说明对象不可能再被使用
在Java技术体系中,固定可作为GCRoots的对象包括:
jmap -dump:format=b,live,file=11.bin
强、软(SoftReference)、弱(WeakReference)
软引用:
必须配合引用队列:虚(PPhantomRefernce)、终结(FinalReference)
终结:使用finallize方法
利用可达性算法,不可达进行第一次标记。
标记后进行筛选:是否有必要执行finalize()方法,如果没有重写或者已经被调用过,那么就视为没有必要执行
如果有必要执行,那么会放入一个F-Queued的队列(引用队列)中,并在稍后由一条由虚拟机自动建立的,低调度优先级的Finalizer线程去执行他们的finalize()方法。
为了防止出现阻塞,F-Queue不会等待方法执行结束,否则会让其他对象永久处于等待,造成内存回收子系统 崩溃。
如果finalize()成功执行,重新于引用链上任一对象建立关系即可:比如把this赋值给某个类变量或者对象的成员变量,那么在第二次标记时,他将会被移出”即将回收“的集合。如果此时对象仍然没有逃脱,那么就要被回收了。
Systen.gc()还是系统自动回收,都只会调用一次finalize()方法
主要回收两个内容:废弃常量和不再使用类型。
判断一个常量是否废弃相对简单:该常量曾经进入常量池中,但现在又没有一个对象的值和该常量相同,也就是说没有对象引用该常量,且虚拟机中也没有其他地方引用该字面量,则该常量可以被垃圾回收,清理出常量池。
类、方法、字段的符号引用也类似。
但是判断一个类是否废弃需要满足下面三个条件:
对于是否被零星回收,HotSpot提供了 -Xnoclassgc 参数进行控制,还可以使用 -XX:+TraceClassLoading、-XX:TraceClassUnLoading查看类加载和写在信息(前两个可以在Product版JVM中使用,最后一种需要FastDebug版的JVM支持)。
根据对象生命周期的不同特点分为新生代和老年代
新生代:处理不常用的对象
老年代:处理常用的对象
在新生代中,每次垃圾收集时都发现有大批对象死去,而每次回收后存活的少量对象将会逐步晋升到老年代释放
新创建的对象选择伊甸园空间
当伊甸园空间满了以后会进行垃圾护手,新生代的垃圾回收叫做Minor GC,回收后将存活对象赋值到幸存区,并将寿命+1
再将to和form交换指向位置
在第一次的回收基础上,对幸存区的某一个进行取消引用
此时to中的1已经被取消引用,所以直接删除
最后from和to交换位置、放入新对象
当年龄达到一定阙值后放入老年代
当新生代内存不够时,会尝试促发FullGC进行老年代的垃圾回收,准确来说是整个堆空间
-Xms20M -Xmx20M -Xmn10M -XX:+UseSerialGC -XX:+PrintGCDetails -verbose:gc
代码:
package org.example;
import java.io.IOException;
public class Main {
public static int a=5;
public static void main(String[] args) throws InterruptedException {
Thread.sleep(10000000000l);
return ;
}
}
E:F:T=8:1:1,其中T默认是已使用内存
既然刚启动,那为什么EdenSpace会有占用呢?
思考:当new的对象占用内存如果超过了幸存区内存会发生什么?内存溢出?动态占比分配? 试验代码:
package org.example;
import java.io.IOException;
import java.lang.reflect.Array;
import java.util.ArrayList;
public class Main {
public static int a=5;
public static void main(String[] args) throws InterruptedException, IOException {
System.in.read();
ArrayList bytes=new ArrayList<>();
System.out.println("添加对象中");
bytes.add(new byte[1024*1024*5]);
bytes.forEach(System.out::println);
System.in.read();
bytes.add(new byte[1024*1024*5]);
bytes.forEach(System.out::println);
System.in.read();
bytes.add(new byte[1024*1024*5]);
bytes.forEach(System.out::println);
bytes.add(new byte[1024*1024*5]);
bytes.forEach(System.out::println);
return ;
}
}
结果:
D:\Program\jdk\bin\java.exe -Xms20M -Xmx20M -Xmn10M -XX:+UseSerialGC -XX:+PrintGCDetails -verbose:gc "-javaagent:D:\Program\IntelliJ IDEA 2022.3.1\lib\idea_rt.jar=61656:D:\Program\IntelliJ IDEA 2022.3.1\bin" -Dfile.encoding=UTF-8 -classpath H:\JVM\gc\target\classes org.example.Main
[0.003s][warning][gc] -XX:+PrintGCDetails is deprecated. Will use -Xlog:gc* instead.
[0.010s][info ][gc] Using Serial
[0.010s][info ][gc,init] Version: 17.0.1+12-39 (release)
[0.010s][info ][gc,init] CPUs: 8 total, 8 available
[0.010s][info ][gc,init] Memory: 13810M
[0.010s][info ][gc,init] Large Page Support: Disabled
[0.010s][info ][gc,init] NUMA Support: Disabled
[0.010s][info ][gc,init] Compressed Oops: Enabled (32-bit)
[0.010s][info ][gc,init] Heap Min Capacity: 20M
[0.010s][info ][gc,init] Heap Initial Capacity: 20M
[0.010s][info ][gc,init] Heap Max Capacity: 20M
[0.010s][info ][gc,init] Pre-touch: Disabled
[0.010s][info ][gc,metaspace] CDS archive(s) mapped at: [0x0000000800000000-0x0000000800bc0000-0x0000000800bc0000), size 12320768, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0.
[0.011s][info ][gc,metaspace] Compressed class space mapped at: 0x0000000800c00000-0x0000000840c00000, reserved size: 1073741824
[0.011s][info ][gc,metaspace] Narrow klass base: 0x0000000800000000, Narrow klass shift: 0, Narrow klass range: 0x100000000
[10.160s][info ][gc,start ] GC(0) Pause Young (Allocation Failure)
[10.165s][info ][gc,heap ] GC(0) DefNew: 8192K(9216K)->1023K(9216K) Eden: 8192K(8192K)->0K(8192K) From: 0K(1024K)->1023K(1024K)
[10.165s][info ][gc,heap ] GC(0) Tenured: 0K(10240K)->1443K(10240K)
[10.165s][info ][gc,metaspace] GC(0) Metaspace: 2679K(2880K)->2679K(2880K) NonClass: 2400K(2496K)->2400K(2496K) Class: 279K(384K)->279K(384K)
[10.165s][info ][gc ] GC(0) Pause Young (Allocation Failure) 8M->2M(19M) 4.780ms
[10.165s][info ][gc,cpu ] GC(0) User=0.00s Sys=0.02s Real=0.01s
[10.384s][info ][gc,start ] GC(1) Pause Young (Allocation Failure)
[10.390s][info ][gc,heap ] GC(1) DefNew: 9215K(9216K)->482K(9216K) Eden: 8192K(8192K)->0K(8192K) From: 1023K(1024K)->482K(1024K)
[10.390s][info ][gc,heap ] GC(1) Tenured: 1443K(10240K)->2463K(10240K)
[10.390s][info ][gc,metaspace] GC(1) Metaspace: 4881K(5120K)->4881K(5120K) NonClass: 4357K(4480K)->4357K(4480K) Class: 523K(640K)->523K(640K)
[10.390s][info ][gc ] GC(1) Pause Young (Allocation Failure) 10M->2M(19M) 5.666ms
[10.390s][info ][gc,cpu ] GC(1) User=0.00s Sys=0.00s Real=0.01s
[26.252s][info ][gc,start ] GC(2) Pause Full (System.gc())
[26.252s][info ][gc,phases,start] GC(2) Phase 1: Mark live objects
[26.257s][info ][gc,phases ] GC(2) Phase 1: Mark live objects 5.380ms
[26.257s][info ][gc,phases,start] GC(2) Phase 2: Compute new object addresses
[26.259s][info ][gc,phases ] GC(2) Phase 2: Compute new object addresses 2.149ms
[26.259s][info ][gc,phases,start] GC(2) Phase 3: Adjust pointers
[26.262s][info ][gc,phases ] GC(2) Phase 3: Adjust pointers 3.118ms
[26.263s][info ][gc,phases,start] GC(2) Phase 4: Move objects
[26.263s][info ][gc,phases ] GC(2) Phase 4: Move objects 0.855ms
[26.264s][info ][gc,heap ] GC(2) DefNew: 8083K(9216K)->0K(9216K) Eden: 7600K(8192K)->0K(8192K) From: 482K(1024K)->0K(1024K)
[26.264s][info ][gc,heap ] GC(2) Tenured: 2463K(10240K)->3900K(10240K)
[26.264s][info ][gc,metaspace ] GC(2) Metaspace: 7956K(8256K)->7956K(8256K) NonClass: 7083K(7232K)->7083K(7232K) Class: 872K(1024K)->872K(1024K)
[26.264s][info ][gc ] GC(2) Pause Full (System.gc()) 10M->3M(19M) 12.256ms
[26.264s][info ][gc,cpu ] GC(2) User=0.02s Sys=0.00s Real=0.01s
添加对象中
[B@3b07d329
[49.675s][info ][gc,start ] GC(3) Pause Young (Allocation Failure)
[49.678s][info ][gc,heap ] GC(3) DefNew: 8192K(9216K)->35K(9216K) Eden: 8192K(8192K)->0K(8192K) From: 0K(1024K)->35K(1024K)
[49.678s][info ][gc,heap ] GC(3) Tenured: 3900K(10240K)->9020K(10240K)
[49.678s][info ][gc,metaspace ] GC(3) Metaspace: 8137K(8384K)->8137K(8384K) NonClass: 7263K(7360K)->7263K(7360K) Class: 874K(1024K)->874K(1024K)
[49.678s][info ][gc ] GC(3) Pause Young (Allocation Failure) 11M->8M(19M) 2.957ms
[49.678s][info ][gc,cpu ] GC(3) User=0.00s Sys=0.02s Real=0.00s
[96.458s][info ][gc,start ] GC(4) Pause Young (Allocation Failure)
[96.458s][info ][gc ] GC(4) Pause Young (Allocation Failure) 14M->14M(19M) 0.078ms
[96.458s][info ][gc,cpu ] GC(4) User=0.00s Sys=0.00s Real=0.00s
[96.458s][info ][gc,start ] GC(5) Pause Full (Allocation Failure)
[96.458s][info ][gc,phases,start] GC(5) Phase 1: Mark live objects
[96.467s][info ][gc,phases ] GC(5) Phase 1: Mark live objects 8.235ms
[96.467s][info ][gc,phases,start] GC(5) Phase 2: Compute new object addresses
[96.469s][info ][gc,phases ] GC(5) Phase 2: Compute new object addresses 2.466ms
[96.469s][info ][gc,phases,start] GC(5) Phase 3: Adjust pointers
[96.473s][info ][gc,phases ] GC(5) Phase 3: Adjust pointers 4.087ms
[96.473s][info ][gc,phases,start] GC(5) Phase 4: Move objects
[96.474s][info ][gc,phases ] GC(5) Phase 4: Move objects 0.946ms
[96.475s][info ][gc,heap ] GC(5) DefNew: 5571K(9216K)->0K(9216K) Eden: 5535K(8192K)->0K(8192K) From: 35K(1024K)->0K(1024K)
[96.475s][info ][gc,heap ] GC(5) Tenured: 9020K(10240K)->8999K(10240K)
[96.475s][info ][gc,metaspace ] GC(5) Metaspace: 8213K(8448K)->8092K(8448K) NonClass: 7339K(7424K)->7244K(7424K) Class: 874K(1024K)->848K(1024K)
[96.475s][info ][gc ] GC(5) Pause Full (Allocation Failure) 14M->8M(19M) 16.586ms
[96.475s][info ][gc,cpu ] GC(5) User=0.02s Sys=0.00s Real=0.02s
[B@3b07d329
[B@682a0b20
[96.477s][info ][gc,start ] GC(6) Pause Young (Allocation Failure)
[96.477s][info ][gc ] GC(6) Pause Young (Allocation Failure) 13M->13M(19M) 0.086ms
[96.477s][info ][gc,cpu ] GC(6) User=0.00s Sys=0.00s Real=0.00s
[96.477s][info ][gc,start ] GC(7) Pause Full (Allocation Failure)
[96.477s][info ][gc,phases,start] GC(7) Phase 1: Mark live objects
[96.485s][info ][gc,phases ] GC(7) Phase 1: Mark live objects 8.022ms
[96.485s][info ][gc,phases,start] GC(7) Phase 2: Compute new object addresses
[96.487s][info ][gc,phases ] GC(7) Phase 2: Compute new object addresses 1.451ms
[96.487s][info ][gc,phases,start] GC(7) Phase 3: Adjust pointers
[96.491s][info ][gc,phases ] GC(7) Phase 3: Adjust pointers 4.088ms
[96.491s][info ][gc,phases,start] GC(7) Phase 4: Move objects
[96.492s][info ][gc,phases ] GC(7) Phase 4: Move objects 0.856ms
[96.492s][info ][gc,heap ] GC(7) DefNew: 5217K(9216K)->5121K(9216K) Eden: 5217K(8192K)->5121K(8192K) From: 0K(1024K)->0K(1024K)
[96.492s][info ][gc,heap ] GC(7) Tenured: 8999K(10240K)->8962K(10240K)
[96.492s][info ][gc,metaspace ] GC(7) Metaspace: 8097K(8448K)->8028K(8448K) NonClass: 7247K(7424K)->7189K(7424K) Class: 849K(1024K)->838K(1024K)
[96.492s][info ][gc ] GC(7) Pause Full (Allocation Failure) 13M->13M(19M) 15.333ms
[96.492s][info ][gc,cpu ] GC(7) User=0.02s Sys=0.00s Real=0.02s
[96.492s][info ][gc,start ] GC(8) Pause Full (Allocation Failure)
[96.492s][info ][gc,phases,start] GC(8) Phase 1: Mark live objects
[96.498s][info ][gc,phases ] GC(8) Phase 1: Mark live objects 6.004ms
[96.498s][info ][gc,phases,start] GC(8) Phase 2: Compute new object addresses
[96.500s][info ][gc,phases ] GC(8) Phase 2: Compute new object addresses 1.182ms
[96.500s][info ][gc,phases,start] GC(8) Phase 3: Adjust pointers
[96.504s][info ][gc,phases ] GC(8) Phase 3: Adjust pointers 4.837ms
[96.505s][info ][gc,phases,start] GC(8) Phase 4: Move objects
[96.507s][info ][gc,phases ] GC(8) Phase 4: Move objects 2.185ms
[96.507s][info ][gc,heap ] GC(8) DefNew: 5121K(9216K)->5121K(9216K) Eden: 5121K(8192K)->5121K(8192K) From: 0K(1024K)->0K(1024K)
[96.507s][info ][gc,heap ] GC(8) Tenured: 8962K(10240K)->8450K(10240K)
[96.507s][info ][gc,metaspace ] GC(8) Metaspace: 8028K(8448K)->8028K(8448K) NonClass: 7189K(7424K)->7189K(7424K) Class: 838K(1024K)->838K(1024K)
[96.507s][info ][gc ] GC(8) Pause Full (Allocation Failure) 13M->13M(19M) 14.864ms
[96.507s][info ][gc,cpu ] GC(8) User=0.02s Sys=0.00s Real=0.02s
[96.509s][info ][gc,heap,exit ] Heap
[96.509s][info ][gc,heap,exit ] def new generation total 9216K, used 5405K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
[96.509s][info ][gc,heap,exit ] eden space 8192K, 65% used [0x00000000fec00000, 0x00000000ff1475c8, 0x00000000ff400000)
[96.509s][info ][gc,heap,exit ] from space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
[96.509s][info ][gc,heap,exit ] to space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
[96.509s][info ][gc,heap,exit ] tenured generation total 10240K, used 8450K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
[96.509s][info ][gc,heap,exit ] the space 10240K, 82% used [0x00000000ff600000, 0x00000000ffe40b90, 0x00000000ffe40c00, 0x0000000100000000)
[96.509s][info ][gc,heap,exit ] Metaspace used 8034K, committed 8448K, reserved 1056768K
[96.509s][info ][gc,heap,exit ] class space used 839K, committed 1024K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at org.example.Main.main(Main.java:21)
进程已结束,退出代码1
最开始放到新生代,但是当继续new的时候,直接放入了老年代. 重复实验,发现如果幸存区空间充足,对象会放入幸存区并且延寿,否则直接将待延寿对象晋升到老年代,当老年代空间不足时,抛出oom异常.
package org.example;
import java.io.IOException;
import java.lang.reflect.Array;
import java.util.ArrayList;
public class Main {
public static int a=5;
public static void main(String[] args) throws InterruptedException, IOException {
System.in.read();
ArrayList bytes=new ArrayList<>();
System.out.println("添加对象中");
bytes.add(new byte[1024*1024*5]);
bytes.forEach(System.out::println);
System.in.read();
bytes.add(new byte[1024*1024*8]);
}
}
添加对象中
[B@3b07d329
[34.804s][info ][gc,start ] GC(4) Pause Young (Allocation Failure)
[34.806s][info ][gc,heap ] GC(4) DefNew: 8192K(9216K)->14K(9216K) Eden: 8192K(8192K)->0K(8192K) From: 0K(1024K)->14K(1024K)
[34.806s][info ][gc,heap ] GC(4) Tenured: 3897K(10240K)->9017K(10240K)
[34.806s][info ][gc,metaspace ] GC(4) Metaspace: 8072K(8320K)->8072K(8320K) NonClass: 7196K(7296K)->7196K(7296K) Class: 875K(1024K)->875K(1024K)
[34.806s][info ][gc ] GC(4) Pause Young (Allocation Failure) 11M->8M(19M) 2.195ms
[34.806s][info ][gc,cpu ] GC(4) User=0.00s Sys=0.00s Real=0.00s
[59.066s][info ][gc,start ] GC(5) Pause Young (Allocation Failure)
[59.066s][info ][gc ] GC(5) Pause Young (Allocation Failure) 11M->11M(19M) 0.075ms
[59.066s][info ][gc,cpu ] GC(5) User=0.00s Sys=0.00s Real=0.00s
[59.066s][info ][gc,start ] GC(6) Pause Full (Allocation Failure)
[59.066s][info ][gc,phases,start] GC(6) Phase 1: Mark live objects
[59.074s][info ][gc,phases ] GC(6) Phase 1: Mark live objects 7.218ms
[59.074s][info ][gc,phases,start] GC(6) Phase 2: Compute new object addresses
[59.076s][info ][gc,phases ] GC(6) Phase 2: Compute new object addresses 1.923ms
[59.076s][info ][gc,phases,start] GC(6) Phase 3: Adjust pointers
[59.080s][info ][gc,phases ] GC(6) Phase 3: Adjust pointers 3.998ms
[59.080s][info ][gc,phases,start] GC(6) Phase 4: Move objects
[59.080s][info ][gc,phases ] GC(6) Phase 4: Move objects 0.713ms
[59.082s][info ][gc,heap ] GC(6) DefNew: 3000K(9216K)->0K(9216K) Eden: 2985K(8192K)->0K(8192K) From: 14K(1024K)->0K(1024K)
[59.082s][info ][gc,heap ] GC(6) Tenured: 9017K(10240K)->9000K(10240K)
[59.082s][info ][gc,metaspace ] GC(6) Metaspace: 8199K(8448K)->8078K(8448K) NonClass: 7323K(7424K)->7229K(7424K) Class: 875K(1024K)->849K(1024K)
[59.082s][info ][gc ] GC(6) Pause Full (Allocation Failure) 11M->8M(19M) 15.316ms
[59.082s][info ][gc,cpu ] GC(6) User=0.02s Sys=0.00s Real=0.01s
[59.082s][info ][gc,start ] GC(7) Pause Full (Allocation Failure)
[59.082s][info ][gc,phases,start] GC(7) Phase 1: Mark live objects
[59.090s][info ][gc,phases ] GC(7) Phase 1: Mark live objects 7.740ms
[59.090s][info ][gc,phases,start] GC(7) Phase 2: Compute new object addresses
[59.091s][info ][gc,phases ] GC(7) Phase 2: Compute new object addresses 1.085ms
[59.091s][info ][gc,phases,start] GC(7) Phase 3: Adjust pointers
[59.094s][info ][gc,phases ] GC(7) Phase 3: Adjust pointers 3.000ms
[59.094s][info ][gc,phases,start] GC(7) Phase 4: Move objects
[59.095s][info ][gc,phases ] GC(7) Phase 4: Move objects 1.331ms
[59.095s][info ][gc,heap ] GC(7) DefNew: 0K(9216K)->0K(9216K) Eden: 0K(8192K)->0K(8192K) From: 0K(1024K)->0K(1024K)
[59.095s][info ][gc,heap ] GC(7) Tenured: 9000K(10240K)->8452K(10240K)
[59.095s][info ][gc,metaspace ] GC(7) Metaspace: 8078K(8448K)->8009K(8448K) NonClass: 7229K(7424K)->7171K(7424K) Class: 849K(1024K)->838K(1024K)
[59.095s][info ][gc ] GC(7) Pause Full (Allocation Failure) 8M->8M(19M) 13.684ms
[59.096s][info ][gc,cpu ] GC(7) User=0.02s Sys=0.00s Real=0.01s
[59.097s][info ][gc,heap,exit ] Heap
[59.097s][info ][gc,heap,exit ] def new generation total 9216K, used 220K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
[59.097s][info ][gc,heap,exit ] eden space 8192K, 2% used [0x00000000fec00000, 0x00000000fec37390, 0x00000000ff400000)
[59.097s][info ][gc,heap,exit ] from space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
[59.097s][info ][gc,heap,exit ] to space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
[59.097s][info ][gc,heap,exit ] tenured generation total 10240K, used 8452K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
[59.097s][info ][gc,heap,exit ] the space 10240K, 82% used [0x00000000ff600000, 0x00000000ffe41268, 0x00000000ffe41400, 0x0000000100000000)
[59.097s][info ][gc,heap,exit ] Metaspace used 8013K, committed 8448K, reserved 1056768K
[59.097s][info ][gc,heap,exit ] class space used 839K, committed 1024K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at org.example.Main.main(Main.java:17)
进程已结束,退出代码1
刚刚想到问题并实现了,下面就是这个类似的.:laughing:
没错,这种情况如果老年代空间足够(前提是新生代不够用)直接晋升
如果超过老年代的话,很明显就是OOM,不过会提前做个自救工作,GC
当某个线程发生OOM时,会影响主线程吗?
综上,不会影响
-XX:+uSEsERIALgc=Serial+SerialOld
Serial:作用于新生代,标记复制
SerialOld:作用于老年代,标记整理
吞吐量:运行用户代码时间/(运行用户代码时间+运行垃圾收集时间)
#JDK8下默认开启
-XX:+UseParallelGC ~ -XX:+UseParallelOldGC
#需要手动开启
#自适应新生代大小
-XX:+UseAdaptiveSizePolicy
#根据目标调整吞吐量目标,如果达不到则调整堆的大小 1/(1+ratio) => 垃圾回收时间/总的运行时间,结果表示每100分钟执行n分钟
-XX:GCTimeRatio=ratio
#GC暂停时间
-XX:MaxGCPauseMillis=ms
-XX:ParallelGCThreads=n
默认线程数为cpu核数
这里本来是OS的内容,在这里再提一下
-XX:+UseConcMarkSweepGc
-XX:+UserParNewGC
#老年代补救
-XX:SerialOld
#并行线程数,CPU核数
-XX:ParallelGCThreads=n
#并发线程数,一般设置为并行线程数的1/4
-XX:ConGCThreads=threads
-XX:CMSInitiatingOccupancyFraction=parent
-XX:+CMSScavengeBeforeRemark
,也就是说当核心数≥4时,并发回收垃圾手机线程只占用不超过25%的处理器运算资源,并且伴随着核心数增多而下降
GC Roots主要在全局性的引用和执行上下文中,且目前Java应用越做越庞大,类、常量很多,逐个检查耗费时间较长。
目前主流的虚拟机均采用准确式垃圾收集(虚拟机可以知道内存中某个位置的数据具体是什么类型),当用户线程停顿下来以后,并不需要一个不漏地检查完所有执行上下文和全局的应用位置,虚拟机应当时又办法直接得到哪些地方存放着用户引用的。
在HotSpot中,使用一组称为OopMap的数据结构来解决准确式垃圾回收的问题,在类加载动作完成的时候,虚拟机会把对象内什么偏移量上是什么类型的数据计算出来,在即使编译过程中,也会在特定位置记录栈、寄存器中哪些位置是引用。
OopMap协助虚拟机快速准确完成GC Roots的枚举,但是可能导致引用关系变化,换句话说
导致OopMap内容发生变化的指令非常多,如果每个指令都生成对应的OopMap,那么会需要大量的额外存储空间,这样垃圾收集伴随的空间成本将无比高昂
实际上HotSpot的确没有为每条指令生成OopMap,只是在特定的位置记录了这些信息你,这些位置被称为安全点。
安全点的设定,决定了用户程序执行时并非在代码指定流的任意位置都能停下来进行垃圾收集,必须到达安全点才能暂停。
安全点的选定:
安全点机制只能保证程序执行时,在不太长的时间内就会遇到可进入垃圾手机的过程的安全点。
不执行的时候呢?
——没有分配处理器时间 Sleep or Blocked,此时线程无法响应虚拟机中断请求,不能再走到安全的地方终端挂起自己,虚拟机也显然不可能持续等待线程重新杯激活分配处理器时间。
为了解决这一问题,引入了安全区域(Safe Region)
安全区域是指能够确保在某一段代码片段中,引用关系不会发生变化,因此在这个区域中任意地方开始垃圾收集都是安全的。(背扩展拉伸了的安全点)
当用户线程执行刀安全区域里的代码时,首先会标识自己已经进入了安全区域,虚拟机在进行垃圾收集时不必去管此类线程,当线程离开安全区域时,检测虚拟机是否已经完成了根节点枚举(或垃圾收集过程中其他需要暂停用户线程的阶段),如果完成,线程就当作没事发生过继续执行,否则一直等待,知道收到可以离开安全区域的信号为止
分代收集理论提到了为解决 对象跨代引用所带来的问题,垃圾收集器在新生代中建立了名为记忆集的数据结构-
记忆集
用于避免把整个老年代加进GCRoots扫描范围
事实上不只是新生代、老年代之间才可有跨代引用的问题,所有设计部分区域收集(Partial GC)行为的垃圾收集器(G1,ZGC,Shenandoah)都会面临相同的问题
记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构。
Class RemebereSetd{
Object[] set[OBJECT_INTERGKENERATIONAL_REFRENCE_SIZE]
}
全部记录,无论是空间占用还是维护成本都相当高昂。
其实在垃圾收集的场景中,收集器只需要通过记忆集判断出某一块非收集区域是否存在指向了收集区域的指针即可。
在设计记忆集的时候,可以选择更为粗犷的记录粒度来节省记忆集的存储和维护成本。
卡表对记忆集的实现:
卡表与记忆集的关系,类似于HashMap和Map的关系
最简单的一种形式:字节数组,一下代码时默认的卡表标记逻辑
CARD_TABLE [this address >>9] = 0;
该数组的每一个元素都对应(注意是对应,也就是说存放的是地址)着其标志的内容区域中一块特定大小的内存块,该内存块成为“卡页”。
一般来说 卡页 的大小都是 2^n字节数,HotSpot使用的卡页是2^9,也就是512字节(地址>>9 == 地址/512)
如果卡表标识内存区域的其实地址是0x0000的话,数组CARD_TABLE的第0、1、2号元素,分别对应了地址范围为0.00000x01FF、0x02000x03FF、0x04FF~0x05FF的卡页内存块.(每块大小为512)
一个卡页的内存中通常包含不止一个对象,只要卡页内有一个(或更多)对象的字段存在着跨代指针,那就将对应卡表的数组元素的值标识为1,成这个元素变脏(Dirty),没有则标识为0。在垃圾收集发生时,只要筛选出卡表中变脏的元素,就能轻易得出哪些卡页内存块中包含跨代指针,把他们加入GC Roots中一并扫描。
写屏障用来解决卡表元素维护问题。
写屏障 可以看作在虚拟机层面对”引用类型字段赋值“这个动作的AOP切面,在引用对象负值时产生一个环形通知,供程序进行额外动作,因此写屏障分为写前屏障与写后屏障(将环绕通知看作前置通知+后置通知),HotSpot虚拟机很多哦收集器都有使用到写屏障,但是直到G1收集器出现之前,都只用到了写后屏障。
// 写后屏障更新卡表
void oop_field_store(oop* filed,oop new_value){
//引用字段赋值操作
*field = new_value;
//写后屏障,在这里完成卡表状态更新
post_write_barrier(field,new_value);
}
应用写屏障后,虚拟机就会为所有赋值操作生成相对应的指令,一旦收集器在写屏障中增加了更新卡表操作,无论更新的是不是老年代对新生代对象的引用,每次只要是对引用进行更新,都会产生额外的开销,不过和Minor GC是扫描整个老年代相比还是较小。
在高并发场景下,卡表还面临”伪共享“问题
处理并发底层细节时一种经常需要考虑的问题,现代代中央处理器的缓存系统中以缓存行(Cache Line)为单位存储,当线程修改互相独立的变量时,如果这些变量恰好共享同一个缓存行,就会彼此影响(写回、无效化、同步)而导致性能降低,这就是伪共享问题
伪共享相关文章: JAVA系列:缓存一致性协议( MESI协议)_NIO4444的博客-CSDN博客 伪共享(False Sharing) - 知乎 (zhihu.com) 真实字节二面:什么是伪共享? - 知乎 (zhihu.com) [ Java 伪共享的原理深度解析以及避免方法_刘Java的博客-CSDN博客](https://blog.csdn.net/weixin_43767015/article/details/104856899#:~:text=缓存系统中的缓存是以缓存行(cache,line)为单位存储的,当多线程修改互相独立的变量时,如果这些变量共享同一个缓存行,因为都会导致同一个缓存行失效而会无意中影响彼此的性能,这就是伪共享(false sharing)。) 【深入理解JVM】3、CPU储存器+MESI+CPU伪共享+CPU乱序问题及代码论证+volatile+synchrnized【面试必备】_Hello-zhou的博客-CSDN博客
避免伪共享问题:
不采用无条件的写屏障,先检查卡表标记,只有当该卡表元素未被标记时才将其标记变脏
if( CARD_TABLE [this address >>9] !=0 ){
CARD_TABLE [this address >>9]=0;
}
在JDK7之后,HotSpot虚拟机增加了一个新的参数 -XX:+UseCondCardMark,用来决定是否开启卡表更新条件的判断。开启会增加一次额外判断的开销,但能够避免伪共享问题,是否打开要根据实际运行情况来进行测试权衡。
使用场景:
-XX:+UseG1GC
-XX:G1HeapRegionSize=size
-XX:MaxGCPauseMillis=time