JVM
口述JVM的组成
首先JVM的组成分为几大块,类加载器,运行时数据区,执行引擎,本地方法接口,然后运行时数据区又分为方法区,栈,堆,程序计数器,本地方法栈。
首先是类加载器,它负责帮我们的class文件加载到JVM当中去,它又分为启动类加载器(主要是加载jdk里的包),扩展类加载器(主要加载jdk一些扩展类jar包),应用类加载器(主要加载我们写的java代码跟引入的相关依赖,自定义类加载器。提到了类加载器,它有一个双亲委派机制和沙箱安全机制,简单来说就是类加载器加载文件的时候会先看他的父类有没有加载过,如果加载过就不会在加载了。这样就保证了我们系统的安全性跟类的唯一性。
其次是方法区:它是所有线程共享的,存的主要是类信息、常量、静态变量、即时编译后的代码
;
然后就是栈:它是我们方法执行的一个容器,遵循先进后出的原则。
还有就是本地方法栈:它主要是一些调用native修饰的方法进栈,主要是调用一些操作系统层面的语言c/c++ 比如说开启一个新的线程
然后就是堆:堆的话就是我们对象存储的地方,它又分为新生代和老年代,新生代又分为eden区和幸存者0和幸存者1 内存比例主要是8:1:1,一个初始的对象都会先进入eden区,然后在经历一次垃圾回收之后就会到幸存者0区,幸存者0区垃圾回收又回到幸存者1区,反复15次以后的对象都没有被垃圾回收的话就会进入我们的老年代,新生代的gc又叫yangGc,老年代的gc叫fullGc。我们在应用开发和监控的时候应该避免频繁的fullGc。这里gc的算法有复制算法,标记清除法,标记整理法。
gc的类型有parallelGc serialGc CMS G1 ZGc。
程序计数器:主要是线程上下文切换的时候由于主要记录的是我们线程执行到哪了
提到JVM它里面分为了很多块…
1.我们的类加载器是我们JVM的入口负责把我们的class文件写入到jvm内存里面去到方法区形成大CLASS对象,链接->为类对象分配内存,并设置类变量的默认初始值,final修饰的变量在编译的时候就初始化好了,这时会给其赋值。初始化->就是执行类构造器方法classinit 主要是给类变量初始化值。
2. 执行引擎是我们jvm的出口他负责jvm与我们操作系统的交互。
3. 方法区主要是存放类的信息
然后就是我们本地方法栈(里面存储着java执行不了的方法用native修饰)和本地方法接口(这里指的是操作系统的接口),调用过程中如果需要第三方类库的支持那么久需要本地方法库。
那么我们的java栈就是存储我们的实例的引用,8种数据类型,方法进栈。栈里面有个程序计数器(主要是记录栈里方法出栈下一个执行什么方法)。
方法区和堆看下面详细介绍。
类加载器(优先级1~4)
- Bootstrap Classloader : 启动类加载器,用来加载 %JAVA_HOME%/jre/lib 下的rt.jar中的class文件 或者 xbootclassoth选项指定的jar包
- Extension Classloader : 扩展类加载器 , 用来加载 %JAVA_HOME%/jre/lib/*.jar 中的class文件 或者 -Djava.ext.dirs指定目录下的jar包
- Application Classloader : 应用类加载器 , 用来加载classpath下的class文件
- Custom Classloader : 用户自定义类加载器,用来加载自定义内容.此加载器需要用户自己继承Classloader类
==============================================
双亲委派机制:
当某个类加载器需要加载某个.class文件时,它首先把这个任务委托给他的上级类加载器,递归这个操作,如果上级的类加载器没有加载,自己才会去加载这个类。
作用:
1、防止重复加载同一个.class。通过委托去向上面问一问,加载过了,就不用再加载一遍。保证数据安全。
2、保证核心.class不能被篡改。通过委托方式,不会去篡改核心.clas,即使篡改也不会去加载,即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。
沙箱安全机制
沙箱安全机制是基于双亲委派机制的前提下 String 的类,由于双亲委派机制的原理,此请求会先交给启动类加载器尝试加载,但是Bootstrap在加载类时首先通过包和类名查找rt.jar中有没有该类,有则优先加载rt.jar包中的类,因此就保证了java的运行机制不会被破坏.
方法区
方法区是被所有的线程共享,所有定义方法的信息都保存在该区域,此区属于共享区间。静态变量+常量+类信息(构造方法/接口定义)+运行时常量池存在方法区中 but 实例变量存在堆内存中和方法区无关
栈
先进后出,每个线程有独立的栈。他的生命周期跟随我们线程的生命周期,8种基本类型的变量,对象引用的变量,实例方法都是在函数的栈内存中分配。
StackOverflowerError
本地方法栈:
主要是jvm执行不了的方法 在们的代码中用native标记的方法只有声明却没有实现方法,这时就到我们本地方法栈中通过调用本地方法接口执行方法(c语言实现的第三方函数库)。如我们的开启线程就是这样子实现的。
程序计数器
里面记录着我们栈里面方法调用和执行的情况,类似于我们的一个排班表。
堆
一个JVM里面只有一个堆内存,堆内存的大小是可以调节的,
我们的类加载器读取了类文件后需要把类,方法,常态量,放到堆内存中,保存所有引用类型的真实信息,以方便执行器执行,堆内存分为三个部分 1.新生区(Eden,S0,S1三个区 8:1:1的比例大概) 2.养老区 3.永久区(就是我们的方法区) 默认堆内存 = 内存/64。 最大 = 内存/4
有关GC当经过一定次数(默认是15次)的GC会从新生区转移到老年区。当养老区的内存满的话就会在进行一次Full GC 还是内存满的话就会抛出OutOfMemoryError
**
jvm常用的参数
**
OutOfMemoryError:java heap space
1.调整堆内存的大小 通过参数 -Xms.Xmx来调整
如-Xms1024m -Xmx1024m -XX:+printGCDetails初始化容量大小为1G 最大为1G 并打印分配的详细信息。
2.代码中创建了大量的大对象,并且长时间存在被引用不能被GC回收
GC垃圾回收
常见垃圾回收的算法
引用计数(一般不用) 较难处理循环引用。
复制 (伊甸区->幸存者0<->幸存者1) 有一部分内存空间始终不能被使用
标记清除(有大片的内存碎片)
标记整理 (Java堆中老年代的垃圾回收算法)内存没有随便化,清理完比较规整
三色标记法 用可达性分析算法把对象分为几种颜色。主要是CMS垃圾回收器使用
- 白色:没碰过
- 灰色:我看过你,但你的小弟还没看完
- 黑色:我和你的小弟全部看完
如何定位对象是否需要被回收?
1.引用计数法(有弊端) 有变量指向对象 则计数+1 但是对象之间变量的循环引用无法记录。存在内存泄露的问题
2.可达性分析算法
将“GC Roots” 对象作为起点,从这些节点开始向下搜索引用的对象,找到的对象都标记为非垃圾对象,其余未标记的
对象都是垃圾对象
GC Roots根节点:线程栈的本地变量、静态变量、本地方法栈的变量等等
打破双亲委派机制
- 自己建一个类加载器 集成ClassLoad
- 重写loadClass方法,把双亲委派那段代码删了
- 然后改良一下沙箱安全机制
逃逸分析
如果一个方法里的对象 没有返回。那么这个对象不会分配在堆空间而是分配在栈空间,随着方法的结束,这个对象也就销毁了
TLAB
堆空间内多个线程并发分配地址,会产生阻塞问题。
1.首先TLAB是线程缓冲区,每个线程都有(Thread-local allocation buffer)。默认设定为占用Eden Space的1%。在Java程序中很多对象都是小对象且用过即丢,它们不存在线程共享也适合被快速GC,所以对于小对象通常JVM会优先分配在TLAB上,并且TLAB上的分配由于是线程私有所以没有锁开销。因此在实践中分配多个小对象的效率通常比分配一个大对象的效率要高。
2.如果遇到大对象 在线程缓冲区里放不下。那么就会用cas的方法为这个对象分配内存空间。
为什么要指针压缩?堆内存越大越好吗?
1.在64位平台的HotSpot中使用32位指针,内存使用会多出1.5倍左右,使用较大指针在主内存和缓存之间移动数据,占用较大宽带,同时GC也会承受较大压力
2.为了减少64位平台下内存的消耗,启用指针压缩功能
3.在jvm中,32位地址最大支持4G内存(2的32次方),可以通过对对象指针的压缩编码、解码方式进行优化,使得jvm只用32位地址就可以支持更大的内存配置(小于等于32G)
4.堆内存小于4G时,不需要启用指针压缩,jvm会直接去除高32位地址,即使用低虚拟地址空间
5.堆内存大于32G时,压缩指针会失效,会强制使用64位(即8字节)来对java对象寻址,这就会出现1的问题,所以堆内存不要大于32G为好
G1 垃圾回收器:
- 初始标记:STW,标记 GC Roots 直接可达对象。
- 并发标记:用户线程与 GC 并发,遍历对象图;采用三色标记 + SATB 原始快照解决漏标。
- 重新标记:STW,修正并发阶段引用变化。
- 筛选回收(拷贝):✅STW。根据停顿预期,挑选垃圾最多的 Region,把存活对象复制拷贝到空闲 Region。
JAVA_MEM_OPTS=“-server
-Xms4096M
-Xmx4096M
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:ParallelGCThreads=2
-XX:-OmitStackTraceInFastThrow
-XX:+UnlockExperimentalVMOptions
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintGCDetails
-XX:+PrintAdaptiveSizePolicy
-XX:+PrintGCDateStamps
-XX:+PrintReferenceGC
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=logdir/javaHeapDump.hprof−verbose:gc−Xloggc:{log_dir}/java_HeapDump.hprof -verbose:gc -Xloggc:logdir/javaHeapDump.hprof−verbose:gc−Xloggc:{log_dir}/gc.log”