JVM学习记录
运行时数据区
-
方法区(线程共享)
存放类信息,常量,静态变量,即时编译器编译后的代码,
若是方法区中存在引用类型的静态变量, 那么就是方法区中的元素指向堆中的元素
public static Object obj = new Object();
-
堆(线程共享)
方法区中会包含类的信息,堆中会有对象,那么那个对象是由那个类创建的??
此时堆会指向方法区Old区、Young区(Eden区 、From区、To区) (8 :1 :1)
-
虚拟机栈
方法执行区域,n个栈帧
- 栈帧
- 局部变量表
- 方法中定义的局部变量以及方法的参数存放在这张表中,局部变量表中的变量不可直接使用,如需要使用的话,必须通过相关指令将其加载至操作数栈中作为操作数使用
- 操作数栈
- 以压栈和出栈的方式存储操作数,如果操作数栈中有引用类型变量, 这时就是栈中元素 指向堆中的对象
- 局部变量表
- 栈帧
-
本地方法栈
用于执行Native类型的方法
- Java方法执行的时候调用native类型方法呢? 通过虚拟机栈动态链接到本地方法栈?
-
程序计数器
用于维护一个变量,记录线程执行到的位置线程正在执行 Java 方法,则计数器记录的是正在执行的虚拟机字节码指令的地址如果正在执行的是Native方法,则这个计数器为空
Garbage Collect
什么才是垃圾对象,如何判断对象为垃圾对象?
-
引用计数法
- 一个对象没有任何指针对其引用,就是垃圾对象
- 如果两个对象相互持有引用,那么这两个对象将永久不能被回收
-
可达性分析
- 通过
GC
Root 对象,开始向下遍历,看某个对象是否可达,采用三色标记- 白色:表示对象尚未被垃圾收集器访问过
- 黑色:表示对象已经被垃圾收集器访问过,且这个对象的所有引用都已经扫描过
- 灰色:表示对象已经被垃圾收集器访问过,但这个对象至少存在一个引用还没被扫描过
- 通过
什么时候进行垃圾回收?
GC
是由JVM
自动完成的,根据Jvm
系统环境而定,垃圾回收时机是不确定的,即使调用System.gc();
通知JVM
回收,但时机也是不确定的,而且也不建议手动调用该方法,因为GC
消耗的资源比较大
垃圾怎么进行回收?
-
标记-清除(Mark-Sweep)
- 扫描堆中的所有对象,从而确定需要回收的对象,比较耗时
- 清除掉标记需要回收的对象,释放内存空间
- 缺点
- 标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。 (提前触发GC操作)
- 标记和清除两个过程都比较耗时,效率很低
- 扫描堆中的所有对象,从而确定需要回收的对象,比较耗时
-
标记-复制(Mark-Copying)
-
将内存划分为两块相等的区域,每次只使用其中一块
-
将还存活的对象复制到另外一块上面,然后把已经使用过的内存空间一次清除掉
-
缺点
- 空间利用率低
-
- 标记-整理(Mark-Compact)
- 扫描堆中的所有对象,标记出需要被回收的对象
- 清理掉被标记的对象,把所有存活的对象都移向一端
- 扫描堆中的所有对象,标记出需要被回收的对象
- 分代收集算法
- **Young区: ** 复制算法(对象在被分配之后,可能生命周期比较短,Young区复制效率比较高)
- **Old区: **标记清除或标记整理(Old区对象存活时间比较长,复制来复制去没必要,不如做个标记再清理)
-
垃圾收集器
如果说收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。
-
Serial (复制算法)
Serial是一种单线程收集器,不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作,更重要的是其在进行垃圾收集的时候需要暂停其他线程。
- 优点
- 简单高效,拥有很高的单线程收集效率
- 缺点
- 收集过程需要暂停所有线程
- 适用范围
- 新生代
- 应用
- Client模式下的默认新生代收集器
- 优点
-
Serial Old (标记-整理算法)
Serial Old收集器是Serial收集器的老年代版本,也是一个单线程收集器,不同的是采用 标记整理算法,运行过程和Serial收集器一样。
-
ParNew
(复制算法)ParNew
相当于Serial收集器的多线程版本- 优点
- 在多CPU时,比Serial效率高
- 缺点
- 收集过程暂停所有应用程序线程,单CPU时比Serial效率差。
- 适用范围
- 新生代
- 应用
- 运行在Server模式下的虚拟机中首选的新生代收集器
- 优点
-
Parallel Scavenge (复制算法)
Parallel Scavenge收集器是一个新生代收集器,它也是使用复制算法的收集器,又是并行的多线程收集器,看上去和
ParNew
一样,但是Parallel Scanvenge
更关注系统的吞吐量。吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)
比如虚拟机总共运行了100分钟,垃圾收集时间用了1分钟,吞吐量=(100-1)/100=99%。
若吞吐量越大,意味着垃圾收集的时间越短,则用户代码可以充分利用CPU资源,尽快完成程序
的运算任务。
-XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间, -XX:GCRatio 直接设置吞吐量的大小。
-
Parallel Old (标记-整理算法)
Parallel Old收集器是Parallel Scavenge收集器的老年代版本,使用多线程和标记-整理算法进行垃圾回收,也是更加关注系统的吞吐量。
-
CMS
(Concurrent Mark Sweep) (标记-清除算法)CMS
收集器是一种以获取最短回收停顿时间
为目标的收集器。采用的是"标记-清除算法",整个过程分为4步(1)初始标记
CMS
initial mark 标记GC Roots
直接关联对象,不用Tracing,速度很快(2)并发标记
CMS
concurrent mark 进行GC Roots Tracing
(3)重新标记
CMS
remark 修改并发标记因用户程序变动的内容(4)并发清除
CMS
concurrent sweep 清除不可达对象回收空间,同时有新垃圾产生,留着下次清理称为浮动垃圾由于整个过程中,并发标记和并发清除,收集器线程可以与用户线程一起工作,所以总体上来说,
CMS
收集器的内存回收过程是与用户线程一起并发地执行的- 优点
- 并发收集、低停顿
- 缺点
- 产生大量空间碎片、并发阶段会降低吞吐量
- 优点
-
G1
(Garbage-First) ()使用
G1
收集器时,Java堆的内存布局与就与其他收集器有很大差别,它将整个Java堆划分为多个大小相等的独立区域(Region),虽然还保留有新生代和老年代的概念,但新生代和老年代不再
是物理隔离的了,它们都是一部分Region(不需要连续)的集合。
每个Region大小都是一样的,可以是
1M
到32M
之间的数值,但是必须保证是2的n次幂如果对象太大,一个Region放不下[超过Region大小的50%],那么就会直接放到H中
设置Region大小:
-XX:G1HeapRegionSize=M
所谓Garbage-First,其实就是优先回收垃圾最多的Region区域
- 分代收集(仍然保留了分代的概念)
- 空间整合(整体上属于“标记-整理”算法,不会导致空间碎片)
- 可预测的停顿(比
CMS
更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒)
工作过程
初始标记(Initial Marking) 标记以下
GC
Roots能够关联的对象,并且修改TAMS的值,需要暂停用户线程并发标记(Concurrent Marking)从
GC
Roots进行可达性分析,找出存活的对象,与用户线程并发执行最终标记(Final Marking) 修正在并发标记阶段因为用户程序的并发执行导致变动的数据,需暂停用户线程
筛选回收(Live Data Counting and Evacuation) 对各个Region的回收价值和成本进行排序,根据用户所期望的
GC
停顿时间制定回收计划-
ZGC
Jdk11
新引入的ZGC
收集器,不管是物理上还是逻辑上,ZGC
中已经不存在新老年代的概念了会分为一个个page,当进行
GC
操作时会对page进行压缩,因此没有碎片问题只能在64位的Linux上使用,目前用得还比较少
- 可以达到10 ms以内的停顿时间要求
- 支持TB级别的内存
- 堆内存变大后停顿时间还是在10 ms以内
-
-
垃圾收集器分类
-
串行收集器->Serial和Serial Old
只能有一个垃圾回收线程执行,用户线程暂停。适用于内存比较小的嵌入式设备
-
并行收集器 [吞吐量优先]->
Parallel Scanvenge
、Parallel Old多条垃圾收集线程并行工作,但此时用户线程仍然处于等待状态。适用于科学计算、后台处理等若交互场景
-
并发收集器[停顿时间优先]->
CMS
、G1
用户线程和垃圾收集线程同时执行(但并不一定是并行的,可能是交替执行的),垃圾收集线程在执行的时候不会停顿用户线程的运行
适用于相对时间有要求的场景,比如Web
-
-
常见问题
-
吞吐量和停顿时间
- 停顿时间 -> 垃圾收集器进行垃圾回收终端应用执行响应的时间
- 吞吐量 -> 运行用户代码时间 / (运行用户代码时间+垃圾收集时间)
停顿时间越短就越适合需要和用户交互的程序,良好的响应速度能提升用户体验;
高吞吐量则可以高效地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。
-
-
如何选择合适的垃圾收集器
- 优先调整堆的大小让服务器自己来选择
- 如果内存小于100 M,使用串行收集器
- 如果是单核,并且没有停顿时间要求,使用串行或
Jvm
自己选 - 如果允许停顿时间超过1秒,选择并行或
JVM
自己选 - 如果响应时间最重要,并且不能超过1秒,使用并发收集器
-
开启需要的垃圾收集器
1.串行 -XX:+UseSerialGC -XX:+UseSerialOldGC 2.并行(吞吐量优先): -XX:+UseParallelGC -XX:+UseParallelOldGC 3.并发收集器(响应时间优先) -XX:+UseConcMarkSweepGC -XX:+UseG1GC
Jvm
参数
-
标准参数
-version -help -server -cp
-
-X参数
非标准参数,也就是在
JDK
个版本之间可能会变动-Xint 解释执行 -Xcomp 第一次使用就编译成本地代码 -Xmixed 混合模式,JVM自己来决定
-
-XX参数
非标准化参数,相对不稳定,主要用于
JVM
调优和Debuga.Boolean类型 格式:-XX:[+-]<name> +或-表示启用或者禁用name属性 比如:-XX:+UseConcMarkSweepGC 表示启用CMS类型的垃圾回收器 -XX:+UseG1GC 表示启用G1类型的垃圾回收器 b.非Boolean类型 格式:-XX<name>=<value>表示name属性的值是value 比如:-XX:MaxGCPauseMillis=500
-
其他参数
这块相当于就是 -XX类型的参数
-Xms1000M 等价于 -XX:InitialHeapSize=1000M -Xmx1000M 等价于 -XX:MaxHeapSize=1000M -Xss100 等价于 -XX:ThreadStackSize=100
-
查看参数
java -XX:+PrintFlagsFinal -version > flags.txt sz flags.txt
-
设置参数的常见方式
- 开发工具中设置比如IDEA,eclipse
- 运行jar包的时候:
java -XX:+UseG1GC xxx.jar
- web容器比如tomcat,可以在脚本中的进行设置
- 通过
jinfo
实时调整某个 Java 进程的参数(参数只有被标记为manageable的flflags
可以被实时修改)
-
实践
-
设置堆内存大小和参数打印
-Xmx100M -Xms100M -XX:+PrintFlagsFinal
-
查询
+PrintFlagsFinal
的值:=true
-
查询堆内存大小
MaxHeapSize
:= 104857600
-
-
常见参数