物业网站模板下载,网站 不稳定,英讯网站建设,平面设计找图网站本文介绍 GC 基础原理和理论#xff0c;GC 调优方法思路和方法#xff0c;基于 Hotspot jdk1.8#xff0c;学习之后你将了解如何对生产系统出现的 GC 问题进行排查解决。
本文介绍 GC 基础原理和理论#xff0c;GC 调优方法思路和方法#xff0c;基于 Hotspot jdk1.8GC 调优方法思路和方法基于 Hotspot jdk1.8学习之后你将了解如何对生产系统出现的 GC 问题进行排查解决。
本文介绍 GC 基础原理和理论GC 调优方法思路和方法基于 Hotspot jdk1.8学习之后你将了解如何对生产系统出现的 GC 问题进行排查解决。 图片来自 Pexels
内容主要如下
GC 基础原理涉及调优目标GC 事件分类、JVM 内存分配策略、GC 日志分析等。CMS 原理及调优。G1 原理及调优。GC 问题排查和解决思路。
GC 基础原理
GC 调优目标
大多数情况下对 Java 程序进行 GC 调优主要关注两个目标
响应速度(Responsiveness)响应速度指程序或系统对一个请求的响应有多迅速。
比如用户订单查询响应时间对响应速度要求很高的系统较大的停顿时间是不可接受的。调优的重点是在短的时间内快速响应。
吞吐量(Throughput)吞吐量关注在一个特定时间段内应用系统的最大工作量。
例如每小时批处理系统能完成的任务数量在吞吐量方面优化的系统较长的 GC 停顿时间也是可以接受的因为高吞吐量应用更关心的是如何尽可能快地完成整个任务不考虑快速响应用户请求。
GC 调优中GC 导致的应用暂停时间影响系统响应速度GC 处理线程的 CPU 使用率影响系统吞吐量。
GC 分代收集算法
现代的垃圾收集器基本都是采用分代收集算法其主要思想 将 Java 的堆内存逻辑上分成两块新生代、老年代针对不同存活周期、不同大小的对象采取不同的垃圾回收策略。 新生代(Young Generation)
新生代又叫年轻代大多数对象在新生代中被创建很多对象的生命周期很短。
每次新生代的垃圾回收(又称 Young GC、Minor GC、YGC)后只有少量对象存活所以使用复制算法只需少量的复制操作成本就可以完成回收。
新生代内又分三个区一个 Eden 区两个 Survivor 区(S0、S1又称From Survivor、To Survivor)大部分对象在 Eden 区中生成。
当 Eden 区满时还存活的对象将被复制到两个 Survivor 区(中的一个);当这个 Survivor 区满时此区的存活且不满足晋升到老年代条件的对象将被复制到另外一个 Survivor 区。
对象每经历一次复制年龄加 1达到晋升年龄阈值后转移到老年代。
老年代(Old Generation)
在新生代中经历了 N 次垃圾回收后仍然存活的对象就会被放到老年代该区域中对象存活率高。老年代的垃圾回收通常使用“标记-整理”算法。
GC 事件分类
根据垃圾收集回收的区域不同垃圾收集主要分为
Young GCOld GCFull GCMixed GC
①Young GC
新生代内存的垃圾收集事件称为 Young GC(又称 Minor GC)当 JVM 无法为新对象分配在新生代内存空间时总会触发 Young GC。
比如 Eden 区占满时新对象分配频率越高Young GC 的频率就越高。
Young GC 每次都会引起全线停顿(Stop-The-World)暂停所有的应用线程停顿时间相对老年代 GC 造成的停顿几乎可以忽略不计。
②Old GC 、Full GC、Mixed GC
Old GC只清理老年代空间的 GC 事件只有 CMS 的并发收集是这个模式。
Full GC清理整个堆的 GC 事件包括新生代、老年代、元空间等 。
Mixed GC清理整个新生代以及部分老年代的 GC只有 G1 有这个模式。
GC 日志分析
GC 日志是一个很重要的工具它准确记录了每一次的 GC 的执行时间和执行结果通过分析 GC 日志可以调优堆设置和 GC 设置或者改进应用程序的对象分配模式。
开启的 JVM 启动参数如下 -verbose:gc -XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps
常见的 Young GC、Full GC 日志含义如下 免费的 GC 日志图形分析工具推荐下面 2 个
GCViewer下载 jar 包直接运行 。gceasyWeb 工具上传 GC 日志在线使用。
内存分配策略
Java 提供的自动内存管理可以归结为解决了对象的内存分配和回收的问题。
前面已经介绍了内存回收下面介绍几条最普遍的内存分配策略
①对象优先在 Eden 区分配大多数情况下对象在先新生代 Eden 区中分配。当 Eden 区没有足够空间进行分配时虚拟机将发起一次 Young GC。
②大对象之间进入老年代JVM 提供了一个对象大小阈值参数(-XX:PretenureSizeThreshold默认值为 0代表不管多大都是先在 Eden 中分配内存)。
大于参数设置的阈值值的对象直接在老年代分配这样可以避免对象在 Eden 及两个 Survivor 直接发生大内存复制。
③长期存活的对象将进入老年代对象每经历一次垃圾回收且没被回收掉它的年龄就增加 1大于年龄阈值参数(-XX:MaxTenuringThreshold默认 15)的对象将晋升到老年代中。
④空间分配担保当进行 Young GC 之前JVM 需要预估老年代是否能够容纳 Young GC 后新生代晋升到老年代的存活对象以确定是否需要提前触发 GC 回收老年代空间基于空间分配担保策略来计算。
continueSize老年代最大可用连续空间 Young GC 之后如果成功(Young GC 后晋升对象能放入老年代)则代表担保成功不用再进行 Full GC提高性能。
如果失败则会出现“promotion failed”错误代表担保失败需要进行 Full GC。
⑤动态年龄判定新生代对象的年龄可能没达到阈值(MaxTenuringThreshold 参数指定)就晋升老年代。
如果 Young GC 之后新生代存活对象达到相同年龄所有对象大小的总和大于任意 Survivor 空间(S0S1空间)的一半此时 S0 或者 S1 区即将容纳不了存活的新生代对象。
年龄大于或等于该年龄的对象就可以直接进入老年代无须等到 MaxTenuringThreshold 中要求的年龄。
另外如果 Young GC 后 S0 或 S1 区不足以容纳未达到晋升老年代条件的新生代存活对象会导致这些存活对象直接进入老年代需要尽量避免。
CMS 原理及调优
名词解释
可达性分析算法用于判断对象是否存活基本思想是通过一系列称为“GC Root”的对象作为起点(常见的 GC Root 有系统类加载器、栈中的对象、处于激活状态的线程等)基于对象引用关系从 GC Roots 开始向下搜索所走过的路径称为引用链当一个对象到 GC Root 没有任何引用链相连证明对象不再存活。
Stop The WorldGC 过程中分析对象引用关系为了保证分析结果的准确性需要通过停顿所有 Java 执行线程保证引用关系不再动态变化该停顿事件称为 Stop The World(STW)。
Safepoint代码执行过程中的一些特殊位置当线程执行到这些位置的时候说明虚拟机当前的状态是安全的如果有需要 GC线程可以在这个位置暂停。
HotSpot 采用主动中断的方式让执行线程在运行期轮询是否需要暂停的标志若需要则中断挂起。
CMS 简介
CMS(Concurrent Mark and Sweep 并发-标记-清除)是一款基于并发、使用标记清除算法的垃圾回收算法只针对老年代进行垃圾回收。
CMS 收集器工作时尽可能让 GC 线程和用户线程并发执行以达到降低 STW 时间的目的。
通过以下命令行参数启用 CMS 垃圾收集器 -XX:UseConcMarkSweepGC
值得补充的是下面介绍到的 CMS GC 是指老年代的 GC而 Full GC 指的是整个堆的 GC 事件包括新生代、老年代、元空间等两者有所区分。
新生代垃圾回收
能与 CMS 搭配使用的新生代垃圾收集器有 Serial 收集器和 ParNew 收集器。
这 2 个收集器都采用标记复制算法都会触发 STW 事件停止所有的应用线程。不同之处在于Serial 是单线程执行ParNew 是多线程执行。 老年代垃圾回收 CMS GC 以获取最小停顿时间为目的尽可能减少 STW 时间可以分为 7 个阶段
阶段 1初始标记(Initial Mark) 此阶段的目标是标记老年代中所有存活的对象, 包括 GC Root 的直接引用, 以及由新生代中存活对象所引用的对象触发第一次 STW 事件。
这个过程是支持多线程的(JDK7 之前单线程JDK8 之后并行可通过参数 CMSParallelInitialMarkEnabled 调整)。
阶段 2并发标记(Concurrent Mark) 此阶段 GC 线程和应用线程并发执行遍历阶段 1 初始标记出来的存活对象然后继续递归标记这些对象可达的对象。
阶段 3并发预清理(Concurrent Preclean) 此阶段 GC 线程和应用线程也是并发执行因为阶段 2 是与应用线程并发执行可能有些引用关系已经发生改变。
通过卡片标记(Card Marking)提前把老年代空间逻辑划分为相等大小的区域(Card)。
如果引用关系发生改变JVM 会将发生改变的区域标记为“脏区”(Dirty Card)然后在本阶段这些脏区会被找出来刷新引用关系清除“脏区”标记。
阶段 4并发可取消的预清理(Concurrent Abortable Preclean)
此阶段也不停止应用线程。本阶段尝试在 STW 的最终标记阶段(Final Remark)之前尽可能地多做一些工作以减少应用暂停时间。
在该阶段不断循环处理标记老年代的可达对象、扫描处理 Dirty Card 区域中的对象循环的终止条件有
达到循环次数达到循环执行时间阈值新生代内存使用率达到阈值
阶段 5最终标记(Final Remark)
这是 GC 事件中第二次(也是最后一次)STW 阶段目标是完成老年代中所有存活对象的标记。
在此阶段执行
遍历新生代对象重新标记根据 GC Roots重新标记遍历老年代的 Dirty Card重新标记
阶段 6并发清除(Concurrent Sweep) 此阶段与应用程序并发执行不需要 STW 停顿根据标记结果清除垃圾对象。
阶段 7并发重置(Concurrent Reset)
此阶段与应用程序并发执行重置 CMS 算法相关的内部数据, 为下一次 GC 循环做准备。
CMS 常见问题
①最终标记阶段停顿时间过长问题
CMS 的 GC 停顿时间约 80% 都在最终标记阶段(Final Remark)若该阶段停顿时间过长常见原因是新生代对老年代的无效引用在上一阶段的并发可取消预清理阶段中执行阈值时间内未完成循环来不及触发 Young GC清理这些无效引用。
通过添加参数-XX:CMSScavengeBeforeRemark。
在执行最终操作之前先触发 Young GC从而减少新生代对老年代的无效引用降低最终标记阶段的停顿。
但如果在上个阶段(并发可取消的预清理)已触发 Young GC也会重复触发 Young GC。
②并发模式失败(concurrent mode failure)晋升失败(promotion failed)问题。 并发模式失败当 CMS 在执行回收时新生代发生垃圾回收同时老年代又没有足够的空间容纳晋升的对象时CMS 垃圾回收就会退化成单线程的 Full GC。所有的应用线程都会被暂停老年代中所有的无效对象都被回收。 晋升失败当新生代发生垃圾回收老年代有足够的空间可以容纳晋升的对象但是由于空闲空间的碎片化导致晋升失败此时会触发单线程且带压缩动作的 Full GC。
并发模式失败和晋升失败都会导致长时间的停顿常见解决思路如下
降低触发 CMS GC 的阈值。即参数 -XX:CMSInitiatingOccupancyFraction 的值让 CMS GC 尽早执行以保证有足够的空间。增加 CMS 线程数即参数 -XX:ConcGCThreads。增大老年代空间。让对象尽量在新生代回收避免进入老年代。
③内存碎片问题
通常 CMS 的 GC 过程基于标记清除算法不带压缩动作导致越来越多的内存碎片需要压缩。
常见以下场景会触发内存碎片压缩
新生代 Young GC 出现新生代晋升担保失败(promotion failed))程序主动执行System.gc()
可通过参数 CMSFullGCsBeforeCompaction 的值设置多少次 Full GC 触发一次压缩。
默认值为 0代表每次进入 Full GC 都会触发压缩带压缩动作的算法为上面提到的单线程 Serial Old 算法暂停时间(STW)时间非常长需要尽可能减少压缩时间。
G1 原理及调优
G1 简介
G1(Garbage-First)是一款面向服务器的垃圾收集器支持新生代和老年代空间的垃圾收集主要针对配备多核处理器及大容量内存的机器。
G1 最主要的设计目标是实现可预期及可配置的 STW 停顿时间。
G1 堆空间划分 ①Region
为实现大内存空间的低停顿时间的回收将划分为多个大小相等的 Region。每个小堆区都可能是 Eden 区Survivor 区或者 Old 区但是在同一时刻只能属于某个代。
在逻辑上, 所有的 Eden 区和 Survivor 区合起来就是新生代所有的 Old 区合起来就是老年代且新生代和老年代各自的内存 Region 区域由 G1 自动控制不断变动。
②巨型对象
当对象大小超过 Region 的一半则认为是巨型对象(Humongous Object)直接被分配到老年代的巨型对象区(Humongous Regions)。
这些巨型区域是一个连续的区域集每一个 Region 中最多有一个巨型对象巨型对象可以占多个 Region。
G1 把堆内存划分成一个个 Region 的意义在于
每次 GC 不必都去处理整个堆空间而是每次只处理一部分 Region实现大容量内存的 GC。通过计算每个 Region 的回收价值包括回收所需时间、可回收空间在有限时间内尽可能回收更多的垃圾对象把垃圾回收造成的停顿时间控制在预期配置的时间范围内这也是 G1 名称的由来Garbage-First。
G1工作模式
针对新生代和老年代G1 提供 2 种 GC 模式Young GC 和 Mixed GC两种会导致 Stop The World。
Young GC当新生代的空间不足时G1 触发 Young GC 回收新生代空间。
Young GC 主要是对 Eden 区进行 GC它在 Eden 空间耗尽时触发基于分代回收思想和复制算法每次 Young GC 都会选定所有新生代的 Region。
同时计算下次 Young GC 所需的 Eden 区和 Survivor 区的空间动态调整新生代所占 Region 个数来控制 Young GC 开销。
Mixed GC当老年代空间达到阈值会触发 Mixed GC选定所有新生代里的 Region根据全局并发标记阶段(下面介绍到)统计得出收集收益高的若干老年代 Region。
在用户指定的开销目标范围内尽可能选择收益高的老年代 Region 进行 GC通过选择哪些老年代 Region 和选择多少 Region 来控制 Mixed GC 开销。
全局并发标记 全局并发标记主要是为 Mixed GC 计算找出回收收益较高的 Region 区域具体分为 5 个阶段
阶段 1初始标记(Initial Mark)
暂停所有应用线程(STW)并发地进行标记从 GC Root 开始直接可达的对象(原生栈对象、全局对象、JNI 对象)。
当达到触发条件时G1 并不会立即发起并发标记周期而是等待下一次新生代收集利用新生代收集的 STW 时间段完成初始标记这种方式称为借道(Piggybacking)。
阶段 2根区域扫描(Root Region Scan)
在初始标记暂停结束后新生代收集也完成的对象复制到 Survivor 的工作应用线程开始活跃起来。
此时为了保证标记算法的正确性所有新复制到 Survivor 分区的对象需要找出哪些对象存在对老年代对象的引用把这些对象标记成根(Root)。
这个过程称为根分区扫描(Root Region Scanning)同时扫描的 Suvivor 分区也被称为根分区(Root Region)。
根分区扫描必须在下一次新生代垃圾收集启动前完成(接下来并发标记的过程中可能会被若干次新生代垃圾收集打断)因为每次 GC 会产生新的存活对象集合。
阶段 3并发标记(Concurrent Marking)
标记线程与应用程序线程并行执行标记各个堆中 Region 的存活对象信息这个步骤可能被新的 Young GC 打断。
所有的标记任务必须在堆满前就完成扫描如果并发标记耗时很长那么有可能在并发标记过程中又经历了几次新生代收集。
阶段 4再次标记(Remark)
和 CMS 类似暂停所有应用线程(STW)以完成标记过程短暂地停止应用线程, 标记在并发标记阶段发生变化的对象和所有未被标记的存活对象同时完成存活数据计算。
阶段 5清理(Cleanup)
为即将到来的转移阶段做准备, 此阶段也为下一次标记执行所有必需的整理计算工作
整理更新每个 Region 各自的 RSet(Remember SetHashMap 结构记录有哪些老年代对象指向本 Regionkey 为指向本 Region 的对象的引用value 为指向本 Region 的具体 Card 区域通过 RSet 可以确定 Region 中对象存活信息避免全堆扫描)。回收不包含存活对象的 Region。统计计算回收收益高(基于释放空间和暂停目标)的老年代分区集合。
G1调优注意点
①Full GC 问题
G1 的正常处理流程中没有 Full GC只有在垃圾回收处理不过来(或者主动触发)时才会出现G1 的 Full GC 就是单线程执行的 Serial old gc会导致非常长的 STW是调优的重点需要尽量避免 Full GC。
常见原因如下
程序主动执行 System.gc()全局并发标记期间老年代空间被填满(并发模式失败)Mixed GC 期间老年代空间被填满(晋升失败)Young GC 时 Survivor 空间和老年代没有足够空间容纳存活对象
类似 CMS常见的解决是
增大 -XX:ConcGCThreadsn 选项增加并发标记线程的数量或者 STW 期间并行线程的数量-XX:ParallelGCThreadsn。减小 -XX:InitiatingHeapOccupancyPercent 提前启动标记周期。增大预留内存 -XX:G1ReservePercentn默认值是 10代表使用 10% 的堆内存为预留内存当 Survivor 区域没有足够空间容纳新晋升对象时会尝试使用预留内存。
②巨型对象分配
巨型对象区中的每个 Region 中包含一个巨型对象剩余空间不再利用导致空间碎片化当 G1 没有合适空间分配巨型对象时G1 会启动串行 Full GC 来释放空间。
可以通过增加 -XX:G1HeapRegionSize 来增大 Region 大小这样一来相当一部分的巨型对象就不再是巨型对象了而是采用普通的分配方式。
③不要设置 Young 区的大小
原因是为了尽量满足目标停顿时间逻辑上的 Young 区会进行动态调整。如果设置了大小则会覆盖掉并且会禁用掉对停顿时间的控制。
④平均响应时间设置
使用应用的平均响应时间作为参考来设置 MaxGCPauseMillisJVM 会尽量去满足该条件可能是 90% 的请求或者更多的响应时间在这之内 但是并不代表是所有的请求都能满足平均响应时间设置过小会导致频繁 GC。
调优方法与思路
如何分析系统 JVM GC 运行状况及合理优化?
GC 优化的核心思路在于尽可能让对象在新生代中分配和回收尽量避免过多对象进入老年代导致对老年代频繁进行垃圾回收同时给系统足够的内存减少新生代垃圾回收次数进行系统分析和优化也是围绕着这个思路展开。
分析系统的运行状况
分析系统的运行状况
系统每秒请求数、每个请求创建多少对象占用多少内存。Young GC 触发频率、对象进入老年代的速率。老年代占用内存、Full GC 触发频率、Full GC 触发的原因、长时间 Full GC 的原因。
常用工具如下
jstatJVM 自带命令行工具可用于统计内存分配速率、GC 次数GC 耗时。
常用命令格式 jstat -gc pid 统计间隔时间 统计次数
输出返回值代表含义如下 例如jstat -gc 32683 1000 10统计 pid32683 的进程每秒统计 1 次统计 10 次。
jmapJVM 自带命令行工具可用于了解系统运行时的对象分布。
常用命令格式如下 // 命令行输出类名、类数量数量类占用内存大小 // 按照类占用内存大小降序排列 jmap -histo pid // 生成堆内存转储快照在当前目录下导出dump.hrpof的二进制文件 // 可以用eclipse的MAT图形化工具分析 jmap -dump:live,formatb,filedump.hprof pid
jinfo命令格式 jinfo pid
用来查看正在运行的 Java 应用程序的扩展参数包括 Java System 属性和 JVM 命令行参数。
其他 GC 工具
监控告警系统Zabbix、Prometheus、Open-Falconjdk 自动实时内存监控工具VisualVM堆外内存监控Java VisualVM 安装 Buffer Pools 插件、google perf工具、Java NMT(Native Memory Tracking)工具GC 日志分析GCViewer、gceasyGC 参数检查和优化http://xxfox.perfma.com/
GC 优化案例
①数据分析平台系统频繁 Full GC
平台主要对用户在 App 中行为进行定时分析统计并支持报表导出使用 CMS GC 算法。
数据分析师在使用中发现系统页面打开经常卡顿通过 jstat 命令发现系统每次 Young GC 后大约有 10% 的存活对象进入老年代。
原来是因为 Survivor 区空间设置过小每次 Young GC 后存活对象在 Survivor 区域放不下提前进入老年代。
通过调大 Survivor 区使得 Survivor 区可以容纳 Young GC 后存活对象对象在 Survivor 区经历多次 Young GC 达到年龄阈值才进入老年代。
调整之后每次 Young GC 后进入老年代的存活对象稳定运行时仅几百 KbFull GC 频率大大降低。
②业务对接网关 OOM
网关主要消费 Kafka 数据进行数据处理计算然后转发到另外的 Kafka 队列系统运行几个小时候出现 OOM重启系统几个小时之后又 OOM。
通过 jmap 导出堆内存在 eclipse MAT 工具分析才找出原因代码中将某个业务 Kafka 的 topic 数据进行日志异步打印该业务数据量较大大量对象堆积在内存中等待被打印导致 OOM。
③账号权限管理系统频繁长时间 Full GC
系统对外提供各种账号鉴权服务使用时发现系统经常服务不可用通过 Zabbix 的监控平台监控发现系统频繁发生长时间 Full GC且触发时老年代的堆内存通常并没有占满发现原来是业务代码中调用了 System.gc()。
总结
GC 问题可以说没有捷径排查线上的性能问题本身就并不简单除了将本文介绍到的原理和工具融会贯通还需要我们不断去积累经验真正做到性能最优。 阅读目录置顶)(长期更新计算机领域知识https://blog.csdn.net/weixin_43392489/article/details/102380691
阅读目录置顶)(长期更新计算机领域知识https://blog.csdn.net/weixin_43392489/article/details/102380882
