JVM调优
2024-01-04 16:12:59 20 举报AI智能生成
登录查看完整内容
JVM调优是指对Java虚拟机进行性能优化，以提高应用程序的运行效率和响应速度。JVM调优主要包括内存管理、垃圾回收、线程管理等方面。常用的JVM调优工具有VisualVM、JConsole、JProfiler等。在进行JVM调优时，需要根据应用程序的特点和需求，选择合适的调优策略和方法。例如，可以通过调整堆内存大小、新生代与老年代比例、垃圾回收器参数等来优化内存管理；通过调整线程池大小、线程栈大小等来优化线程管理。总之，JVM调优是一项复杂而重要的工作，需要开发人员具备一定的专业知识和实践经验。
作者其他创作
大纲/内容
加载
验证
准备
解析
初始化
使用
卸载
类加载的过程
定义
引导类加载器：BootStrapClassLoader
扩展类加载器：ExtClassLoader
应用程序加载器：AppClassLoader
自定义类加载器：MyClassLoader
类加载器
实现原理
沙箱安全机制
避免类重复加载
如此设计的好处
自定义类加载器重写loadClass与findClass方法
Java的SPI机制
打破双亲委派模型
双亲委派模型
JVM类加载机制
作用: 记住下一条JVM指令的执行地址
1.线程私有2.唯一一个无内存溢出的区3.内存地址不断动态变化：程序每运行一步字节码执行引擎都会修改4.多线程也记住上次中断或挂起执行的位置
特点
程序计数器
作用
一些本地方法
本地方法栈
栈帧：一个方法对应一个栈帧，读取方法时，压入栈帧底部
出入栈规则
局部变量表
保存计算过程的中间结果，存储计算过程中的临时变量
操作数栈
栈帧内部包含一个指向运行时常量池中该栈帧所属方法的引用（地址：直接引用 程序运行过程中，将符号引用转换为内存中的对应地址）符号： 方法名，类名ex：public int computer(){}在方法区中有个地址，xxx.computer() => 通过动态链接将符号转为地址
动态链接
在方法退出之前，都需要返回到方法被调用的位置
方法出口信息
存储的内容
栈帧
为什么有多个栈帧?
多个栈帧
组成
是否涉及垃圾回收？
是否存在线程安全问题
栈内存溢出原因
几个问题
虚拟机栈
所有JVM线程共享的区，存储类相关信息（静态变量，成员变量，类变量，类信息）运行时常量池，方法数据，成员方法及构造器的代码部分等
永久代有一个 JVM 本身设置的固定大小上限，无法进行调整
永久代（JDK < 1.8）
-XX:MetaspaceSize=N //设置 Metaspace 的初始（和最小大小）-XX:MaxMetaspaceSize=N //设置 Metaspace 的最大大小
元空间使用的是直接内存，受本机可用内存的限制
元空间（JDK >= 1.8)
Class常量池
字面量
符号引用
常量池
运行时常量池
JDK 1.6在永久代 JDK 1.8在元空间
串池机制，可避免重复创建对象
字符串拼接原理
三种字符串操作
Java运行时类名，方法名，常量等也是以字符串形式存储在串池中
调整HashTable桶个数
如果程序中含有大量字符串，使用intern()进行字符串入池 ，减少字符串个数，节约堆内存的使用
调优
字符串常量池（串池)
八种包装类型的包装类和对象池
扩展延伸
方法区
new 关键创建的对象
垃圾回收
线程共享，考虑安全问题
堆
JVM内存结构模型图
JVM内存结构
1.类加载检查
指针碰撞
空闲列表
分类
CAS
TLAB
并发问题
2.内存分配
3.初始化
什么是java对象的指针压缩？
为什么要进行指针压缩？
对象头
对齐填充
实例数据
对象在存储中的布局
4.设置对象头
5.执行init方法
对象创建的流程
标量与聚合量
标量替换
对象在栈上的分配
对象在新生代的分配
大对象的分配
长期存活的对象将进入老年代
对象动态年龄判断
老年代空间分配担保机制
对象内存分配
对象的创建与内存分配
一个对象如果没有任何与之关联的引用，即他们的引用计数都为 0
可能产生循环引用问题，A->B->C->A 计数都为1，不能被回收
1.引用计数法
“GC roots”根对象作为起点搜索
通过根到该对象找不到可达路径则为垃圾对象
2.可达性分析
回收机制
强引用
软引用
弱引用
虚引用
补充：终结器引用
四种引用
回收方式
适合老年代
标记清除法(Mark-Sweep)
适合回收新生代： 新生代存活率低
复制算法(Copying）
根据老年代的特点特出的一种标记算法，结合了复制算法与标记清除法。 标记阶段和标记清除算法相同，标记后不是清理对象，而是将存活对象移向内存的一端。然后清除端边界外的对象。
标记整理算法(Mark-Compact)
垃圾回收算法
核心思想
收集步骤
算法选择
伊甸园Eden
S1（From）
S2（To）
幸存区Survivor
新生代
老年代
JVM内存分代模型（用于分代垃圾回收算法）
当Eden区满时，触发Minor GC
Minor GC
Full GC
GC分类
并行： 指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态
并发：并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个 CPU 上。
并行与并发
PS + PO
吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）
吞吐量
STW越短，响应越快
响应时间
调优策略选择
相关概念
基本参数
单线程
必须暂停其他所有的工作线程STW（ “Stop The World” ），直到收集结束
简单而高效（没有多线程交互的开销）
内存较小，适合个人电脑
应用场景
回收过程
Serial / Serial Old收集器 （串行）
Parallel Scavenge PS(吞吐量控制) / Pareallel Old
ParNew收集器(吞吐量优先)
-XX: +UseConcMarkSweepGC
-XX: G1HeapRegionSize: 指定分区大小
-XX: ParallelCMSThreads: CMS线程数量
-XX: MaxGCPauseMillis: 期望停顿时间
-XX: CMSInitiatingOccupancyFraction: 老年代使用比例启动CMS
-XX:+UseCMSCompactAtFullCollection: 在FGC时进行压缩
-XX: CMSFullGCsBeforeCompaction=5: 5次CMS进行压缩
1.初始标记：仅标记GC Roots的直接关联对象，并且暂停其他所有线程（STW）
2.并发标记 Concurrent Mark：并发标记阶段就是从GC Roots 的直接关联对象开始遍历进行font color=\"#e74f4c\
3. 重新标记：修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录 （STW）
4.并发清理 Concurrent Sweep： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理。
5.并发重置：重置本次GC过程中的标记数据。
对CPU资源敏感（会和服务抢资源）
-XX:+UseCMSCompactAtFullCollection
XX:CMSFullGCsBeforeCompaction=0
使用“标记-清除”算法会导致大量空间碎片产生（配置压缩整理参数会进行内存整理）
-XX: CMSInitiatingOccupancyFraction: 默认92% -> 下调触发老年代Full GC的阈值
产生浮动垃圾，老年区太多内存碎片
问题
垃圾回收器中的应用
黑色
灰色
白色
多标-浮动垃圾
漏标-读写屏障
三色标记
CMS收集器 Concurrent Mark Sweep（响应时间优先）
-XX:+UseG1GC
-XX: MaxGCPauseMillis
G1NewSizePercent/G1MaxNewSizePercent:
并行与并发： G1 能充分利用多 CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短 Stop-The-World 停顿的时间
将整个 Java 堆划分为多个大小相等的独立区域（Region）
可预测的停顿
YoungGC
MixedGC
Full GC
垃圾收集分类
G1 收集器（同时注重响应时间与吞吐量）
主要目标
布局
Region设计
ZGC收集器收集器
垃圾回收器
记忆集与卡表
-XX: +UseSerialGC = Serial New + Serial Old
-XX: UseConcMarkSweepGC = ParNew + CMS + Serial Old
-XX: UseParallelGC = Parallel Scavemage + Parallel Old(1.8默认)
-XX: UseG1GC
垃圾回收器组合参数
如何选择垃圾收集器
安全点
安全区域
安全点与安全区域
JVM-04.垃圾回收机制看着一篇就够了
垃圾回收机制
java -Xmn10M -Xms40M -Xmx60M -XX:+PrintCommandLineFlags -XX:+PrintGCDetails TestPool
常用命令
jps
查看内存信息，实例个数以及占用内存大小
查看堆内存占用情况
堆dump
jmap
查找死锁
找出占用cpu高的线程堆栈信息
jstack
查看正在运行的Java应用程序的扩展参数
查看系统属性
jinfo
查看堆内存各部分的使用量，以及加载类的数量
垃圾回收整体统计
堆内存统计
新生代垃圾回收统计
新生代内存统计
老年代垃圾回收统计
老年代内存统计
元空间统计
垃圾回收信息统计（比例）
JVM 最近编译情况
年轻代对象增长的速率
Young GC 的触发频率和每次耗时
每次 Young GC 后有多少对象存活和进入老年代
Full GC的触发频率和每次耗时
优化思路
应用场景：JVM运行情况分析
jstat
调优工具
调整比例，在年轻代被回收，避免放入老年代
每次YGC后存货对象小于Survior的50%
尽量将用过即死的对象留在年轻代
思路
应用程序稳定运行时长期存活对象在堆中占用的空间大小，也就是Full GC后堆中老年代占用空间的大小
总堆：1200MB = 300MB × 4* 新生代：450MB = 300MB × 1.5* 老年代： 750MB = 1200MB - 450MB*
确认活跃数据大小
-Xmn512M：新生代大小-Xms: 堆初始阈值-Xmx: 最大堆大小-XX:MaxMetaspaceSize=256m：元数据区最大值-XX:NewRatio=2: 老年代和新生代的比值。新生代占1/3，老年代2/3-Xss256K虚拟机栈大小(默认1M，一般不需要)-XX:SurvivorRatio=6： 新生代中eden区和survivor区的比值，每个survivor区占新生代的八分之一-XX:PretenureSizeThreshold=1000000: 大于这个值的对象直接在老年代分配，避免在Eden区和Survivor区发生大量的内存复制，该参数只对Serial和ParNew收集器有效
堆内存分配
-XX：MaxGCPauseMills：期望收集时间上限，用来控制收集对应用程序停顿的影响-XX：GCTimeRatio：期望的 GC 时间占总时间的比例，用来控制吞吐量-XX：UseAdaptiveSizePolicy：自动分代大小调节策略
Parallel Scavenge
-XX:CMSInitiatingOccupancyFraction=75 触发执行CMS回收的当前年代区内存占用的百分比需打开-XX:+UseCMSInitiatingOccupancyOnly-XX:+UseCMSCompactAtFullCollection：使用CMS执行Full GC时对内存进行压缩-XX:CMSFullGCsBeforeCompaction=1： 多少次FGC后进行内存压缩-XX:MaxGCPauseMillis 建议停顿时间
CMS参数
调整参数
Full GC 和 Young GC频繁
请求高峰期发生Full GC，单次暂停时间特别长
老年代充裕的情况下，发生Full GC（CMS JDK1.7）
常见问题
内存大->FGC时间越长解决：PS -> PN + CMS / G1
增大内存后反而卡顿严重
CPU 100% -> 有线程占用系统资源找到进程中哪个线程cpu高(top)导出该线程堆栈(jstack)定位方法(栈帧)消耗时间(js)
系统CPU经常100%
导出堆内存(jmap)分析(jhat jvisualvm mat...)
内存标高
新生代中的Eden区增加一倍，Minor GC的次数就会减少一半
由于新生代空间较小，Eden区很快被填满，就会导致频繁Minor GC，因此可以通过增大新生代空间来降低Minor GC的频率
MinorGC频繁
Minor GC时间更多取决于GC后存活对象的数量，而非Eden区的大小
堆中短期对象很多，那么扩容新生代，单次Minor GC时间不会显著增加
单次Minor GC时间=T1（扫描新生代）和 T2（复制存活对象到Survivor区，更耗时间）
Minor GC时间
Minor GC每分钟100次 ，Major GC每4分钟一次，单次Minor GC耗时25ms，单次Major GC耗时200ms，接口响应时间50ms。
如果应用存在大量的短期对象，应该选择较大的年轻代；如果存在相对较多的持久对象，老年代应该适当增大
选择各分区大小
动态年龄计算：Hotspot遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积当累积的某个年龄大小超过了survivor区的一半时，取这个年龄和MaxTenuringThreshold中更小的一个值，作为新的晋升年龄阈值
a）MaxTenuringThreshold设置的过大，原本应该晋升的对象一直停留在Survivor区，直到Survivor区溢出，一旦溢出发生，Eden+Svuvivor中对象将不再依据年龄全部提升到老年代，这样对象老化的机制就失效了
MaxTenuringThreshold设置的过小，“过早晋升”即对象不能在新生代充分被回收，大量短期对象被晋升到老年代，老年代空间迅速增长，引起频繁的Major GC。分代回收失去了意义，严重影响GC性能。
MaxTenuringThreshold设定的阈值
Major GC和Minor GC频繁
remark阶段主要是通过扫描堆来判断对象是否存活。CMS对老年代做回收，Remark阶段仅扫描老年代是否可行？结论是不可行
跨代引用的存在，CMS在Remark阶段必须扫描整个堆
Remark前增加了一个可中断的并发预清理（CMS-concurrent-abortable-preclean），该阶段主要工作仍然是并发标记对象是否存活
参数CMSMaxAbortablePrecleanTime ，默认为5s，如果可中断的预清理执行超过5s，不管发没发生Minor GC，都会中止此阶段，进入Remark
解决：提供CMSScavengeBeforeRemark参数，用来保证Remark前强制进行一次Minor GC
高峰期CMS在重标记（Remark）阶段耗时1.39s。Remark阶段是Stop-The-World
高峰期GC导致性能下降
把-XX:PermSize参数和-XX:MaxPermSize设置成一样，强制虚拟机在启动的时候就把永久代的容量固定下来，避免运行时自动扩容
大量代理类产生，通过参数CMSPermGenSweepingEnabled ，可以让CMS在Perm区容量不足时对其回收
Perm永久代/元空间不足，自动扩容导致STW
JVM设置了参数（-XX:PretenureSizeThreshold=1000000），大对象直接进入老年代。
UseAdaptiveSizePolicy参数导致Survivor动态调整到过小，对象直接到老年代
Minor GC时，Survivor区域太小
老年代内存本身比较小，Minor GC时，有概率触发Full GC
老年代空间不足，需要尽快回收老年代里面的不再被使用的对象，终止CMS，直接进行Serial Old GC
CMS GC时出现promotion failed和concurrent mode failure
问题分析
案例
调优思路分析
参数
GC日志
内存泄漏
内存溢出
内存泄漏与内存溢出
阿里巴巴Arthas
JVM调优工具及调优方法
JVM调优
职业：暂无
0 条评论
回复 删除
下一页
