简单的网站建设模板,单位网站建设费用账务处理,wordpress分类页模板设置,html5网站有哪些文章目录从面试角度来谈谈你了解的JVM调优GC调优的步骤1.确定目标#xff1a;2.优化参数3.验收优化结果GC优化案例一、Major GC和Minor GC频繁优化Minor GC频繁问题#xff1a;1.可以适当增大新生代的内存二、请求高峰期发生GC#xff0c;导致服务可用性降低优化标记停顿时间…
文章目录从面试角度来谈谈你了解的JVM调优GC调优的步骤1.确定目标2.优化参数3.验收优化结果GC优化案例一、Major GC和Minor GC频繁优化Minor GC频繁问题1.可以适当增大新生代的内存二、请求高峰期发生GC导致服务可用性降低优化标记停顿时间长的问题转换成如何减少新生代对象数量三、发生Stop-The-World的GC永久代空间不足导致容量拓展的问题Java中9中常见的CMS GC问题分析与解决2.GC基础2.3 分配对象2.4收集对象2.4.1 收集算法2.5 收集器2.5.1 分代收集器2.5.2 分区收集2.5.3 常用的收集器3.1 判断GC有没有问题3.1.1评价标准3.1.2 读懂对应的GC Cause3.3.2 GC问题分类常用的JVM参数设置从面试角度来谈谈你了解的JVM调优
GC调优的步骤
GC优化一般步骤可以概括为确定目标、优化参数、验收结果
1.确定目标
譬如- 高可用可用性达到多少个- 低延迟 请求必须多少毫秒内完成响应 高吞吐每秒完成多少事务
2.优化参数
以下参考美团技术团队的做法注重高可用和低延迟的话那么就需要有个量化指标比如时间T内发生N次GC受GC影响请求占比接口响应时间GC时间×N/T。可见无论降低单次GC或者降低GC次数都可以有效减少GC响应时间的影响。 具体优化
通过收集GC日志信息结合系统需求确定优化方案例如选用合适的GC回收器、重新设置内存比例、调整JVM参数等
3.验收优化结果
将修改应用到所有服务器判断优化结果是否符合预期总结相关经验。
接下来我们通过三个案例来实践以上的优化流程和基本原则本文中三个案例使用的垃圾回收器均为ParNewCMSCMS失败时Serial Old替补)。
GC优化案例
一、Major GC和Minor GC频繁
面试假如给了我们一个场景Minor GC每分钟100次 Major GC每4分钟一次单次Minor GC耗时25ms单次Major GC耗时200ms接口响应时间50ms
首先我们可以看到Minor GC是很频繁的因此首先从Minor GC开始。
优化Minor GC频繁问题
1.可以适当增大新生代的内存
通常情况下由于新生代空间较小Eden区很快被填满就会导致频繁Minor GC因此可以通过增大新生代空间来降低Minor GC的频率。例如在相同的内存分配率的前提下新生代中的Eden区增加一倍Minor GC的次数就会减少一半同样**Minor GC更多取决于GC后存活对象的数量而非Eden区的大小。**因此如果我们新生代短期对象很多扩容新生代单次Minor GC时间不会显著增加。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wG0FRgRp-1678358886599)(null)] 如果应用存在大量的短期对象应该选择较大的年轻代如果存在相对较多的持久对象老年代应该适当增大。
二、请求高峰期发生GC导致服务可用性降低
GC日志显示高峰期CMS在重标记Remark阶段耗时1.39s。Remark阶段是Stop-The-World以下简称为STW的即在执行垃圾回收时Java应用程序中除了垃圾回收器线程之外其他所有线程都被挂起意味着在此期间用户正常工作的线程全部被暂停下来这是低延时服务不能接受的。本次优化目标是降低Remark时间。 优化标记停顿时间长的问题
解决问题前先回顾一下CMS的四个主要阶段以及各个阶段的工作内容。下图展示了CMS各个阶段可以标记的对象用不同颜色区分。
1.Init-mark初始标记(STW) 该阶段进行可达性分析标记GC ROOT能直接关联到的对象所以很快。2.Concurrent-mark并发标记由前阶段标记过的绿色对象出发所有可到达的对象都在本阶段中标记。3.Remark重标记(STW) 暂停所有用户线程重新扫描堆中的对象进行可达性分析标记活着的对象。**因为并发标记阶段是和用户线程并发执行的过程所以该过程中可能有用户线程修改某些活跃对象的字段指向了一个未标记过的对象**如下图中红色对象在并发标记开始时不可达但是并行期间引用发生变化变为对象可达这个阶段需要重新标记出此类对象防止在下一阶段被清理掉这个过程也是需要STW的。特别需要注意一点这个阶段是以新生代中对象为根来判断对象是否存活的。4.并发清理进行并发的垃圾清理 Remark阶段主要是通过扫描堆来判断对象是否存活。那么准确判断对象是否存活需要扫描哪些对象
注意跨代引用新生代持有对老年代的引用 因它的存在Remark阶段必须扫描整个堆来判断对象是否存活包括图中灰色的不可达对象
新生代GC和老年代的GC是各自分开独立进行的只有Minor GC时才会使用根搜索算法标记新生代对象是否可达也就是说虽然一些对象已经不可达但在Minor GC发生前不会被标记为不可达CMS也无法辨认哪些对象存活只能全堆扫描新生代老年代。由此可见堆中对象的数目影响了Remark阶段耗时。 分析GC日志可以得出同样的规律Remark耗时500ms时新生代使用率都在75%以上。这样降低Remark阶段耗时问题转换成如何减少新生代对象数量
转换成如何减少新生代对象数量
生代中对象的特点是“朝生夕灭”这样**如果Remark前执行一次Minor GC大部分对象就会被回收。CMS就采用了这样的方式在Remark前增加了一个可中断的并发预清理CMS-concurrent-abortable-preclean**该阶段主要工作仍然是并发标记对象是否存活只是这个过程可被中断
除此之外CMS为了避免这个阶段没有等到Minor GC而陷入无限等待提供了参数CMSMaxAbortablePrecleanTime 默认为5s含义是如果可中断的预清理执行超过5s不管发没发生Minor GC都会中止此阶段进入Remark对于这种情况CMS提供CMSScavengeBeforeRemark参数用来保证Remark前强制进行一次Minor GC
优化了后经过增加CMSScavengeBeforeRemark参数单次执行时间200ms的GC停顿消失从监控上观察GCtime和业务波动保持一致不再有明显的毛刺。
小结
通过案例分析了解到由于跨代引用的存在CMS在Remark阶段必须扫描整个堆同时为了避免扫描时新生代有很多对象增加了可中断的预清理阶段用来等待Minor GC的发生。只是该阶段有时间限制如果超时等不到Minor GCRemark时新生代仍然有很多对象我们的调优策略是通过参数强制Remark前进行一次Minor GC从而降低Remark阶段的时间。
思考如果老年代可能持有新生代对象引用所以Minor GC时也必须扫描老年代。
JVM是如何避免Minor GC时扫描全堆的 经过统计信息显示老年代持有新生代对象引用的情况不足1%根据这一特性JVM引入了卡表card table来实现这一目的
卡表具体策略就是将老年代的空间分成大小为512B的若干张card。卡表本身是单字节数组数组中的每个元素对应着一张卡**当发生老年代引用新生代时虚拟机将该卡对应的卡表元素设置为适当的值。**如上图所示卡表3被标记为脏卡表还有另外的作用标识并发标记阶段哪些块被修改过之后Minor GC时通过扫描卡表就可以很快的识别哪些卡中存在老年代指向新生代的引用。这样虚拟机通过空间换时间的方式避免了全堆扫描
三、发生Stop-The-World的GC
确定目标
根据GC日志可知本次Full GC耗时1.23s。这个在线服务同样要求低时延高可用。本次优化目标是降低单次STW回收停顿时间提高可用性 问题分析
首先什么时候可能会触发STW的Full GC呢 Perm空间不足 CMS GC时出现promotion failed和concurrent mode failureconcurrent mode failure发生的原因一般是CMS正在进行但是由于老年代空间不足需要尽快回收老年代里面的不再被使用的对象这时停止所有的线程同时终止CMS直接进行Serial Old GC 统计得到的Young GC晋升到老年代的平均大小大于老年代的剩余空间 主动触发Full GC执行jmap -histo:live [pid]来避免碎片问题
然后我们来逐一分析一下 - 排除原因2如果是原因2中两种情况日志中会有特殊标识目前没有。 - 排除原因3根据GC日志当时老年代使用量仅为20%也不存在大于2G的大对象产生。 - 排除原因4因为当时没有相关命令执行。 - 锁定原因1根据日志发现Full GC后Perm区变大了推断是由于永久代空间不足容量扩展导致的
永久代空间不足导致容量拓展的问题
通过把-XX:PermSize参数和-XX:MaxPermSize设置成一样强制虚拟机在启动的时候就把永久代的容量固定下来避免运行时自动扩容。CMS默认情况下不会回收Perm区通过参数CMSPermGenSweepingEnabled、CMSClassUnloadingEnabled 可以让CMS在Perm区容量不足时对其回收
Java中9中常见的CMS GC问题分析与解决
2.GC基础
TLAB Thread Local Allocation Buffer 的简写基于 CAS 的独享线程Mutator Threads可以优先将对象分配在 Eden 中的一块内存因为是 Java 线程独享的内存区没有锁竞争所以分配速度更快每个 TLAB 都是一个线程独享的。Card Table 中文翻译为卡表主要是用来标记卡页的状态每个卡表项对应一个卡页。当卡页中一个对象引用有写操作时写屏障将会标记对象所在的卡表状态改为 dirty卡表的本质是用来解决跨代引用的问题
2.3 分配对象
Java 中对象地址操作主要使用 Unsafe 调用了 C 的 allocate 和 free 两个方法分配方法有两种
空闲链表free list 通过额外的存储记录空闲的地址将随机 IO 变为顺序 IO但带来了额外的空间消耗。碰撞指针bump pointer 通过一个指针作为分界点需要分配内存时仅需把指针往空闲的一端移动与对象大小相等的距离分配效率较高但使用场景有限。
2.4收集对象
引用计数法Reference Counting 对每个对象的引用进行计数每当有一个地方引用它时计数器 1、引用失效则 -1引用的计数放到对象头中大于 0 的对象被认为是存活对象。虽然循环引用的问题可通过 Recycler 算法解决但是在多线程环境下引用计数变更也要进行昂贵的同步操作性能较低早期的编程语言会采用此算法。可达性分析又称引用链法Tracing GC 从 GC Root 开始进行对象搜索可以被搜索到的对象即为可达对象此时还不足以判断对象是否存活/死亡需要经过多次标记才能更加准确地确定整个连通图之外的对象便可以作为垃圾被回收掉。目前 Java 中主流的虚拟机均采用此算法。
GC Root的对象有哪些 虚拟机栈中引用的对象、方法区中类静态属性的常量、运行时方法区的常量、本地方法栈中JNI引用的对象 2.4.1 收集算法
Mark-Sweep标记-清除 回收过程主要分为两个阶段第一阶段为追踪Tracing阶段即从 GC Root 开始遍历对象图并标记Mark所遇到的每个对象第二阶段为清除Sweep阶段即回收器检查堆中每一个对象并将所有未被标记的对象进行回收整个过程不会发生对象移动。整个算法在不同的实现中会使用三色抽象Tricolour Abstraction、位图标记BitMap等技术来提高算法的效率存活对象较多时较高效。Mark-Compact 标记-整理 这个算法的主要目的就是解决在非移动式回收器中都会存在的碎片化问题也分为两个阶段第一阶段与 Mark-Sweep 类似第二阶段则会对存活对象按照整理顺序Compaction Order进行整理。主要实现有双指针Two-Finger回收算法、滑动回收Lisp2算法和引线整理Threaded Compaction算法等。Copying复制 将空间分为两个大小相同的 From 和 To 两个半区同一时间只会使用其中一个每次进行回收时将一个半区的存活对象通过复制的方式转移到另一个半区。有递归Robert R. Fenichel 和 Jerome C. Yochelson提出和迭代Cheney 提出算法以及解决了前两者递归栈、缓存行等问题的近似优先搜索算法。复制算法可以通过碰撞指针的方式进行快速地分配内存但是也存在着空间利用率不高的缺点另外就是存活对象比较大时复制的成本比较高。
2.5 收集器
2.5.1 分代收集器
ParNew 一款多线程的收集器采用复制算法主要工作在 Young 区可以通过 -XX:ParallelGCThreads 参数来控制收集的线程数整个过程都是 STW 的常与 CMS 组合使用。CMS 以获取最短回收停顿时间为目标采用“标记-清除”算法分 4 大步进行垃圾收集其中初始标记和重新标记会 STW
2.5.2 分区收集
G1 一种服务器端的垃圾收集器应用在多处理器和大容量内存环境中在实现高吞吐量的同时尽可能地满足垃圾收集暂停时间的要求。ZGC JDK11 中推出的一款低延迟垃圾回收器适用于大内存低延迟服务的内存管理和回收SPECjbb 2015 基准测试在 128G 的大堆下最大停顿时间才 1.68 ms停顿时间远胜于 G1 和 CMS。Shenandoah 由 Red Hat 的一个团队负责开发与 G1 类似基于 Region 设计的垃圾收集器但不需要 Remember Set 或者 Card Table 来记录跨 Region 引用停顿时间和堆的大小没有任何关系。停顿时间与 ZGC 接近下图为与 CMS 和 G1 等收集器的 benchmark。
2.5.3 常用的收集器 3.1 判断GC有没有问题
3.1.1评价标准
延迟Latency 也可以理解为最大停顿时间即垃圾收集过程中一次 STW 的最长时间越短越好一定程度上可以接受频次的增大GC 技术的主要发展方向。吞吐量Throughput 应用系统的生命周期内由于 GC 线程会占用 Mutator 当前可用的 CPU 时钟周期吞吐量即为 Mutator 有效花费的时间占系统总运行时间的百分比
目前各大互联网公司的系统基本都更追求低延时避免一次 GC 停顿的时间过长对用户体验造成损失衡量指标需要结合一下应用服务的 SLA主要如下两点来判断 3.1.2 读懂对应的GC Cause 重点需要关注的几个GC Cause
System.gc() 手动触发GC操作。CMS CMS GC 在执行过程中的一些动作重点关注 CMS Initial Mark 和 CMS Final Remark 两个 STW 阶段。Promotion Failure Old 区没有足够的空间分配给 Young 区晋升的对象即使总可用内存足够大。Concurrent Mode Failure CMS GC 运行期间Old 区预留的空间不足以分配给新的对象此时收集器会发生退化严重影响 GC 性能下面的一个案例即为这种场景。GCLocker Initiated GC 如果线程执行在 JNI 临界区时刚好需要进行 GC此时 GC Locker 将会阻止 GC 的发生同时阻止其他线程进入 JNI 临界区直到最后一个线程退出临界区时触发一次 GC。
3.3.2 GC问题分类
Unexpected GC 意外发生的 GC实际上不需要发生我们可以通过一些手段去避免。 Space Shock 空间震荡问题参见“场景一动态扩容引起的空间震荡”。Explicit GC 显示执行 GC 问题参见“场景二显式 GC 的去与留”。 Partial GC 部分收集操作的 GC只对某些分代/分区进行回收。 Young GC 分代收集里面的 Young 区收集动作也可以叫做 Minor GC。 ParNew Young GC 频繁参见“场景四过早晋升”。 Old GC 分代收集里面的 Old 区收集动作也可以叫做 Major GC有些也会叫做 Full GC但其实这种叫法是不规范的在 CMS 发生 Foreground GC 时才是 Full GCCMSScavengeBeforeRemark 参数也只是在 Remark 前触发一次Young GC。 CMS Old GC 频繁参见“场景五CMS Old GC 频繁”。CMS Old GC 不频繁但单次耗时大参见“场景六单次 CMS Old GC 耗时长”。 Full GC 全量收集的 GC对整个堆进行回收STW 时间会比较长一旦发生影响较大也可以叫做 Major GC参见“场景七内存碎片收集器退化”。MetaSpace 元空间回收引发问题参见“场景三MetaSpace 区 OOM”。Direct Memory 直接内存也可以称作为堆外内存回收引发问题参见“场景八堆外内存 OOM”。JNI 本地 Native 方法引发问题参见“场景九JNI 引发的 GC 问题”。
常用的JVM参数设置
参数说明-Xms设置JVM初始内存大小。建议与-Xmx相同避免每次垃圾回收完成后JVM重新分配内存。-Xmx设置JVM最大可用内存大小。为避免容器OOM请为系统预留足够的内存大小。-XX:PrintGCDetails输出GC详细信息。-XX:PrintGCDateStamps输出GC时间戳。日期形式例如2019-12-24T21:53:59.2340800。-Xloggc:/home/admin/nas/gc-${POD_IP}-$(date %s).logGC日志文件路径。需保证Log文件所在容器路径已存在建议您将该容器路径挂载到NAS目录或收集到SLS以便自动创建目录以及实现日志的持久化存储。-XX:HeapDumpOnOutOfMemoryErrorJVM发生OOM时自动生成DUMP文件。-XX:HeapDumpPath/home/admin/nas/dump-${POD_IP}-$(date %s).hprofDUMP文件路径。需保证DUMP文件所在容器路径已存在建议您将该容器路径挂载到NAS目录以便自动创建目录以及实现日志的持久化存储。
-Xms2048m -Xmx2048m -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/home/admin/nas/gc-${POD_IP}-$(date %s).log -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/home/admin/nas/dump-${POD_IP}-$(date %s).hprofm -Xmx2048m -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/home/admin/nas/gc-PODIP−{POD_IP}-PODIP−(date ‘%s’).log -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/home/admin/nas/dump-PODIP−{POD_IP}-PODIP−(date ‘%s’).hprof
