当前位置：首页 > news >正文

jvm底层

news 来源：原创 2024/4/27 17:07:14

逐步细化

静态链接：静态方法(符号引用)替换为内存指针或者句柄直接引用)

动态链接：程序期间将符号引用替换为直接引用

对象头：

指针压缩：

-XX:+UseCompressedOops 开启指针压缩

减少内存消耗；大指针在主内存缓存间移动数据，占用带宽大 GC压力大

jvm通过对对象指针存入堆内存时进行压缩编码32位，取到cpu寄存器解码方式优化35位

堆内存大于32g，压缩指针失效，强制使用64位对java对象寻址

小于4g 不需要启动指针压缩直接去除高32位地址，使用低虚拟空间

Launcher

单例

内存分配

引用计数：对象引用计数器，一个引用+1

可达性分析：

无用的类：

所有实例被回收

加载该类的classLoader被回收

该类对应的java.lang.Class对象没有在任何地方被引用

逃逸分析：

在方法被定义后可能被外部方法引用

不会逃逸的对象可在栈上分配内存，方法结束时跟随栈内存一起被回收掉

默认开启- XX:DoEscapeAnalysis 7默认开启

标量替换：不会逃逸且对象可进一步分解，jvm不会创建该对象，分解若干成员变量

-XX:EliminateAllocations

标量与聚合量：标量不能分解的量，基本数据类型 reference类型

聚合量：可分解的量，对象

finalize方法仅执行一次，可覆盖然后自救

eden分配：

大部分情况，对象在eden分配，无足够空间虚拟机发起Minor gc

minorGc/youngGc 新生代垃圾收集动作非常频繁回收速度快

majorGc/fullGc 回收老年代年轻代方法区的垃圾

老年代

大对象直接进入老年代：eden发不下

-XX:PretenureSizeThreshold 字节超过直接进入老年代 serial/parNew收集器有效

避免大对象分配内存时的复制操作

长期存活对象：分代收集，为每个对象年龄计数器 - XX:MaxTenuringThreshold

survivor区域年龄+1 +2 +n 多个年龄对象总和超过survivor区域50%，n及其以上对象放到老年代

年龄判断机制都是在minorGc 后触发的

内存模型

栈帧内存空间：独立

参数：

-Xms -Xmx -Xmn

-XX:MaxMetaspaceSize元空间max值，默认 -1 不限制

-Xss 栈大小默认1m，值越小栈帧越小，512k，jvm开启线程越多

-XX:MetaspaceSize 元空间初始大小字节为单位 21M ，到达触发full gc，收集器对该值调整，释放了大量空间则调低，释放很少空间不超max提高该值

垃圾收集

分代收集理论

复制算法：

标记整理算法

写屏障只

标记清理算法

标记存活，回收未被标记的

效率不高/碎片

垃圾收集分类

youngGC：G1计算下现在eden区回收大概要多久，如果回收时间小于参数-XX:MaxGCPauseMills增加region 新对象存放，知道时间相近

MixedGC：老年代堆占有率达到参数- XX:InitiatingHeapOccupancyPercent触发，young和部分old大对象，复制算法如没有足够空间fullGC

fullGC:停掉系统程序，单线程进行标记清理和压缩整理，好空闲出来一批region来供下一次mixedGC 耗时

垃圾收集器

serial：--XX:+UseSerialGC --XX:+UseSerialOldGC

串行单线程一条线程收集工作 stw

新生代复制算法，老年代标记整理

parallel scavenge：-XX:UseParallelGC 并行

parNew-XX：ParNewGC 可和cms配合使用 stw 年轻代

如何选择：

内存小于100m，串行
单核没有停顿时间要求串行 jvm自己选择
容许停顿时间超1s，并行 jvm自己选择
响应时间最重要，不能超过1s，并发收集器
4G以下可用parallel，4-8GparNew+CMS ；8G以上G1 几百G用ZGC

cms

和cpu敏感，和服务抢资源

浮动垃圾无法处理

并发标记局部变量gcroot被销毁，gcroot引用对象被扫描过本轮不会回收

并发标记/清理产生新对象直接全部黑色本轮不清除看你会变成浮动垃圾

标记-清除，大量空间碎片 -XX:+UseCMSCompactAtFullCollection让jvm清理完整理

执行过程中不确定，上次没做完这次被触发，并发标记/清理 concurrent mode failure -> stw serial old 垃圾收集器回收！！！

- XX:CMSFullGCCsBeforeCompaction多少次FullGC后压缩一次，默认0 每次都压素一次

三色标记：堆

并发标记，标记期间应用线程还在跑，对象间引用可能发生变化

黑色：已被垃圾收集器访问过，且引用对象都已经扫描过，安全存活

灰色：已被垃圾收集器访问过，至少一个引用对象没有被扫描过

白色：未被垃圾收集器访问过，不可访问

漏标：读写屏障

漏标导致被应用对象当成垃圾误删除，严重bug

增量更新：黑色对象插入新白色对象引用，将新引用记录，并发扫描结束后将这些黑色对象为根重新扫描一次，深度扫描

原始快照 SATB：灰色对象删除指向白色对象的引用关系，引用记录下来，并发扫描结束，灰色对象为根重新扫描一次扫描到白色对象将其标记为黑色；浮动垃圾效率要高些

记忆集remember set

新声代gcroot可达性扫描过程中，碰到跨代引用的对象，提高效率，引入记录集

从非收集区到收集区到指针集合

卡表：页内存card card_table[] 数组标识是否被年轻代引用

G1:

小的大小相等的内存块 region

jvm最多可2048个region -XX:G1HeapRegionSize指定大小

默认年轻代占比5%， -XX:G1NewSizePercent设置新生代初始化占比，最多<0.6 XX:G1MaxNewSizePercent调整

大对象处理：专门分配大对象的region：Humongous 超过region的一半放入h，可跨region存放

后台维护优先队列，容许收集时间优先选择回收价值max的region

-XX:MaxTenuringThreshold最大年龄阈值15

-XX:InitiatingHeapOccupancyPercent老年代占用空间达到整堆内存阈值 45%则mixedGc

-XX:G1MixedGCLiveThresholdPercent 85% region存活对象低于这个值会回收该region

XX:G1MixedGCCountTarget一次回收过程中指定做几次筛选 8；

优化

调节XX:MaxGCPauseMills,保证年轻代gc别太频繁，考虑每次gc存活对象有多少，避免存活对象过多快速进入老年代

什么场景

50%以上堆被存活对象占用

对象分配和晋升速度变化非常大

垃圾回收时间特别长，超过1s

8G以上堆内存

停顿时间是500ms以内

为什么G1用SATB，CMS用增量更新

satb效率高，不需要更新标记阶段再次深度扫描被删除引用对象，只是简单标记，下一轮再扫

cms增量引用的根对象会做深度扫描，G1很多对象都位于不同region，深度扫代价高

ZGC

低延迟垃圾收集器，C4

基于region布局，读屏障颜色指针等技术实现并发标记-整理

并发标记：遍历对象可达性分析，指针上进行，更新颜色指针

并发预备分配：特定查询条件统计得出本次收集过程要清理哪些region重分配集

并发重分配：复制到空闲region，重新分配集中每个region维护转发表，记录从旧对象到新对象的转向关系，收集器据此是否处于重分配集中，读屏障将访问转发新复制的对象上修正引用值

并发重映射：修正堆中重分配集旧对象引用，合并到下一次垃圾收集循环中并发标记完成

颜色指针：并发标记对象指针上

region存活对象被移除后region被释放重用；颜色指针可减少垃圾收集过程中内存屏障的使用数量，可扩展存储结构，来记录更多与对象标记，重定位过程相关数据

读屏障：从堆对象的引用中读取一个指针，加一个load Barriers

安全点：对正在执行的线程设定

代码中特定位置，线程运行到这些位置状态是确定的，jvm可安全进行一些操作：GC

方法返回之前 / 调用某个方法之后 / 抛出异常的位置 / 循环的末尾

当垃圾收集需要中断线程时，简单得设置一个标识位，各线程执行过程轮询这个标志，一旦中断标志=true 在自己最近安全点上中断挂起轮询标志的地方和安全点上重合的

安全区域：

一个线程处于sleep或中断状态，不响应jvm中断请求，运行在safe point上，所以引入safeRegion，一段代码片段中，引用关系不会发现变化，这个区域任意地方开始gc都是安全的

每秒几十万并发的系统如何优化jvm

kafka需要大内存机器64G，没几秒就youngGC 不好，G1 - XX:MaxGCPauseMills=50ms

双亲委派：父加载器

类型

引导类加载器：jre的lib核心类

扩展类加载器：ext

应用程序加载器：appClassLoader ，classpath，target包

自定义加载器：

过程

appClassLoader urlClassLoader loadClass(全类名)

findLoadedClass已经加载的类c

parent.loadClass(name,resolve:false);加锁 sync ；

父的loadClass （extClassLoader循环调super）

findBootstrapClassOrNull引导类加载器

已经加载的类去

findClass(); 可打破双亲委派，跳过super

urlClassLoader: path 类路径

ucp.getResource加载类

defineClass

打破

tomcat

web容器，不同应用程序可能会依赖同一三分库的不同版本；

commonLoader：基本类加载器，class可被tomcat本身及wabapp访问

sharedLoader:各webapp共享类加载器，加载路径中class对于所有webapp可见，对tomcat容器不可见

catalinaLoader：tomcat容器私有类加载器，加载路径中class对webapp不可见

webappClassLoader：各webapp私有类加载器，加载路径中的class文件对当前webapp见，每个war有自己的webappClassLoader，互相隔离，不同war包应用引入不同spring版本

原因

沙箱安全机制：自己写的类不会被加载，防止核心api库被随意篡改

避免类重复加载：父已经被加载类该类，没必要再加载一次

全盘委托：

当一个classload装载一个类时，除非显示使用另一个classloader，该类所依赖及引用的类也由这个classloader载入

自定义类加载器

继承java.lang.ClassLoader类


public class FindClassLoader {static class MyClassLoader extends ClassLoader{private String classPath;public MyClassLoader(String classPath){this.classPath =classPath;}private byte[] loadByte(String name) throws Exception{name = name.replaceAll("\\.","/");FileInputStream fis = new FileInputStream(classPath+"/"+name+".class");int len = fis.available();byte[] data = new byte[len];fis.read(data);fis.close();return data;}protected Class<?> findClass(String name) throws ClassNotFoundException{try {byte[] data = loadByte(name);//字节数组转class对象，字节数组是class文件读取后最终的字节数组return defineClass(name,data,0,data.length);}catch (Exception e){e.printStackTrace();throw new ClassNotFoundException();}}}public static void main(String[] args) throws Exception{//初始化自定义类加载器 先初始化父类classloader；会把自定义类加载器的父加载器=appClassLoaderMyClassLoader classLoader = new MyClassLoader("读取哪个路径");Class clazz = classLoader.loadClass("类全路径");Object obj = clazz.newInstance();Method method=clazz.getDeclaredMethod("哪个方法",null);method.invoke(obj,null);System.out.println(clazz.getClassLoader().getClass().getName());}}