JVM内核-原理、诊断与优化学习笔记（五）：GC参数

最新推荐文章于 2022-03-06 23:01:59 发布
最新推荐文章于 2022-03-06 23:01:59 发布
阅读量179 收藏
点赞数
文章标签： java
原文链接：http://www.cnblogs.com/LeesinDong/p/10835379.html
版权

文章目录

堆的回顾

在这里插入图片描述

串行收集器

  • 最古老，最稳定
  • 效率高
  • 可能会产生较长的停顿（因为只有一个线程）
    -XX:+UseSerialGC
    新生代、老年代使用串行回收
    新生代复制算法
    老年代标记-压缩
    在这里插入图片描述
    GC关键字：新生代gc日志
0.844: [GC 0.844: [DefNew: 17472K->2176K(19648K), 0.0188339 secs] 17472K->2375K(63360K),
 0.0189186 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]

Full GC关键字：老年代gc日志

8.259: [Full GC 8.259: [Tenured: 43711K->40302K(43712K), 0.2960477 secs] 63350K->40302K(63360K), 
[Perm : 17836K->17836K(32768K)], 0.2961554 secs] [Times: user=0.28 sys=0.02, real=0.30 secs]

并行收集器

ParNew（par-并行的缩写，new-新生代，所以只是新生代并行）

  • -XX:+UseParNewGC
    新生代并行
    老年代串行
  • Serial收集器新生代的并行版本
  • 复制算法
  • 多线程，需要多核支持
  • -XX:ParallelGCThreads 限制线程数量

和串行收集器的区别是，通过多核支持多线程。
在这里插入图片描述
多线程不一定快哦！
如果是多核用ParNew速度快一点，如果是单线程的话，还是建议串行收集器。

0.834: [GC 0.834: [ParNew: 13184K->1600K(14784K), 0.0092203 secs] 13184K->1921K(63936K), 
0.0093401 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

注意：有ParNew关键字表示ParNew收集器

Parallel收集器

  • 类似ParNew
  • 新生代复制算法
  • 老年代 标记-压缩
  • 更加关注吞吐量（和ParNew时候的区别）
  • -XX:+UseParallelGC
    使用Parallel收集器+ 老年代串行+新生代并行
  • -XX:+UseParallelOldGC
    使用Parallel收集器+ 并行老年代+新生代并行
    在这里插入图片描述
1.500: [Full GC [PSYoungGen: 2682K->0K(19136K)] [ParOldGen: 28035K->30437K(43712K)] 30717K->30437K(62848K) 
[PSPermGen: 10943K->10928K(32768K)], 
0.2902791 secs] [Times: user=1.44 sys=0.03, real=0.30 secs]

注意：PSYoungGen 、ParOldGen关键字

参数设置

-XX:MaxGCPauseMills

最大停顿时间，单位毫秒
GC尽力保证回收时间不超过设定值

-XX:GCTimeRatio

0-100的取值范围
垃圾收集时间占总时间的比
默认99，即最大允许1%时间做GC

这两个参数是矛盾的。因为停顿时间和吞吐量不可能同时调优。

对于这句话的理解：
在gc的时候，垃圾回收的工作总量是一定的，所以就是花一定的时间做一定的事情，如果gc的频率提高，每次gc花的时间就会变少，可是系统的性能会受到损伤，就会导致停顿的时间比较短，可是总体的性能并不是很好。但是，为了追求高性能，gc少做几次，也就是XX:GCTimeRatio比值会比较大，gc时间较少，所以每次的gc停顿的时间就会比较长。
吞吐量：一般认为系统的性能是和吞吐量息息相关的，单位时间内cpu是分配到了应用程序还是gc，如果cpu是分配到应用程序越多，吞吐量越高。
吞吐量高->gc占用cpu时间短->gc停顿的时间长。
这里既希望gc的停顿时间短一点，又希望吞吐量大一点，所以是矛盾的，所以不能同时调优，所以有侧重的调优。

CMS收集器

CMS收集器

Concurrent Mark Sweep 并发标记清除（ 与用户线程一起执行 ）
试图和应用程序线程一起执行。
标记-清除算法
与标记-压缩相比（因为是并行的，所以不能使标记-压缩的方式）
并发阶段会降低吞吐量（停顿减少了，吞吐量就会降低）
老年代收集器（新生代使用ParNew，这里CMS是一个单纯的老年代的收集器）
-XX:+UseConcMarkSweepGC

CMS运行过程比较复杂，着重实现了标记的过程，可分为

  • 初始标记
    根可以直接关联到的对象
    速度快
    会产生全局停顿
  • 并发标记（和用户线程一起）
    主要标记过程，标记全部对象
  • 重新标记
    由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正
    会产生全局停顿
  • 并发清除（和用户线程一起）
    基于标记结果，直接清理对象

可以看到初始标记、重新标记都会产生全局的停顿，所以CMS还是没有办法去掉所有的全局停顿，但是已经大大的减小了全局停顿。
在这里插入图片描述

1.662: [GC [1 CMS-initial-mark: 28122K(49152K)] 29959K(63936K), 0.0046877 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
1.666: [CMS-concurrent-mark-start]
1.699: [CMS-concurrent-mark: 0.033/0.033 secs] [Times: user=0.25 sys=0.00, real=0.03 secs] 
1.699: [CMS-concurrent-preclean-start]
1.700: [CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
1.700: [GC[YG occupancy: 1837 K (14784 K)]1.700: [Rescan (parallel) , 0.0009330 secs]1.701: [weak refs processing, 0.0000180 secs] [1 CMS-remark: 28122K(49152K)] 29959K(63936K), 0.0010248 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
1.702: [CMS-concurrent-sweep-start]
1.739: [CMS-concurrent-sweep: 0.035/0.037 secs] [Times: user=0.11 sys=0.02, real=0.05 secs] 
1.739: [CMS-concurrent-reset-start]
1.741: [CMS-concurrent-reset: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

关键字：

CMS-initial-mark
CMS-concurrent-mark
CMS-remark
CMS-concurrent-sweep
CMS-concurrent-reset

特点

  • 尽可能降低停顿
  • 会影响系统整体吞吐量和性能
    比如，在用户线程运行过程中，分一半CPU去做GC，系统性能在GC阶段，反应速度就下降一半
  • 清理不彻底
    因为在清理阶段，用户线程还在运行，会产生新的垃圾，无法清理
  • 因为和用户线程一起运行，不能在空间快满时再清理
    如果是串行清理、并行清理，gc的时候会停顿，gc完成之后有足够的空间来申请，但是CMS是和应用程序同时进行的，当空间快满时没有足够的空间供申请。
    -XX:CMSInitiatingOccupancyFraction设置触发GC的阈值
    如果不幸内存预留空间不够，就会引起concurrent mode failure
33.348: [Full GC 33.348: [CMS33.357: [CMS-concurrent-sweep: 0.035/0.036 secs] [Times: user=0.11 sys=0.03, real=0.03 secs] 
 (concurrent mode failure): 47066K->39901K(49152K),
  0.3896802 secs] 60771K->39901K(63936K), [CMS Perm : 22529K->22529K(32768K)],
  0.3897989 secs] [Times: user=0.39 sys=0.00, real=0.39 secs]

上面出现concurrent mode failure错误，表示在CMS的时候，内存申请失败。
使用串行收集器作为后备，及时将CMS收集转化为串行收集，但是因为出现这个错误说明内存已经到了消耗殆尽的状态，所以切换为串行收集的时候可能会出现长时间的停顿。

有关碎片

标记-清除和标记-压缩
在这里插入图片描述
上图可以看到，标记清除之后会出现碎片，如果要申请五个连续单位的空间，是申请不到的，而标记压缩清理之后是能够申请到，所以串行收集和并行收集都是标记压缩的，而标记清理算法之后一般对剩余的空间一般还要进行一次压缩。
可是为什么CMS是使用的标记清除？因为希望和用户线程同时进行，标记压缩在清理的时候需要移动可用的对象的空间，应用层的线程可能找不到对象在哪里，为了能够和应用程序并发执行， 就需要可用的对象位置是没有改变的。

所以出现如下的配置：

-XX:+ UseCMSCompactAtFullCollection

Full GC后，进行一次整理
整理过程是独占的，会引起停顿时间变长

-XX:+CMSFullGCsBeforeCompaction

设置进行几次Full GC后，进行一次碎片整理，当碎片很多的时候，还是会停顿很长的时间，所以不能从根本上解决问题。

-XX:ParallelCMSThreads

设定CMS的线程数量，一般约等于CPU的数量。

GC参数整理

-XX:+UseSerialGC：在新生代和老年代使用串行收集器
-XX:SurvivorRatio：设置eden区大小和survivior区大小的比例
-XX:NewRatio:新生代和老年代的比
-XX:+UseParNewGC：在新生代使用并行收集器
-XX:+UseParallelGC ：新生代使用并行回收收集器
-XX:+UseParallelOldGC：老年代使用并行回收收集器
-XX:ParallelGCThreads：设置用于垃圾回收的线程数
-XX:+UseConcMarkSweepGC：新生代使用并行收集器，老年代使用CMS+串行收集器
-XX:ParallelCMSThreads：设定CMS的线程数量
-XX:CMSInitiatingOccupancyFraction：设置CMS收集器在老年代空间被使用多少后触发
-XX:+UseCMSCompactAtFullCollection：设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理
-XX:CMSFullGCsBeforeCompaction：设定进行多少次CMS垃圾回收后，进行一次内存压缩
-XX:+CMSClassUnloadingEnabled：允许对类元数据进行回收
-XX:CMSInitiatingPermOccupancyFraction：当永久区占用率达到这一百分比时，启动CMS回收
-XX:UseCMSInitiatingOccupancyOnly：表示只在到达阀值的时候，才进行CMS回收

Tomcat实例演示

环境

Tomcat 7
JSP 网站
测试网站吞吐量和延时

工具

JMeter

目的

让Tomcat有一个不错的吞吐量

系统结构

在这里插入图片描述
通过局域网连接，将JMeter和Tomcat放在两个电脑上，防止Jmeter对Tomcat的运行产生影响

Jmeter

性能测试工具
建立10个线程，每个线程请求Tomcat 1000次 共10000次请求
在这里插入图片描述
设置ip、端口、请求地址。

JDK6：使用32M堆处理请求

参数：

set CATALINA_OPTS=-server -Xloggc:gc.log -XX:+PrintGCDetails -Xmx32M -Xms32M 
-XX:+HeapDumpOnOutOfMemoryError -XX:+UseSerialGC -XX:PermSize=32M

Average：在一万次请求中平均的返回速度是6毫秒，
Median：一半的请求都能在4毫秒内返回
90%line：90%请求在7毫秒返回，
min：最小延时2毫秒
max：最大演示135毫秒
Throughput：540每秒（）吞吐量
在这里插入图片描述
上述截图显示的是，系统运行到后期大量的请求，占据了一些内存，从而会导致系统产生大量的full gc，在32-33秒之间就产生了四次full gc。

JDK6：使用最大堆512M堆处理请求，未设置Xms

为了有更好的性能，最简单的方法就是直接增大堆的数量。
参数：
set CATALINA_OPTS=-Xmx512m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails

结果：FULL GC很少，基本上是Minor GC
在这里插入图片描述
吞吐量变成了651，因为没有设置最小初始化堆的大小，所以最小初始化堆就变成了可以扩展的空间，在系统运行时，系统只有16m的内存，但是系统运行到后面，内存在不停的往上涨，到达了60m，整个过程中没有full gc的产生，因为没有full gc的产生，所以吞吐量有一个很好的效果。

JDK6：使用最大堆512M堆处理请求，设置Xms为64m

上面看到最后会扩展到60m，这里直接将Xms设置为64m。
参数：
set CATALINA_OPTS=-Xmx512m -Xms64m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails

结果 GC数量减少 大部分是Minor GC
在这里插入图片描述
因为堆越大gc越少，如果堆很小的话，系统希望将工作维持在一个很小的堆上做，必然会不断的进行gc。

JDK6：使用最大堆512M堆处理请求，改为并行收集器

参数：
set CATALINA_OPTS=-Xmx512m -Xms64m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:ParallelGCThreads=4

将新生代和年老代换成并行回收的方式，因为堆很大，所以GC压力原本就不大。
结果：GC压力原本不大，修改GC方式影响很小
在这里插入图片描述

JDK 6，减小堆，串行收集器

set CATALINA_OPTS=-Xmx40m -Xms40m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails

减小堆大小，增加GC压力，使用Serial回收器，Serial回收器是默认的回收器。
在这里插入图片描述

JDK 6，减小堆，并行收集器

set CATALINA_OPTS=-Xmx40m -Xms40m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails -XX:+UseParallelOldGC -XX:ParallelGCThreads=4

减小堆大小，增加GC压力，使用并行回收器
在这里插入图片描述

JDK 6，减小堆，ParNew收集器

set CATALINA_OPTS=-Xmx40m -Xms40m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails -XX:+UseParNewGC

减小堆大小，增加GC压力，使用ParNew回收器
在这里插入图片描述ParNew只是影响新生代，对老年代影响不大，而这里的压力主要是老年代，所以影响不大。

启动Tomcat 7

使用JDK6
不加任何参数启动测试
在这里插入图片描述

启动Tomcat 7

使用JDK7
不加任何参数启动测试
在这里插入图片描述
可以看到JDK7性能更加好一点。
升级JDK可能会带来额外的性能提升！
不要忽视JDK的版本哦

总结

细节决定成败

  • 性能的根本在应用
  • GC参数属于微调
  • 设置不合理，会影响性能，产生大的延时

转载于:https://www.cnblogs.com/LeesinDong/p/10835379.html

as403045314
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
JVM启动命令垃圾回收器指定GC，回收算法和常见调优参数解析
UnicornRe_xiabin_无聊的时候，喜欢去超市买一大瓶纯牛奶，喝个精光
10-11 821
G1 中每个 Region 都有一个与之对应的 Remembered Set，当进行内存回收时，在 GC 根节点的枚举范围中加入 Remembered Set 即可保证不对全堆扫描也不会有遗漏 检查Reference引用的对象是否处于不同的Region。在用户不可见的情况下把用户正常工作的线程全部停掉。这 3 个参数限制了 Java 堆大小为 20 MB，不可扩展，其中 10 MB 分配给新生代，剩下的 10 MB 分配给老年代。分代模型的新生代是复制算法，下面的垃圾回收器工作在新生代的也是复制算法。
jvm生产环境gc及oom有关的参数
sumengnan的博客
08-13 1606
推荐生产环境使用-server参数 特点是启动速度比较慢，但运行时性能和内存管理效率很高。 一、-XX:-UseGCOverheadLimit 关闭GCOverheadLimit特性，GCoverheadlimitexceeded原因：通过统计GC时间来预测是否要OOM了，当超过98%的时间用来做GC并且回收了不到2%的堆内存，就会抛出这个错误（提前预知，没啥用，该OOM还是会OOM，关闭） 二、-XX:+HeapDumpOnOutOfMemoryError ...
JVM + GC
zzh_spring的博客
08-19 117
1. 强引用、软引用、弱引用、虚引用分别是什么？ 强引用 当内存不足，JVM开始垃圾回收，对于强引用的对象，就算是出现了OOM也不会对该对象进行回收，死都不收。 强引用是最常见的普通对象引用，只要还有前饮用指向一个对象，就能表明对象还“活着”，垃圾收集器不会碰到这种对象。在Java中最常见的就是强引用，把一个对象赋给一个引用变量，这个引用变量就是一个强引用。当一个对象被强引用变量引用时，...
java CMS垃圾回收日志解释
关注系统性能调优
10-23 994
2017-10-17T10:25:52.086+0800: 312546.600:   [GC 312546.601:     [ParNew: 2527009K->12016K(2831168K), 0.1067080 secs]      5043247K->2530708K(5976896K), 0.1070890 secs]   [Times: user=5.21 sys=0.03
在linux上gc日志详解,JVM CMS GC日志详解
weixin_36354744的博客
05-06 384
# JDK8-Xms20M -Xmx20M -XX:+PrintGCDetails -XX:+UseConcMarkSweepGCCMS 日志格式:[GC (Allocation Failure) [ParNew: 5504K->640K(6144K), 0.0136830 secs] 5504K->1556K(19840K), 0.0137738 secs] [Times: user...
深入jvm内核-原理、诊断与优化教学视频
03-19
1、java虚拟机的基本介绍。 2、字节码的执行 3、常用的jvm参数配置 4、算法和种类 5、gc参数配置 6、类加载器 7、性能监控工具 8、jvm堆栈分析
深入JVM内核—原理、诊断与优化视频教程-5. GC参数
03-12
在Java开发中，JVM（Java Virtual Machine）是运行所有Java程序的核心，它负责解析字节码并执行...通过实践和学习，你可以掌握如何根据应用特性选择合适的GC策略，进行针对性的优化，使JVM更好地服务于你的业务需求。
深入JVM内核—原理、诊断与优化视频教程-3.常用JVM配置参数
02-09
深入理解JVM的内核原理、诊断技巧以及优化方法对于提升应用性能至关重要。本教程——“深入JVM内核—原理、诊断与优化视频教程”，将重点讲解这些关键点，帮助开发者提升技术水平，更好地解决实际问题。 首先，我们...
深入JVM内核-原理、诊断与优化ppt.zip
最新发布
04-08
《深入JVM内核——原理、诊断与优化》是一份深度探讨Java虚拟机核心机制、问题诊断和性能优化的专业资料。这份资料涵盖了JVM的各个方面，对于Java开发者来说，理解和掌握这些知识至关重要。 首先，我们要了解JVM...
深入JVM内核—原理、诊断与优化视频教程-2.JVM运行机制
02-09
【JVM运行机制详解】 Java虚拟机（JVM）是Java平台的核心组成部分，它负责执行...在《深入JVM内核—原理、诊断与优化》视频教程中，会详细讲解这些内容，并结合实际案例进行演示和实践，帮助开发者成为JVM领域的专家。
-XX:GCTimeRatio
u014520797的专栏
03-15 4111
The Parallel Collector The parallel collector (also referred to here as thethroughput collector) is a generational collector similar to the serial collector. parallel 收集器（这里也叫做吞吐量收集器），是一个类似serial收...
微信小程序多图片上传问题
zezezes的博客
11-01 276
解决后台设置不同图片可能时间中不能区分的问题， 可以将后台时间再往后设置毫秒 具体为 //格式化时间戳 SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmssSSS"); String nowTime = sdf.format(new Date().getTime()); ...
JVM--GC调优
BtWangZhi的博客
03-06 311
基本原则 Parallel 除非确定，否则不要设置最大堆内存 优先设置吞吐量目标 如果吞吐量目标达不到，调大最大内存，不能让OS使用Swap，如果仍然达不到，降低目标。 吞吐量能达到，GC时间太长，设置停顿时间的目标。 设置metaspace 设置吞吐量和停顿时间参数 -XX:MaxGCPauseMillis=100 -XX:GCTimeRatio=99 设置动态扩容增量 -XX:YoungGenerationSizeIncrement=30 G1 年轻代大小：避免使用-Xmn、-XX:NewRat
GC常用参数指定
weixin_32822759的博客
08-06 278
GC 常用参数 -Xmn -Xms -Xmx –Xss 年轻代 最小堆 最大堆 栈空间 -XX:+UseTLAB 使用 TLAB， 默认打开 -XX:+PrintTLAB 打印 TLAB 的使用情况 -XX:TLABSize 设置 TLAB 大小-XX:+DisableExplicitGC 启用用于禁用对的调用处理的选项 System.gc() -XX:+PrintGC 查看 GC 基本信息 -XX:+PrintGCDetails 查看 GC 详细信息 -XX:+PrintHeapAtGC 每
深入理解JVM之垃圾收集器
qq_30233583的博客
09-22 171
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档 文章目录经典垃圾收集器Serial收集器 提示：这里可以添加本文要记录的大概内容： 提示：以下是本篇文章正文内容，下面案例可供参考 示例：pandas 是基于NumPy 的一种工具，该工具是为了解决数据分析任务而创建的。 提示：这里对文章进行总结： 例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。 经典垃圾收集器 如果说收集算法是内存回收的方法论，那
JVM笔记
weixin_44379586的博客
01-10 427
线程私有:栈,本地方法栈,程序计数器 线程共享:堆,方法区 程序计数器 线程私有 无内存溢出 JVM的多线程是通过线程之间轮流切换，分配处理器执行时间的方式来实现的。 为了保证线程切换后能回到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，这个内存区域称为线程私有的内存,执行Native方法时,程序计数器为空。 JVM栈 线程私有 描述的是Java执行方法的线程内存模型：每个方法被执行的时候，JVM都会同步创建一个 栈桢 用于存储 局部变量表 操作数栈
JVM最详细知识点笔记-监控与性能调优篇
热门推荐
qq_15267283的博客
01-10 1万+
性能监控与调优 一、概述 1.1 基本概述 监控的依据 运行日志 异常堆栈 GC日志 线程快照 堆转储快照 调优的方向 合理地编写代码 充分并合理的使用硬件资源 合理地进行JVM调优 1.2 性能优化的步骤 1.2.1 发现问题：性能监控 一种以非强行或者入侵方式收集或查看应用运营性能数据的活动。 监控通常是指一种在生产、质量评估或者开发环境下实施的带有预防或主动性的活动。 当应用相关干系人提出性能问题却没有提供足够多的线索时，首先我们需要进行性能监控，随后是性能分析。 常见的问题: GC
经典垃圾收集器
张紫娃的博客
08-17 525
年轻代GC策略：串行GC(Serial Copying)，并行回收GC(Parallel Scavenge)，并行GC(ParNew) 老年代GC策略：串行GC(Serial MSC)，并行GC(Parallel MSC)，并发GC(CMS) 年轻代 串行GC(Serial Copying) 1.算法：复制（copying）清理算法 2.操作步骤: 2.1扫描年轻代中所有存活对象 2.2使用Minor GC进行垃圾回收，同时将存活的对象保存到S0/S1区。 2.3在上一次Minor GC的基础上进行S0和S
GC（垃圾收集器）参数总结
para_Arya的博客
05-23 439
参数 描述 -verbose:gc 表示输出虚拟机中GC的详细情况 -Xms20M 设置堆最小容量为20M -Xmx20M 设置堆最大容量为20M -Xmn10M 设置新生代区的大小为10M -XX:+PrintGCDetails 打印GC详细信息 +PrintGCTimeStamps 打印GC时间信息 -Xloggc:eclipse_gc.log 打印GC...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值