jvm调优的过程（思路）

如果你对GC过程不熟悉，建议先看上一篇文章：GC-垃圾回收站 https://www.jianshu.com/p/4ba980563ec0

什么情况下需要进行jvm调优？

1.Heap内存（老年代）持续上涨达到设置的最大内存值；
2.Full GC 次数频繁；
3.GC 停顿时间过长（超过1秒）；
4.应用出现OutOfMemory 等内存异常；
5.应用中有使用本地缓存且占用大量内存空间；
6.系统吞吐量与响应性能不高或下降。
第3点：使用Java的内存分析工具，如JVisualVM、JMC或JProfiler。这些工具可以帮助您分析Java堆内存中的对象，并找出哪些对象占用了大量的内存。您可以使用这些工具来检查应用程序的本地缓存，并查看缓存中存储的数据。

JVM调优的基本原则

JVM调优是一个手段，但并不一定所有问题都可以通过JVM进行调优解决，因此，在进行JVM调优时，我们要遵循一些原则：

  • 大多数的Java应用不需要进行JVM优化；
  • 大多数导致GC问题的原因是代码层面的问题导致的（代码层面）；
  • 上线之前，应先考虑将机器的JVM参数设置到最优；
  • 减少创建对象的数量（代码层面）；
  • 减少使用全局变量和大对象（代码层面）；
  • 优先架构调优和代码调优，JVM优化是不得已的手段（代码、架构层面）；
  • 分析GC情况优化代码比优化JVM参数更好（代码层面）；
    通过以上原则，我们发现，其实最有效的优化手段是架构和代码层面的优化，而JVM优化则是最后不得已的手段，也可以说是对服务器配置的最后一次“压榨”。
JVM调优目标

调优的最终目的都是为了令应用程序使用最小的硬件资源消耗来承载更大的吞吐。jvm调优主要是针对垃圾收集器的收集性能优化，令运行在虚拟机上的应用能够使用更少的内存以及延迟获取更大的吞吐量。

延迟：GC低停顿和GC低频率；
低内存占用；
高吞吐量;
其中，任何一个属性性能的提高，几乎都是以牺牲其他属性性能的损为代价的，不可兼得。具体根据在业务中的重要性确定。
注释：GC停顿（GC pause）是指在垃圾回收过程中，暂停所有应用程序线程的时间。这个停顿是为了让垃圾回收器能够有效地识别和回收不再使用的对象，从而释放内存空间。虽然GC停顿可能会影响应用程序的性能，但一些垃圾收集器采用了降低停顿时间和提高吞吐量的优化技术，如并行垃圾回收和增量标记等。这些技术可以减少GC停顿对应用程序的影响，从而提高系统的性能和响应速度。
GC低停顿和GC低频率：即降低GC的停顿时间 或 降低GC的频率

JVM调优量化目标

下面展示了一些JVM调优的量化目标参考实例：

  • Heap 内存使用率 <= 70%;
    Old generation内存使用率<= 70%;
    avgpause <= 1秒;
    Full gc 次数0 或 avg pause interval >= 24小时 ;
    注意：不同应用的JVM调优量化目标是不一样的。
调优工具 （参考GCViewer文章）

借助GCViewer日志分析工具，可以非常直观地分析出待调优点。可从以下几方面来分析：
Memory,分析Totalheap、Tenuredheap、Youngheap内存占用率及其他指标，理论上内存占用率越小越好；
Pause，分析Gc pause、Fullgc pause、Total pause三个大项中各指标，理论上GC次数越少越好，GC时长越小越好；

JVM调优的步骤

一般情况下，JVM调优可通过以下步骤进行：

  • 分析GC日志及dump文件，判断是否需要优化，确定瓶颈问题点；
  • 确定JVM调优量化目标；
  • 确定JVM调优参数（根据历史JVM参数来调整）；
  • 依次调优内存、延迟、吞吐量等指标；
  • 对比观察调优前后的差异；
  • 不断的分析和调整，直到找到合适的JVM参数配置；
  • 找到最合适的参数，将这些参数应用到所有服务器，并进行后续跟踪。
    以上操作步骤中，某些步骤是需要多次不断迭代完成的。一般是从满足程序的内存使用需求开始的，之后是时间延迟的要求，最后才是吞吐量的要求，要基于这个步骤来不断优化，每一个步骤都是进行下一步的基础，不可逆行之。
JVM参数

JVM调优最重要的工具就是JVM参数了。先来了解一下JVM参数相关内容。

-XX 参数被称为不稳定参数，此类参数的设置很容易引起JVM 性能上的差异，使JVM存在极大的不稳定性。如果此类参数设置合理将大大提高JVM的性能及稳定性。

不稳定参数语法规则包含以下内容。
布尔类型参数值：
-XX:+ ‘+’表示启用该选项
-XX:- ‘-‘表示关闭该选项

数字类型参数值：
-XX:=给选项设置一个数字类型值，可跟随单位，例如：’m’或’M’表示兆字节;’k’或’K’千字节;’g’或’G’千兆字节。32K与32768是相同大小的。

字符串类型参数值：
-XX:=给选项设置一个字符串类型值，通常用于指定一个文件、路径或一系列命令列表。例如：-XX:HeapDumpPath=./dump.core

JVM参数解析及调优

比如以下参数示例：

-Xmx4g –Xms4g –Xmn1200m –Xss512k -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:PermSize=100m -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=15

上面为Java7及以前版本的示例，在Java8中永久代的参数-XX:PermSize和-XX：MaxPermSize已经失效。这在前面章节中已经讲到。

参数解析：

-Xmx4g：堆内存最大值为4GB。
-Xms4g：初始化堆内存大小为4GB。
-Xmn1200m：设置年轻代大小为1200MB。增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss512k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1MB，以前每个线程堆栈大小为256K。应根据应用线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。
-XX:NewRatio=4：设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=8：设置年轻代中Eden区与Survivor区的大小比值。设置为8，则两个Survivor区与一个Eden区的比值为2:8，一个Survivor区占整个年轻代的1/10
-XX:PermSize=100m：初始化永久代大小为100MB。
-XX:MaxPermSize=256m：设置持久代大小为256MB。
-XX:MaxTenuringThreshold=15：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
新生代、老生代、永久代的参数，如果不进行指定，虚拟机会自动选择合适的值，同时也会基于系统的开销自动调整。

可调优参数：

-Xms：初始化堆内存大小，默认为物理内存的1/64(小于1GB)。

-Xmx：堆内存最大值。默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。

-Xmn：新生代大小，包括Eden区与2个Survivor区。

-XX:SurvivorRatio=1：Eden区与一个Survivor区比值为1:1。

-XX:MaxDirectMemorySize=1G：直接内存。报java.lang.OutOfMemoryError: Direct buffer memory异常可以上调这个值。

-XX:+DisableExplicitGC：禁止运行期显式地调用System.gc()来触发fulll GC。

注意: Java RMI的定时GC触发机制可通过配置-Dsun.rmi.dgc.server.gcInterval=86400来控制触发的时间。

-XX:CMSInitiatingOccupancyFraction=60：老年代内存回收阈值，默认值为68。

-XX:ConcGCThreads=4：CMS垃圾回收器并行线程线，推荐值为CPU核心数。

-XX:ParallelGCThreads=8：新生代并行收集器的线程数。

-XX:MaxTenuringThreshold=10：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

-XX:CMSFullGCsBeforeCompaction=4：指定进行多少次fullGC之后，进行tenured区 内存空间压缩。

-XX:CMSMaxAbortablePrecleanTime=500：当abortable-preclean预清理阶段执行达到这个时间时就会结束。

在设置的时候，如果关注性能开销的话，应尽量把永久代的初始值与最大值设置为同一值，因为永久代的大小调整需要进行FullGC才能实现。

内存优化示例

当JVM运行稳定之后，触发了FullGC我们一般会拿到如下信息:
3.153：
[Full GC(Ergonomics)
[PSYoungGen:37887K->0k(359424K{新生代大小})]
[ParOldGen:84645K->93168K{FulIGC之后老年代空间占用}(184832K{老年代大小}]
122533K->93168K(544256K),
[Metaspace: 3135K->3135K{FulIGC后永久代空间占用}(1056768K{永久代大小})],
0.0773607 secs{FullGC时间}]
[Times: user=0.25 sys=0.02, real=0.07 secs]

以上gc日志中，在发生fullGC之时，整个应用的堆占用以及GC时间。为了更加精确需多次收集，计算平均值。或者是采用耗时最长的一次FullGC来进行估算。上图中，老年代空间占用在93168kb（约93MB），以此定为老年代空间的活跃数据。则其他堆空间的分配，基于以下规则来进行。

java heap：参数-Xms和-Xmx，建议扩大至3-4倍FullGC后的老年代空间占用。
永久代：-XX:PermSize和-XX:MaxPermSize，建议扩大至1.2-1.5倍FullGc后的永久带空间占用。
新生代：-Xmn，建议扩大至1-1.5倍FullGC之后的老年代空间占用。
老年代：2-3倍FullGC后的老年代空间占用。

空间 倍数
总大小：3-4 倍活跃数据的大小
新生代：1-1.5 活跃数据的大小
老年代：2-3 倍活跃数据的大小
永久代 ：1.2-1.5 倍Full GC后的永久代空间占用

基于以上规则，则对参数定义如下：
java -Xms373m -Xmx373m -Xmn140m -XX:PermSize=5m -XX:MaxPermSize=5m

延迟优化示例

对延迟性优化，首先需要了解延迟性需求及可调优的指标有哪些。

应用程序可接受的平均停滞时间: 此时间与测量的Minor
GC持续时间进行比较。可接受的Minor GC频率：Minor
GC的频率与可容忍的值进行比较。
可接受的最大停顿时间:最大停顿时间与最差情况下FullGC的持续时间进行比较。
可接受的最大停顿发生的频率：基本就是FullGC的频率。
其中，平均停滞时间和最大停顿时间，对用户体验最为重要。对于上面的指标，相关数据采集包括：MinorGC的持续时间、统计MinorGC的次数、FullGC的最差持续时间、最差情况下，FullGC的频率。

吞吐量调优

吞吐量调优主要是基于应用程序的吞吐量要求而来的，应用程序应该有一个综合的吞吐指标，这个指标基于整个应用的需求和测试而衍生出来的。
评估当前吞吐量和目标差距是否巨大，如果在20%左右，可以修改参数，加大内存，再次从头调试，如果巨大就需要从整个应用层面来考虑，设计以及目标是否一致了，重新评估吞吐目标。
对于垃圾收集器来说，提升吞吐量的性能调优的目标就是尽可能避免或者很少发生FullGC或者Stop-The-World压缩式垃圾收集（CMS），因为这两种方式都会造成应用程序吞吐降低。尽量在MinorGC 阶段回收更多的对象，避免对象提升过快到老年代。

最后，回到文章的第一个问题，如果出现了以上问题，还可以通过以下的方法来分析：
1、Heap内存（老年代）持续上涨达到设置的最大内存值；
操作方法：jstat -gc <进程ID>，其中<进程ID>是Java进程的ID（使用JVisualVM或JMC也可以查看）

分析：如果Java的堆内存（老年代）持续上涨并达到设置的最大内存值，这通常意味着垃圾回收器（GC）无法有效地回收无用的对象，或者应用程序正在创建大量新的对象，超过了你设置的堆内存大小。这可能会导致OutOfMemoryError错误。

解决方案：
增加堆大小：如果你的应用程序确实需要更多的内存来运行，你可以尝试增加堆的大小。但是，请注意，这可能会导致系统其他部分的内存不足，从而影响性能。
优化代码：检查你的代码，看看是否有不必要的对象创建，或者是否有可以重用的对象。优化你的代码，以减少对象的创建和使用。
优化垃圾收集器：根据你使用的Java版本，你可以尝试调整垃圾收集器的参数。例如，你可以尝试使用G1垃圾收集器或者ZGC，这些垃圾收集器在处理大量内存时表现得更好。
使用Java的内存分析工具：例如JVisualVM、JMC（Java Mission Control）或者JStack，这些工具可以帮助你找出内存中的问题。
使用Java的Profiler：例如VisualVM、YourKit或者JProfiler，这些工具可以帮助你找出内存中的问题，并给出优化的建议。

2、Full GC 次数频繁；
操作方法：jconsole <PID> ，在JConsole中，选择“Java堆”选项卡，然后选择“垃圾收集”部分。您将看到有关Full GC的详细信息，包括次数和持续时间。如果使用的是云服务，也可以在云服务监控上查看，例如阿里云。

分析：Full GC（全局垃圾回收）可能会导致应用程序性能下降，因为Full GC会暂停整个应用程序，导致应用程序停顿和响应延迟。

解决方案：
系统承载高并发请求或处理大量数据，导致Young GC无法处理，每次Young GC后存活的对象过多，内存分配不合理，Survivor区过小，导致对象频繁进入老年代，频繁触发Full GC。解决方法是合理分配内存，调大SurLo垃圾回收器使用率，调大Survivor区。
系统一次性加载过多数据进内存，导致频繁有大对象进入老年带，触发Full GC。解决方法是分批次加载数据。
内存泄漏，创建大量对象，无法回收，一直占用老年代内存，导致频繁Full GC。解决方法是使用MAT工具分析内存快照，找出内存泄漏的原因并修复。
Metaspace（永久代）因加载类过多触发Full GC。解决方法是合理设置类加载器的大小。
误调用System.gc()触发Full GC。解决方法是避免滥用System.gc()，因为JVM并不一定会按照这个请求执行。

3、GC 停顿时间过长（超过1秒）；
操作方法：与查看Full GC次数相同，VisualVM是一个开源的Java虚拟机监视、分析和调试工具，可以用于监控JVM的性能和查看GC的详细信息。您可以使用VisualVM的“Sampler”和“Profiler”功能来监视应用程序的性能，并查看GC的停顿时长。

分析：如果GC停顿时间过长（超过1秒），这可能会导致应用程序性能下降，因为停顿时间过长会导致应用程序的响应缓慢和停顿。以下是一些可能导致GC停顿时间过长的原因和解决方法：

解决方案
应用程序的内存分配不合理，导致GC需要花费更多的时间来回收内存。解决方法是合理分配内存，避免过度使用内存。
系统承载高并发请求或处理大量数据，导致内存中的对象过多，GC需要花费更多的时间来处理这些对象。解决方法是分批次处理数据，避免一次性加载过多数据进内存。
内存泄漏，创建大量对象，无法回收，一直占用老年代内存，导致GC需要花费更多的时间来回收这些对象。解决方法是使用MAT工具分析内存快照，找出内存泄漏的原因并修复。
GC算法或垃圾收集器选择不当，导致GC效率低下。解决方法是根据应用程序的特点选择适合的GC算法和垃圾收集器，并进行调优。
代码中存在大量大对象的创建，导致GC需要花费更多的时间来处理这些对象。解决方法是避免创建过多的大对象，或者将大对象分解成小对象进行处理。

本文借鉴：
https://blog.csdn.net/agonie201218/article/details/123748148

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 212,816评论 6赞 492
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 90,729评论 3赞 385
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 158,300评论 0赞 348
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 56,780评论 1赞 285
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 65,890评论 6赞 385
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 50,084评论 1赞 291
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,151评论 3赞 410
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 37,912评论 0赞 268
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,355评论 1赞 303
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,666评论 2赞 327
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,809评论 1赞 341
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,504评论 4赞 334
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,150评论 3赞 317
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,882评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,121评论 1赞 267
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,628评论 2赞 362
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,724评论 2赞 351