什么是JVM
Java Virtual Machine,Java虚拟机
Java虚拟机有自己完善的硬件架构,如处理器、堆栈等,还具有相应的指令系统。
Java虚拟机本质上就是一个程序,当它在命令行上启动的时候,就开始执行保存在某字节码文件中的指令。Java语言的可移植性正是建立在Java虚拟机的基础上。任何平台只要装有针对于该平台的Java虚拟机,字节码文件(.class)就可以在该平台上运行。这就是“一次编译,多次运行”。
Java虚拟机不仅是一种跨平台的软件,而且是一种新的网络计算平台。该平台包括许多相关的技术,如符合开放接口标准的各种API、优化技术等。Java技术使同一种应用可以运行在不同的平台上。Java平台可分为两部分,即Java虚拟机(Java virtual machine,JVM)和Java API类库。
作用:JVM是java字节码执行的引擎,解析字节码文件的内容,并将其翻译为各种操作系统能理解的机器码
运作过程:解析字节码文件的时候,会先加载字节码文件,将其存入java虚拟机的内存空间中,进行一系列的动作,最后运行程序得出结果
JVM内存空间
字节码数据在java虚拟机内存中如何存放的?
虚拟机栈
用于执行java方法,每个方法执行都会创建一个栈帧,存储局部变量表,操作数栈,动态链接等信息,程序执行时,栈帧入栈,执行完成后栈帧出栈
程序计数器
或者叫PC寄存器,记载着每一个线程当前运行的JAVA方法的地址,指示当前程序执行到了哪个位置:
1、执行Java方法时记录正在执行的虚拟机字节码指令地址;
2、执行本地方法时,计数器值为null;
每一个线程都有一个PC寄存器,也就是说PC寄存器是线程独有的。
生命周期跟随线程,线程启动而产生,线程结束而消亡。
是一块较小的内存空间,它的作用可以看做是当前线程所执行的字节码的行号指示器。
本地方法区
如果程序有使用到native方法,加载和执行就在这个区域。
方法区
存储 Java 类字节码数据的一块区域,存储类,常量相关的信息。
Java堆
Java虚拟机管理的内存中最大的一块,Java虚拟机启动的时候建立,所有线程共享,几乎所有的对象实例都在这里分配内存。
GC主要就是在Java堆中进行的。
Java 堆根据对象存活时间的不同,Java 堆还被分为新生代(或叫 年轻代)、老年代两个区域,新生代还被进一步划分为 Eden 区、Survivor 0、Survivor 1 区。
新生代
- 新生代内存按照8:1:1的比例分为一个Eden区和两个survivor区(survivor0和survivor1);
- 当有对象需要分配时,优先被分配在年轻代的 Eden 区;
- 当Eden区满了,就需要进行垃圾回收(Minor GC),回收 Eden 区中没有被引用的对象(可达性分析);
- 在年轻代的对象经过了指定次数(默认15次)的 GC 后,将在下次 GC 时进入老年代;
- 两个survivor区(survivor0和survivor1)
老年代
- 老年代存放的都是一些生命周期较长的对象,或者是很大的对象(大于Eden区空间);
- 默认的,新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 ),即:新生代 ( Young ) = 1/3 的堆空间大小,老年代 ( Old ) = 2/3 的堆空间大小;
- 将对象从新生代移到老年代时,如果此时老年代空间不够,那么触发 Major GC。
GC介绍
GC,即垃圾回收
英语:Garbage Collection,缩写为GC
GC是一种自动的内存管理机制
垃圾回收的术语:
Minor GC
从新生代空间回收内存被称为 Minor GC,有时候也称之为 Young GC。
Major GC
从老年代空间回收内存被称为 Major GC,有时候也称之为 Old GC。
Full GC
Full GC 是清理整个堆空间 —— 包括新生代、老年代。因此 Full GC 可以说是 Minor GC 和 Major GC 的结合。
Stop-The-World
翻译为全世界暂停,简称 STW,是指在进行垃圾回收时,因为标记或清理的需要,必须让所有执行任务的线程停止执行任务,从而让垃圾回收线程完成回收垃圾的时间。
垃圾回收机制的重点:
哪些内存需要回收?
垃圾收集器会对堆进行回收前,确定对象中哪些是“存活”,哪些是“死亡”(不可能再被任何途径使用的对象);
当一个对象到GC Roots没有任何引用链相连,即不可达时,则证明此对象时不可用的。
举例:一颗树有很多丫枝,其中一个分支断了,跟树上没有任何联系,那就说明这个分支没有用了,就可以当垃圾回收去烧了。
什么时候回收?
主要的场景:
(1)JVM 无法为一个新的对象分配空间时会触发 Minor GC
(2)老年代空间不够,那么触发 Major GC
(3)当准备要触发一次Minor GC时,如果出现历史Minor GC的平均晋升大小比目前 “老年代”剩余的空间大,老年代剩余空间不够用于新生代晋升,则不会触发young GC,而是转为触发full GC
如何回收?
垃圾收集算法:
1)标记—清除算法
标记—清除算法(Mark-Sweep),是最基础的收集算法,它分为“标记”和“清除”两个阶段:首先标记出所需回收的对象,在标记完成后统一回收掉所有被标记的对象,它的标记过程是通过可达性分析算法实现的。
回收前状态
回收后状态
算法缺点:
标记和清除过程的效率都不高;标记清除后会产生大量不连续的内存碎片。
2)复制算法
复制算法将可用内存按容量分为大小相等的两块,每次只使用其中的一块,当这一块的内存用完了,就将还存活着的对象复制到另外一块内存上面,然后再把已使用过的内存空间一次清理掉。
回收前状态
回收后状态
复制算法优点:
每次只对一块内存进行回收,运行高效;大大减少了内存碎片的出现;
缺点:
可初始分配的最大内存缩小了一半;
3)标记—整理算法
分为“标记”、“整理”、“清除”三个阶段
先对内存区域的对象进行标记,区分出“存活对象”和“可回收对象”,
让所有的对象都向内存区域一端移动,直接清理掉可回收的对象;
回收前状态
回收后状态
4)分代回收
根据对象的存活周期的不同,将内存划分为新生代和老年代。
在新生代中,每次垃圾收集时都会发现有大量对象死去,只有少量存活,因此可选用复制算法来完成收集;
新生代中的对象98%都是“朝生夕死”的,所以并不需要按照1:1的比例来划分内存空间,而是将内存分为一块比较大的Eden空间和两块较小的Survivor空间(8:1:1的比例),每次使用Eden和其中一块Survivor。当回收时,将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上,最后清理掉Eden和刚才用过的Survivor空间。
每次新生代中可用内存空间为整个新生代容量的90%(80%+10%),只有10%的空间会被预留。
老年代中因为对象存活率高、没有额外空间对它进行分配担保,就使用标记—清除算法或标记—整理算法来进行回收
新生代回收
JVM常用参数
Jvm启动参数共分为三类:
一、是标准参数(-),所有的JVM实现都必须实现这些参数的功能,而且向后兼容;
二、是非标准参数(-X),默认jvm实现这些参数的功能,但是并不保证所有jvm实现都满足,且不保证向后兼容;
三、是非Stable参数(-XX),此类参数各个jvm实现会有所不同;
-Xms256m
为jvm启动时分配的内存
-Xmx256m
为jvm运行过程中分配的最大内存,建议和Xms保持一致
-Xmn128m
设置年轻代大小为128M
此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。
-Xss256k
为jvm启动的每个线程分配的内存大小
-XX:NewSize 和-XX:MaxNewSize
用于设置年轻代的大小,建议设为整个堆大小的1/3或者1/4,两个值设为一样大。
-XX:PermSize=1024M 和 -XX:MaxPermSize=1024M
JVM初始分配的非堆内存, 不会被回收, 建议与maxPermSize相同
-XX:SurvivorRatio=4
年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。
设置为4,则两个Survivor区与一个Eden区的比值为2:4,一个Survivor区占整个年轻代的1/6
-XX:NewRatio=4
设置年轻代(EC+S0C+S1C)和年老代(OC)的比值。如:为4,表示年轻代与年老代比值为1:4,年轻代占整个年轻代年老代和的1/5
-XX:InitialTenuringThreshol 和-XX:MaxTenuringThreshold
用于设置晋升到老年代的对象年龄的最小值和最大值,每个对象在坚持过一次Minor GC之后,年龄就加1。
-XX:+PrintGC 输出GC日志
-XX:+PrintGCDetails 输出GC的详细日志
-XX:+PrintGCTimeStamps 输出GC的时间戳(以基准时间的形式)
-XX:+PrintGCDateStamps 输出GC的时间戳(以日期的形式,如 2013-05-04T21:53:59.234+0800)
-Xloggc:../logs/gc.log 日志文件的输出路径
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=20M
JVM的一个日志文件达到了20M以后,就会写入另一个新的文件,最多会有5个日志文件,他们的名字分别是:gc.log.0、gc.log.1 等
-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
-XX:+PrintTenuringDistribution
这个参数用于显示每次Minor GC时Survivor区中各个年龄段的对象的大小。
2020-06-29T03:45:25.512+0800: 76.642: [GC pause (G1 Evacuation Pause) (young)
Desired survivor size 402653184 bytes, new threshold 2 (max 15)
- age 1: 169351248 bytes, 169351248 total
- age 2: 331023392 bytes, 500374640 total
- age 3: 64201192 bytes, 564575832 total
, 1.2957512 secs]
-XX:MaxTenuringThreshold
用于调整对象晋升老年代的所需经历的GC次数,默认15次,即在年轻代的对象经过了指定次数的 GC 后,将在下次 GC 时进入老年代。
JVM调优浅谈
JVM内存管理很差会出现什么情况?
1,内存溢出
2,频繁Full GC
….
内存溢出:
-
OutOfMemoryError: Java heap space 堆溢出
最常见的内存溢出,当在JVM中如果98%的时间是用于GC且可用的 Heap size 不足2%的时候将抛出此异常信息。
优化建议:
Heap Size 最大不要超过可用物理内存的80%,一般的要将-Xms和-Xmx选项设置为相同,而-Xmn为3/8的-Xmx值。
-
OutOfMemoryError: PermGen space 非堆溢出(永久保存区域溢出)
这块内存主要是被JVM存放Class和Meta信息的,是 JVM初始分配的非堆内存,没有GC回收,一般发生在程序的启动阶段。
优化建议:
通过-XX:PermSize和 -XX:MaxPermSize设置合适的内存大小
-
OutOfMemoryError: unable to create new native thread. 无法创建新的线程
常见在高并发的业务场景,线程池一直新建线程,每个线程都有自己的Stack Space,Stack Space的空间是独立分配的,当超出jvm的栈内存大小时, 就会报出无法再创建线程的错误.
优化建议:
设置合适的-Xss参数,优化线程池资源分配。
-
java.lang.StackOverflowError : Thread Stack space
栈溢出了,常见于代码递归的层次过多。
优化建议:
修改程序、设置合适的-Xss参数。
MinorGC 日志
2020-06-23T04:35:59.604+0800: 463.092: [GC (Allocation Failure)
2020-06-23T04:35:59.604+0800: 463.092: [ParNew: 43296K->7006K(47808K), 0.0136826 secs]
44992K->8702K(252608K), 0.0137904 secs] [Times: user=0.03 sys=0.00, real=0.02 secs]
2020-06-23T04:35:59.604+0800 日志文件的时间戳
463.092 JVM记录的时间戳:GC开始,相对JVM启动的相对时间,单位是秒
GC 触发了YoungGC/MinorGC
Allocation Failure – MinorGC的原因,由于年轻代不满足申请的空间,因此触发了MinorGC
[ParNew(使用ParNew作为新生代的垃圾回收器,采用的是复制算法): 43296K(年轻代垃圾回收前的大小)->7006K(年轻代垃圾回收以后的大小)(47808K)
(年轻代的总大小), 0.0136826 secs(回收时间)] 44992K(堆区垃圾回收前的大小)->8702K(堆区垃圾回收后的大小)(252608K)(堆区总大小), 0.0137904 secs(回收时间)]
[Times: user=0.03 sys=0.00, real=0.02 secs]
user:GC 线程在垃圾收集期间所使用的 CPU 总时间;
sys:系统调用或者等待系统事件花费的时间;
real:应用被暂停的时钟时间,由于 GC 线程是多线程的,导致了 real 小于 (user+real),如果是 gc 线程是单线程的话,real 是接近于 (user+real) 时间。
FullGC 日志
2018-04-12T13:48:26.233+0800: 15578.148: [GC [1 CMS-initial-mark: 6294851K(20971520K)]
6354687K(24746432K), 0.0466580 secs] [Times: user=0.04 sys=0.00, real=0.04 secs]
2018-04-12T13:48:26.280+0800: 15578.195: [CMS-concurrent-mark-start]
2018-04-12T13:48:26.418+0800: 15578.333: [CMS-concurrent-mark: 0.138/0.138 secs]
[Times: user=1.01 sys=0.21, real=0.14 secs]
2018-04-12T13:48:26.418+0800: 15578.334: [CMS-concurrent-preclean-start]
2018-04-12T13:48:26.476+0800: 15578.391: [CMS-concurrent-preclean: 0.056/0.057 secs]
[Times: user=0.20 sys=0.12, real=0.06 secs]
2018-04-12T13:48:26.476+0800: 15578.391: [CMS-concurrent-abortable-preclean-start]
2018-04-12T13:48:29.989+0800: 15581.905: [CMS-concurrent-abortable-preclean: 3.506/3.514 secs]
[Times: user=11.93 sys=6.77, real=3.51 secs]
2018-04-12T13:48:29.991+0800: 15581.906: [GC[YG occupancy: 1805641 K (3774912 K)]
2018-04-12T13:48:29.991+0800: 15581.906: [GC2018-04-12T13:48:29.991+0800: 15581.906:
[ParNew: 1805641K->48395K(3774912K), 0.0826620 secs] 8100493K->6348225K(24746432K),
0.0829480 secs] [Times: user=0.81 sys=0.00, real=0.09 secs]2018-04-12T13:48:30.074+0800:
15581.989: [Rescan (parallel) , 0.0429390 secs]2018-04-12T13:48:30.117+0800: 15582.032:
[weak refs processing, 0.0027800 secs]2018-04-12T13:48:30.119+0800: 15582.035: [class
unloading, 0.0033120 secs]2018-04-12T13:48:30.123+0800: 15582.038: [scrub symbol table,
0.0016780 secs]2018-04-12T13:48:30.124+0800: 15582.040: [scrub string table, 0.0004780
secs] [1 CMS-remark: 6299829K(20971520K)] 6348225K(24746432K), 0.1365130 secs]
[Times: user=1.24 sys=0.00, real=0.14 secs]
2018-04-12T13:48:30.128+0800: 15582.043: [CMS-concurrent-sweep-start]
2018-04-12T13:48:38.412+0800: 15590.327: [CMS-concurrent-sweep: 8.193/8.284 secs]
[Times: user=30.34 sys=16.44, real=8.28 secs]
2018-04-12T13:48:38.419+0800: 15590.334: [CMS-concurrent-reset-start]
2018-04-12T13:48:38.462+0800: 15590.377: [CMS-concurrent-reset: 0.044/0.044 secs]
[Times: user=0.15 sys=0.10, real=0.04 secs]
阶段1:Initial Mark
2018-04-12T13:48:26.233+0800: 15578.148: [GC [1 CMS-initial-mark: 6294851K(20971520K)]
6354687K(24746432K), 0.0466580 secs] [Times: user=0.04 sys=0.00, real=0.04 secs]
CMS-initial-mark:初始标记阶段,CMS是老年代垃圾回收器,基于标记-清除算法实现,
它会收集所有 GC Roots 以及其直接引用的对象;
6294851K:当前老年代使用的容量,这里是 6G;
(20971520K):老年代可用的最大容量,这里是 20G;
6354687K:整个堆目前使用的容量,这里是 6.06G;
(24746432K):堆可用的容量,这里是 23.6G;
0.0466580 secs:这个阶段的持续时间;
这个是 CMS 两次 stop-the-wolrd 事件的其中一次,这个阶段的目标是:标记那些直接被 GC root 引用
或者被年轻代存活对象所引用的所有对象
阶段2:CMS-concurrent-mark
2018-04-12T13:48:26.280+0800: 15578.195: [CMS-concurrent-mark-start]
2018-04-12T13:48:26.418+0800: 15578.333: [CMS-concurrent-mark: 0.138/0.138 secs]
[Times: user=1.01 sys=0.21, real=0.14 secs]
CMS-concurrent-mark:并发标记阶段,遍历老年代,标记所有存活的对象,由第一阶段标记过的对象出发,
所有可达的对象都在本阶段标记;
0.138/0.138 secs:这个阶段的持续时间与时钟时间;
2018-04-12T13:48:26.418+0800: 15578.334: [CMS-concurrent-preclean-start]
2018-04-12T13:48:26.476+0800: 15578.391: [CMS-concurrent-preclean: 0.056/0.057 secs]
[Times: user=0.20 sys=0.12, real=0.06 secs]
阶段3:Concurrent Preclean
Concurrent Preclean :并发预清理阶段,对在前面并发标记阶段中引用发生变化的对象进行标记,
包含:从新生代晋升、新分配、被更新的对象,并发地重新扫描这些对象;
0.056/0.057 secs:这个阶段的持续时间与时钟时间;
2018-04-12T13:48:26.476+0800: 15578.391: [CMS-concurrent-abortable-preclean-start]
2018-04-12T13:48:29.989+0800: 15581.905: [CMS-concurrent-abortable-preclean:
3.506/3.514 secs] [Times: user=11.93 sys=6.77, real=3.51 secs]
阶段4:Concurrent Abortable Preclean
Concurrent Abortable Preclean :并发可中止的预清理阶段,和上一阶段工作内容一样,但可以控制结束
时间,这个阶段持续时间依赖于很多的因素:完成的工作量、扫描持续时间等;
2018-04-12T13:48:29.991+0800: 15581.906: [GC[YG occupancy: 1805641 K (3774912 K)]
2018-04-12T13:48:29.991+0800: 15581.906: [GC2018-04-12T13:48:29.991+0800: 15581.906:
[ParNew: 1805641K->48395K(3774912K), 0.0826620 secs] 8100493K->6348225K(24746432K),
0.0829480 secs] [Times: user=0.81 sys=0.00, real=0.09 secs]
2018-04-12T13:48:30.074+0800: 15581.989: [Rescan (parallel) , 0.0429390 secs]
2018-04-12T13:48:30.117+0800: 15582.032: [weak refs processing, 0.0027800 secs]
2018-04-12T13:48:30.119+0800: 15582.035: [class unloading, 0.0033120 secs]
2018-04-12T13:48:30.123+0800: 15582.038: [scrub symbol table, 0.0016780 secs]
2018-04-12T13:48:30.124+0800: 15582.040: [scrub string table, 0.0004780 secs]
[1 CMS-remark: 6299829K(20971520K)] 6348225K(24746432K), 0.1365130 secs]
[Times: user=1.24 sys=0.00, real=0.14 secs]
阶段5:remark
remark 重标记阶段
重标记阶段(CMS的第二个STW阶段),暂停所有用户线程,从GC Root开始重新扫描整堆,标记存活的对象。
虽然CMS只回收老年代的垃圾对象,但是这个阶段依然需要扫描新生代,因为很多GC Root都在新生代,
而这些GC Root指向的对象又在老年代,这称为“跨代引用”。
YG occupancy: 1805641 K (3774912 K):年轻代当前占用量及总容量,这里分别是 1.71G 和 3.6G;
ParNew:触发了一次 young GC,原因是为了减少年轻代的存活对象,尽量使年轻代更干净一些;
[Rescan (parallel) , 0.0429390 secs]:这个 Rescan 是当应用暂停的情况下完成对所有存活对象的标记,
这个阶段是并行处理的,这里花费了 0.0429390s;
[weak refs processing, 0.0027800 secs]:第一个子阶段,它的工作是处理弱引用;
[class unloading, 0.0033120 secs]:第二个子阶段,它的工作是:unloading the unused classes;
[scrub symbol table, 0.0016780 secs]、[scrub string table, 0.0004780 secs]:
最后一个子阶段,它的目的是:cleaning up symbol and string tables which hold class-level
metadata and internalized string respectively
CMS-remark:remark结束,输出当前老年代的使用量与总量6299829K(20971520K),
堆的使用量与总量6348225K(24746432K)
2018-04-12T13:48:30.128+0800: 15582.043: [CMS-concurrent-sweep-start]
2018-04-12T13:48:38.412+0800: 15590.327: [CMS-concurrent-sweep: 8.193/8.284 secs]
[Times: user=30.34 sys=16.44, real=8.28 secs]
阶段6:并发清理阶段
这个阶段主要是清除那些没有被标记的对象,回收它们的占用空间;这里不需要 STW,
它是与用户的应用程序并发运行。
2018-04-12T13:48:38.419+0800: 15590.334: [CMS-concurrent-reset-start]
2018-04-12T13:48:38.462+0800: 15590.377: [CMS-concurrent-reset: 0.044/0.044 secs]
[Times: user=0.15 sys=0.10, real=0.04 secs]
阶段7:Concurrent Reset阶段
这个阶段也是并发执行的,它会重设 CMS 内部的数据结构,为下次的 GC 做准备。
Full GC频繁发生怎么办?
排查方向:
1、根据FULLGC日志分析,消耗在什么阶段;
2、JVM参数设置不合理;
3、是否有内存泄露;
4、对象的内存分配存在问题,大对象过多;
5、使用jstat、jstack、jmap命令定位;