一、什么是JVM?
JVM是一种规范,虚构的计算机(冯诺依曼计算机结构)。跨语言的平台。
也就是编译后是
二、JVM要学什么?
- 源码到类文件
- 类文件到JVM
- JVM中各种处理(内部结构、执行方式、垃圾回收、本地调用)
2.1 源码到类文件
2.1.1 Javac过程
XXX.java -> 词法分析器 -> tokens流 -> 语法分析器 -> 语法树/抽象语法树 -> 语义分析器 -> 注解抽象语法树 -> 字节码生成器 -> XXX.class文件
2.1.2 class文件格式-十六进制
2.1.3 ClassFile Struucture
官网地址:https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html
2.1.4 简单分析
magic u4 --> cafe babe
minor_version u2 -->0000
major_version u2-->0034 十进制数52,表示 JDK8
constant_pool_count u2 --> 00a4 十进制数164 常量池的数量为164
2.1.5 javap验证
javap -v -p xxx.class进行反编译,查看字节码信息和指令等信息
2.2 类文件到虚拟机(类加载机制)
类加载机制指虚拟机把class文件加载到内存,并对数据进行校验、转换解析和初始化。
2.2.1 装载(Load)
主要是查找和导入class文件。
step 1 -->通过一个类的全限定名获取定义此类的二进制字节流;
step 2 -->将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构;
step 3 -->在堆中生成一个代表这个类的java.lang.Class对象,作为对方法区中这些数据的访问入口。
2.2.2 链接(Link)
2.2.2.1验证(Verify)
保证被加载类的正确性!文件格式验证、元数据验证、字节码验证、符号引用验证。
2.2.2.2 准备(Prepare)
为类的静态变量分配内存,并将其初始化为默认值。
2.2.2.3 解析(Resolve)
把类中符号引用转换为直接引用
符号引用:一组符号来描述目标,可以是任何字面量。
直接引用:直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符7类符号引用进 行。
2.2.3 初始化(Initialize)
对类的静态变量、静态代码块执行初始化操作
2.2.4 类加载器ClassLoader
用来装载class类
2.2.4.1 分类
Boostreap ClassLoader --->C++实现的
Extension ClassLoader ---->扩展
App ClassLoader ----->ClassPath指定路径下
Coustom ClassLoader --->自定义
2.2.4.2 加载原则(双亲委派机制)
- 检查某个类是否已经被加载自底向上,从Custom ClassLoader至Bootstrap ClassLoader逐层检查,只要有一个ClassLosder加载了,保证此类只被加载一次。
- 加载顺序
自顶向下,由上层来逐层加载此类。
2.2.4.3 破坏双亲委派
- tomact
- SPI机制(Service Provider Interface)Java中的SPI(Service Provider Interface)机制是一种用于实现组件化架构的技术。它允许在运行时动态地扩展或替换框架或库中的实现类。
Java提供了一些标准的SPI实现,例如JDBC、JNDI、JAXP等。开发人员也可以使用SPI机制来实现自己的插件框架。 - OSGi
OSGi(Open Services Gateway Initiative)是一种模块化系统架构,可以使Java应用程序以模块化的方式进行开发、部署和管理。
如Eclipse、Apache Felix
2.3 运行时数据区(Run-TIme Data Areas)
2.3.1 官网概括
官网; https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
2.3.2 图解
2.3.3 初步介绍
2.3.3.1 Method Area(方法区)
- Java虚拟机有一个在所有Java虚拟机线程之间共享的方法区域。
- 方法区域是在虚拟机启动时创建的。
- 方法区域在逻辑上是堆的一部分,但是它有一个别名Non-Heap(非堆),目的是和heap(堆)分开
- 方法区域的内存不需要是连续的。
- 如果方法区域中的内存不能用于满足分配请求,Java虚拟机将抛出OutOfMemoryError。
另外不同JDK版本Method Area真正的实现不同;
JDK 8中 是Metaspace(元空间)
JDK 8之前是Perm Space(永久代)
二者主要区别:
Meta space和Perm space的主要区别在于存储元数据的方式和管理方式。Meta space使用本地内存存储元数据,并具有自动内存管理功能,而Perm space则位于JVM的堆内存中,并且容量是固定的。
2.3.3.2 Heap(堆)
- Java堆是Java虚拟机所管理内存中最大的一块,在虚拟机启动时创建,被所有线程共享。
- Java对象实例以及数组都在堆上分配。
2.3.3.3 Java Virtual Machine Stacks(虚拟机栈)
- 虚拟机栈是一个线程执行的区域,保存着一个线程中方法的调用状态。换句话说,一个Java线程的运行状态,由一个虚拟机栈来保存,所以虚拟机栈肯定是线程私有的,独有的,随着线程的创建而创建。
- 每一个被线程执行的方法,为该栈中的栈帧,即每个方法对应一个栈帧。调用一个方法,就会向栈中压入一个栈帧;一个方法调用完成,就会把该栈帧从栈中弹出。
栈帧:
官网https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.6
每个栈帧对应一个被调用的方法,可以理解为一个方法的运行空间。每个栈帧中包括局部变量表(Local Variables)、操作数栈(Operand Stack)、指向运行时常量池的引用(A reference to the run-time constant pool)、方法返回地址(Return Address)和附加信息。
局部变量表: 方法中定义的局部变量以及方法的参数存放在这张表中 局部变量表中的变量不可直接使用,如需要使用的话,必须通过相关指令将其加载至操作数栈中作为操作数使 用。
操作数栈:以压栈和出栈的方式存储操作数的
动态链接:每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用,持有这个引用是为了支持方法调用 过程中的动态连接(Dynamic Linking)。
方法返回地址:当一个方法开始执行后,只有两种方式可以退出,一种是遇到方法返回的字节码指令;一种是遇 见异常,并且这个异常没有在方法体内得到处理。
2.3.3.4 The pc Register(程序计数器)
如果线程正在执行Java方法,则计数器记录的是正在执行的虚拟机字节码指令的地址; 如果正在执行的是Native方法,则这个计数器为空。
2.3.3.5 Native Method Stacks(本地方法栈)
如果当前线程执行的方法是Native类型的,这些方法就会在本地方法栈中执行。
那如果在Java方法执行的时候调用native的方法呢?
2.3.4 各种情况
2.3.4.1 栈指向堆
在栈帧中有一个变量,类型为引用类型,比如Object obj=new Object(),这时候就是典型的栈中元 素指向堆中的对象。
2.3.4.2 方法区指向堆
方法区中会存放静态变量,常量等数据。如果是下面这种情况,就是典型的方法区中元素指向堆中的对象。
2.3.4.3 堆指向方法区
方法区中会包含类的信息,堆中会有对象,那怎么知道对象是哪个类创建的呢?
那么一个对象具体是怎么知道它是由那个类创建出来的呢?这就涉及到对象的内存模型了。
2.3.4.4 Java对象内存模型
2.4 JVM内存模型
2.4.1 运行时数据区
其实重点存储数据的是堆和方法区(非堆),所以内存的设计也着重从这 两方面展开(注意这两块区域都是线程共享的)。
对于虚拟机栈,本地方法栈,程序计数器都是线程私有的。
2.4.2 TLAB(Thread Local Allocation Buffer)?
2.4.2.1 什么是TLAB?
从内存模型来看,在Eden区域内,JVM为每个线程分配了一个私有缓存区域。
2.4.2.2 为什么会出现TLAB?
- 堆区是线程共享区域,任何线程都可以访问到堆区中的共享数据;
- 由于对象实例的创建在JVM中非常频繁,因此在并发环境下从堆区中划分内存空间是线程不安全的;
- 为避免多个线程操作同一地址,需要使用加锁等机制,进而影响分配速度。
2.4.2.3 快速分配策略
多线程同时分配内存时,使用TLAB可以避免一系列的非线程安全问题,同时还能够提升内存分配的吞吐量,因此我们可以将这种内存分配方式称之为快速分配策略。
2.4.2.4 TLAB说明
- 尽管不是所有的对象实例都能够在TLAB中成功分配内存,但TLAB确实是作为内存分配的首选。
- 可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间。
- TLAB空间的内存非常小,仅占有整个Eden空间的1%,可以通过选项“-XX:TLABWasteTargetPercent”设置TLAB空间所占用Eden空间的百分比大小。
2.4.3 具体分区
一块是非堆区,一块是堆区堆区分为两大块,一个是Old区,一个是Young区
Young区分为两大块,一个是Survivor区(S0+S1),一块是Eden区
S0和S1一样大,也可以叫From和To
2.4.4 对象内存分配过程
2.4.5 常见面试题
2.4.5.1 如何理解Minor/Major/Full GC ?
Minor GC 年轻代
Major GC 老年代
FULL GC 新生代+老年代
2.4.5.2 为什么需要Survivor区?只有Eden不行吗?
如果没有Survivor,Eden区每进行一次Minor GC,存活的对象就会被送到老年代。 这样一来,老年代很快被填满,触发Major GC(因为Major GC一般伴随着Minor GC,也可以看做触发了Full GC)。 老年代的内存空间远大于新生代,进行一次Full GC消耗的时间比Minor GC长得多。
执行时间长有什么坏处?
频发的Full GC消耗的时间很长,会影响大型程序的执行和响应速度。
如果对老年代的空间进行增加或者减少呢?
假如增加老年代空间,更多存活对象才能填满老年代。虽然降低Full GC频率,但是随着老年代空间加大,一 旦发生Full GC,执行所需要的时间更长;
假如减少老年代空间,虽然Full GC所需时间减少,但是老年代很快被存活对象填满,Full GC频率增加。
所以Survivor的存在意义,就是减少被送到老年代的对象,进而减少Full GC的发生。
2.4.5.3 为什么需要两个Survivor区?
最大的好处就是解决了碎片化。假设现在只有一个Survivor区,我们可以模拟一下流程:
刚刚新建的对象在Eden中,一旦Eden满了,触发一次Minor GC,Eden中的存活对象就会被移动到Survivor 区。这样继续循环下去,下一次Eden满了的时候,问题来了,此时进行Minor GC,Eden和Survivor各有一些 存活对象,如果此时把Eden区的存活对象硬放到Survivor区,很明显这两部分对象所占有的内存是不连续的,
也就导致了内存碎片化。永远有一个Survivor space是空的,另一个非空的Survivor space无碎片。
2.4.5.4 新生代中Eden:S1:S2为什么是8:1:1?
新生代中的可用内存:复制算法用来担保的内存为9:1
可用内存中Eden:S1区为8:1
即新生代中Eden:S1:S2 = 8:1:1
现代的商业虚拟机都采用这种收集算法来回收新生代,IBM公司的专门研究表明,新生代中的对象大概98%是 “朝生夕死”的
2.4.5.5 堆内存中都是线程共享的区域吗?
JVM默认为每个线程在Eden上开辟一个buffer区域,用来加速对象的分配,称之为TLAB,全称:Thread Local Allocation Buffer。 对象优先会在TLAB上分配,但是TLAB空间通常会比较小,如果对象比较大,那么还是在共享区域分配。
2.5 Garbage Collect(垃圾回收)
2.5.1 如何确定一个对象是垃圾?
2.5.1.1 引用计数法
对于某个对象而言,只要应用程序中持有该对象的引用,就说明该对象不是垃圾,如果一个对象没有任何指针对其引用,它就是垃圾。
缺点:出现循环引用情况,则永远不能被回收
2.5.1.2 根可达算法
通过GC Root的对象,开始向下寻找,看某个对象是否可达。
那些能作为GC Root?
虚拟机栈(栈帧中的本地变量表)中引用的对象。
方法区中类静态属性引用的对象。
方法区中常量引用的对象。
本地方法栈中JNI(即一般说的Native方法)引用的对象。
2.5.2 什么时候会进行垃圾回收?
- Eden区或者Servivor区空间不够
- 老年代空间不够用
- 方法区空间不够用
- System.gc() 一般不用
2.5.3 垃圾收集算法
2.5.3.1 标记-清除算法(Mark-Sweep)
- 标记:找出内存中需要回收的对象,并且把它们标记出来。此时堆中所有区域都会被扫描一遍,从而才能确定需要回收的对象,比较耗时。
- 清除调被标记需要回收的对象,释放出对应的内存空间。
缺点:
- 会产生大量不连续的内存碎片,碎片太多会导致以后在程序运行过程中需要分配较大对象时,无法找到足够的连续内存而触发另一次垃圾收集动作。
- 耗时,效率不高
2.5.3.2 标记-复制(Mark-Copying)
将内存划分为两块相等的区域,每次只使用其中一块。当其中一块内存使用完了,就将还存活的对象复制到另外一块上面,然后把已经使用过的内存空间一次清除掉。
缺点:空间利用率低
2.5.3.3 标记-整理(Mark-Compact)
标记过程仍然与"标记-清除"算法一样,但是后续步骤不是直接对可回收对象进行清理,而是让所有存活 的对象都向一端移动,然后直接清理掉端边界以外的内存。
2.5.3.4 分代收集算法
Young区:复制算法(年轻代对象大部分是朝生夕死,存活对象较少,复制效率就高)
Old区:标记清除或者标记整理算法(Old区对象存活时间较长)
2.5.5 HotSpot中垃圾收集器
2.5.5.1 Serial
Serial收集器是最基本、发展历史最悠久的收集器,曾经(在JDK1.3.1之前)是虚拟机新生代收集的唯一 选择。
它是一种单线程收集器,不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作,更 重要的是其在进行垃圾收集的时候需要暂停其他线程。
优点:简单高效,拥有很高的单线程收集效率
缺点:收集过程需要暂停所有线程
算法:复制算法
适用范围:新生代
应用:JVM Client模式下的默认新生代收集器
2.5.5.2 Serial Old
Serial Old收集器是Serial收集器的老年代版本,也是一个单线程收集器,不同的是采用"标记-整理算 法",运行过程和Serial收集器一样。
2.5.5.3 ParNew
可理解为Serial收集器的多线程版本。
优点:在多CPU时,比Serial效率高。
缺点:收集过程暂停所有应用程序线程,单CPU时比Serial效率差。
算法:复制算法
适用范围:新生代
应用:运行在JVM Server模式下的虚拟机中首选的新生代收集器
2.5.5.4 Parallel Scavenge
Parallel Scavenge收集器是一个新生代收集器,它也是使用复制算法的收集器,又是并行的多线程收集 器,看上去和ParNew一样,但是Parallel Scanvenge更关注系统的吞吐量。
吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)
若吞吐量越大,意味着垃圾收集的时间越短,则用户代码可以充分利用CPU资源,尽快完成程序的 运算任务。
-XX:MaxGCPauseMillis控制最大的垃圾收集停顿时间,
-XX:GCRatio直接设置吞吐量的大小。
2.5.5.5 Parallel Old
Parallel Old收集器是Parallel Scavenge收集器的老年代版本,使用多线程和标记-整理算法进行垃圾回收,也是更加关注系统的吞吐量
2.5.5.6 CMS
CMS(Concurrent Mark Sweep)收集器是一种以获取 最短回收停顿时间为目标的收集器。采用的是"标记-清除算法",整个过程分为4步
1.初始标记 CMS initial mark 标记GC Roots直接关联对象,不用Tracing,速度很快
2.并发标记 CMS concurrent mark 进行GC Roots Tracing
3.重新标记 CMS remark 修改并发标记因用户程序变动的内容
- 并发清除
通过参数启用
优点:并发收集、低停顿
缺点:产生大量空间碎片、并发阶段会降低吞吐量。一般会遗Serial Old一起
2.5.5.7 G1(Garbage-First)
使用G1收集器时,Java堆的内存布局与就与其他收集器有很大差别,它将整个Java堆划分为多个 大小相等的独立区域(Region),虽然还保留有新生代和老年代的概念,但新生代和老年代不再 是物理隔离的了,它们都是一部分Region(不需要连续)的集合。
每个Region大小都是一样的,可以是1M到32M之间的数值,但是必须保证是2的n次幂 如果对象太大,一个Region放不下[超过Region大小的50%],那么就会直接放到H中 设置Region大小:-XX:G1HeapReginotallow=M
所谓Garbage-Frist,其实就是优先回收垃圾最多的Region区域
1.分代收集(仍然保留了分代的概念)
2.空间整合(整体上属于“标记-整理”算法,不会导致空间碎片)
3.可预测的停顿(比CMS更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片段内,消 耗在垃圾收集上的时间不得超过N毫秒)
工作过程可分为以下几步:
1.初始标记(Initial Marking) 标记以下GC Roots能够关联的对象,并且修改TAMS的值,需要暂停用户线程
2.并发标记(Concurrent Marking) 从GC Roots进行可达性分析,找出存活的对象,与用户线程并发执行
3.最终标记(Final Marking) 修正在并发标记阶段因为用户程序的并发执行导致变动的数据,需暂停用户线程
- .筛选回收(Live Data Counting and Evacuation) 对各个Region的回收价值和成本进行排序,根据 用户所期望的GC停顿时间制定回收计划
2.5.5.8 ZGC
官网:https://docs.oracle.com/en/java/javase/11/gctuning/z-garbage-collector1.html
JDK11新引入的ZGC收集器,不管是物理上还是逻辑上,ZGC中已经不存在新老年代的概念了 会分为一个个page,当进行GC操作时会对page进行压缩,因此没有碎片问题 只能在64位的linux上使用。
- 可以达到10ms以内的停顿时间要求
- 支持TB级别的内存
- 堆内存变大后停顿时间还是在10ms以内
2.5.5.9 垃圾收集器分类
- 串行收集器Serial 和 Serial Old
只能有一个垃圾回收线程执行,用户线程暂停。适用于内存比较小的嵌入式设备 - 并行收集器(吞吐量优先)Parallel Scanvenge,Parallel Old
多条垃圾回收线程并行工作,但此时用户线程处于等待状态。适用于科学计算、后台处理的场景 - 并发收集器
CMS、G1
用户线程和垃圾收集线程同时执行(但并不一定是并行的,可能是交替执行的),垃圾收集线程在执行的时 候不会停顿用户线程的运行。
适用于相对时间有要求的场景,比如Web 服务。
2.5.5.10 常见问题
- 吞吐量和停顿时间停顿时间:垃圾收集器进行垃圾回收终端应用执行响应的时间
吞吐量:运行用户代码时间/(运行用户代码时间+垃圾收集时间)
停顿时间越短就越适合需要和用户交互的程序,良好的响应速度能提升用户体验;高吞吐量则可以高效地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互 的任务。 - 如何选择合适的垃圾收集器https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html#sthref28
优先调整堆的大小让服务器自己来选择
如果内存小于100M,使用串行收集器
如果是单核,并且没有停顿时间要求,使用串行或JVM自己选
如果允许停顿时间超过1秒,选择并行或JVM自己选
如果响应时间最重要,并且不能超过1秒,使用并发收集器 - G1收集JDK 7开始使用,JDK 8非常成熟,JDK 9默认的垃圾收集器,适用于新老生代。
选择G1收集器的理由:
50%以上的堆被存活对象占用 ;对象分配和晋升的速度变化非常大 ;垃圾回收时间比较长
- G1中的Rset全称Remembered Set,记录维护Region中对象的引用关系
在G1垃圾收集器进行新生代的垃圾收集时,也就是Minor GC,假如该对象被老年代的Region中所引 用,这时候新生代的该对象就不能被回收,怎么记录呢? 用一个类似于hash的结构,key记录region的地址,value表示引用该对象的集合,这样就能知 道该对象被哪些老年代的对象所引用,从而不能回收。
- 如何开启需要的垃圾收集器
串行
-XX:+UseSerialGC -XX:+UseSerialOldGC
并行(吞吐量优先):
-XX:+UseParallelGC -XX:+UseParallelOldGC
并发收集器(响应时间优先) :
-XX:+UseConcMarkSweepGC -XX:+UseG1GC
三、深入学习
3.1 JVM参数
3.1.1 标准参数
-version -help -server -cp
3.1.2 -X参数
非标准参数,各个jdk版本中可能会变化
-Xint 解释执行模式
-Xcomp 编译模式
-Xmixed 混合模式 由JVM自己决定
3.1.3 -XX参数
使用最多的参数,非标准化参数,主要用于JVM调优和Debug
a.Boolean类型:-XX:[+-]<name> + -符号表示启用/禁用
例如:-XX:+UseG1GC
b.非Boolean类型 -XX:<name>=<value> <value>表示属性的值
例如:-XX:MaxHeapSize=1024M
3.1.4 其他参数
-Xms1024M ==> -XX:InitialHeapSize=1024M
-Xmx1024M ==> -XX:MaxHeapSize=1024M
-Xss512M ==> -XX:ThreadStackSize=512M
3.1.5 查看参数
java -XX:+PrintFlagsFinal -version > flags.txt
其中“=”表示默认值 “:=”表示被程序员或者JVM修改过的值
3.1.6 常用参数含义
参数 | 含义 | 说明 |
-XX:CICompilerCount=3 | 最大并行编译数 | 如果设置大于1,虽然编译速度 会提高,但是同样影响系统稳定 性,会增加JVM崩溃的可能 |
-XX:InitialHeapSize=100M | 初始化堆大小 | 简写-Xms100M |
-XX:MaxHeapSize=100M | 最大堆大小 | 简写-Xmx100M |
-XX:NewSize=20M | 设置年轻代的大小 | |
-XX:MaxNewSize=50M | 年轻代最大大小 | |
-XX:OldSize=50M | 设置老年代大小 | |
XX:MetaspaceSize=50M | 设置方法区大小 | |
-XX:MaxMetaspaceSize=50M | 方法区最大大小 | |
-XX:+UseParallelGC | 使用ParallelGC | 新生代,吞吐量优先 |
-XX:+UseParallelOldGC | 使用ParallelOldGC | 老年代,吞吐量优先 |
-XX:+UseConcMarkSweepGC | 使用CMS | 老年代,停顿时间优先 |
-XX:+UseG1GC | 使用G1 GC | 新生代、老年代停顿时间优先 |
-XX:NewRatio | 新生代和老年代的比值 | 比如-XX:Ratio=4,则表示新生代:老年代=1:4,也就是新生代占整个堆内存的1/5 |
-XX:SurvivorRatio | 两个S区和Eden区的比值 | 比如-XX:SurvivorRatio=8,也就是(S0+S1):Eden=2:8,也就是一个S占整个新生代的1/10 |
-XX:+HeapDumpOnOutOfMemoryError | 启动堆内存溢出打印 | 当JVM堆内存发生溢出时,也就是OOM,自动生成dump文件 |
-XX:HeapDumpPath=heap.hprof | 指定堆内存溢出打印目录 | 表示在当前目录生成一个 heap.hprof文件 |
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps | 打印GC日志 | |
-XX:ThreadStackSize=512k | 设置每个线程的堆栈大小 | -Xss128k |
-XX:MaxTenuringThreshold=6 | 提升年老代的最大临界值 默认值为 15 | 在对象头中,只占4bit,该值最大值为15 |
-XX:InitiatingHeapOccupancyPercent | 启动并发GC周期时堆内存使用占比 | G1之类的垃圾收集器用它来触发并发GC周期,基于整个堆的使用率,而不只是某一代内存的使用比.值为 0 则表示”一直执行GC循环”.默认值为 45. |
-XX:G1HeapWastePercent | 允许的浪费堆空间的占比 | 默认是10%,如果并发标记可回收的空间小于10%,则不会触发MixedGC。 |
-XX:MaxGCPauseMillis=200ms | G1最大停顿时间 | 暂停时间不能太小,太小的话就会导致出现G1跟不上垃圾产生的速度。最终退化成Full GC。所以对这个参数的调优是一个持续的过程,逐步调整到最佳状态。 |
-XX:Cnotallow=n | 并发垃圾收集器使用的线程数量 | 默认值随JVM运行的平台不同而不同 |
-XX:G1MixedGCLiveThresholdPercent=65 | 混合垃圾回收周期中要包括的旧区域设置占用率阈值 | 默认占用率为 65% |
-XX:G1MixedGCCountTarget=8 | 设置标记周期完成后,对存活数据上限为G1MixedGCLIveThresholdPercent的旧区域执行混合垃圾回收的目标次数 | 默认8次混合垃圾回收,混合回收的目标是要控制在此目标次数以内 |
-XX:G1OldCSetReginotallow=1 | 描述Mixed GC时,Old Region被加入到CSet中 | 默认情况下,G1只把10%的OldRegion加入到CSet中 |
3.2 常用命令
3.2.1 jps
查看java进程
3.2.2 jinfo
实时查看和调整JVM配置参数
jinfo -flag 参数名 pid 查看参数的值
例如; jinfo -flag MaxHeapSize 2169928
jinfo -flag InitialHeapSize 2169928
修改:参数只有被标记为manageable 的flags可以被实时修改
jinfo -flag [+|-] PID
jinfo -flag <name>=<value> PID
查看曾经赋过值的一些参数
jinfo -flags PID
3.2.3 jstat
查看虚拟机性能统计信息;
查看类装载信息
jstat -class PID 1000 10 查看该java进程的类装载信息,每1000毫秒输出一次,共10次
查看垃圾收集信息
jstat -gc PID 1000 10 查看该java进程的gc信息,每1000毫秒输出一次,共10次
3.2.4 jstack
查看线程堆栈信息
用法:jstack PID
死锁案列:
运行结果:
jstack分析,拉到最后:
3.2.5 jmap
生成堆转储快照:
打印堆内存相关信息:
dump出堆内存相关信息: jmap -dump:format=b,file=heap.hprof PID
设置JVM参数,当堆内存溢出时,自动dump出文件:
XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=heap.hprof
四、性能优化
JVM性能优化可以分为代码层面和非代码层面。代码层面一般结合字节码进行优化,非代码层面一般从内存,gc,CPU占用率等方面进行优化。JVM一般不需要优化。
4.1 内存
4.1.1 内存分配
正常情况下不需要设置,但在秒杀和促销的场景下,需要调整。默认情况下young:old=1:2,秒杀的情况下,就可能出现young区内存不够
4.1.2 内存溢出(OOM)
一般有两种原因:1.大并发场景 2:内存泄漏导致OOM
4.1.2.1 大并发(秒杀)优化
a.浏览器缓存、本地缓存、验证码
b.CDN静态资源服务器
c.集群+负载均衡
d.动静态资源分离、限流(基于令牌桶、漏桶算法)
e.应用级别缓存、接口防刷限流、队列、tomcat性能优化
f.异步消息中间件
g.Redis热点数据对象缓存(数据预热)
h.分布式锁、数据库锁
i.5分钟内没有支付订单,取消订单,恢复库存
4.1.2.2 内存泄漏导致内存溢出
ThreadLocal 使用完未删除,会导致内存泄漏
4.2 GC
4.2.1 是否选用G1
官网:https://docs.oracle.com/javase/8/docs/technotes/guides/vm/G1.html#use_cases
a.50%以上的堆被存活对象占用
b.对象分配和晋升速度变化比较大
c.垃圾回收时间比较长
4.2.2 G1调优
a.使用G1垃圾收集器:-XX:+UseG1GC
获取GC日志,使用GCViewer分析吞吐量和响应时间
b.调整内存大小之后,再获取gc日志分析
可以调整内存的大小
最大停顿时间:-XX:MaxGCPauseNillis=200
启动并发GC时堆内存占用百分比:-XX:InitiatingHeapOccupancyPercent=45
4.3 JVM性能优化指南
4.4. 常见问题
4.4.1 内存泄漏与内存溢出的区别
内存泄漏是指不再使用的对象无法得到及时的回收,持续占用内存空间,从而造成内存空间的浪费。内存泄漏很容易导致内存溢出,但内存溢出不一定是内存泄漏导致的。
4.4.2 young GC会有stw嘛?
无论什么
和
4.4.3 major gc 和full gc的区别
Major GC在很多参考资料中是等价于 Full GC 的,我们也可以发现很多性能监测工具中只有 Minor GC 和 Full GC。一般情况下,一次 Full GC 将会对年轻代、老年代、元空间以及堆外内存进行垃圾回收。触 发 Full GC 的原因有很多:当年轻代晋升到老年代的对象大小,并比目前老年代剩余的空间大小还要大 时,会触发 Full GC;当老年代的空间使用率超过某阈值时,会触发 Full GC;当元空间不足时(JDK1.7 永久代不足),也会触发 Full GC;System.gc() 也会安排一次 Full GC。
4.4.4 什么是直接内存
Java的NIO库允许Java程序使用直接内存。直接内存是在java堆外的、直接向系统申请的内存空间。通 常访问直接内存的速度会优于Java堆。因此出于性能的考虑,读写频繁的场合可能会考虑使用直接内 存。由于直接内存在java堆外,因此它的大小不会直接受限于Xmx指定的最大堆大小,但是系统内存是 有限的,Java堆和直接内存的总和依然受限于操作系统能给出的最大内存
4.4.5 垃圾判断方式
引用计数法:指的是如果某个地方引用了这个对象就+1,如果失效了就-1,当为0就会回收但是JVM没 有用这种方式,因为无法判定相互循环引用(A引用B,B引用A)的情况。
根可达:通过一种GC ROOT的对象(方法区中静态变量引用的对象等-static变量)来判断,如果有 一条链能够到达GC ROOT就说明,不能到达GC ROOT就说明可以回收。
4.4.6 不可达对象一定要被回收嘛
即使在可达性分析法中不可达的对象,也并非是“非死不可”的,这时候它们暂时处于“缓刑阶段”,要真 正宣告一个对象死亡,至少要经历两次标记过程;可达性分析法中不可达的对象被第一次标记并且进行 一次筛选,筛选的条件是此对象是否有必要执行 finalize 方法。当对象没有覆盖 finalize 方法,或 finalize 方法已经被虚拟机调用过时,虚拟机将这两种情况视为没有必要执行。 被判定为需要执行的对象将会被放在一个队列中进行第二次标记,除非这个对象与引用链上的任何一个 对象建立关联,否则就会被真的回收。
4.4.7 为什么要区分新生代和老年代
虚拟机的垃圾收集都采用分代收集算法,这种算法没有什么新的思想,只是根据对象存活周期的不同将内存分为几块。一般将
4.4.8 G1和CMS的区别是什么?
CMS 主要集中在老年代的回收,而 G1 集中在分代回收,包括了年轻代的 Young GC 以及老年代的 Mix GC;G1 使用了 Region 方式对堆内存进行了划分,且基于标记整理算法实现,整体减少了垃圾碎片的 产生;在初始化标记阶段,搜索可达对象使用到的 Card Table,其实现方式不一样。
4.4.9 方法区中的无用类回收
方法区主要回收的是无用的类,那么如何判断一个类是无用的类的呢?判定一个常量是否是“废弃常量”比较简单,而要判定一个类是否是“无用的类”的条件则相对苛刻许多。 类需要同时满足下面 3 个条件才能算是 “无用的类” :
a-该类所有的实例都已经被回收,也就是 Java 堆中不存在该类的任何实例。
b-加载该类的 ClassLoader 已经被回收。
c-该类对应的 java.lang.Class 对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。