一次Tomcat的JVM调优总结

最新推荐文章于 2024-04-14 23:00:16 发布

csdncjh

最新推荐文章于 2024-04-14 23:00:16 发布

阅读量1.1k

点赞数

分类专栏： # JVM 文章标签： tomcat java

本文链接：https://blog.csdn.net/csdncjh/article/details/121021329

版权

JVM 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

场景：

用户反馈，某一模块，闲时正常，一道用户量稍微大点，就会出现卡顿的情况，代码层面已经优化过了N次，数据库也清理出了资源，用户希望快速改善这个问题，因此尝试从JVM的调优来改善。

JAVA内存模型

来源

Java内存管理-JVM内存模型以及JDK7和JDK8内存模型对比总结（三） - 阿飞云 - 博客园

JVM内存：年轻代，老年代，永久代(jdk1.8永久移除，由元空间取代)_LZ_玉米的博客-CSDN博客

Java虚拟机规范（Java SE 7版）

运行时常量池变化

各个版本的变化

java8内存模型

JVM8内存图

方法区

方法区在JVM中也是一个非常重要的区域，它与堆一样，是被线程共享的区域。在方法区中，存储了每个类的信息（包括类的名称、方法信息、字段信息）、静态变量、常量以及编译器编译后的代码等。方法区是堆的一个逻辑部分，为了区分Java堆，它还有一个别名Non-Heap（非堆）。相对而言，GC对于这个区域的收集是很少出现的。当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

在Java 7及之前版本，我们也习惯称方法区它为“永久代”（Permanent Generation），更确切来说，应该是“HotSpot使用永久代实现了方法区”！

Java8为什么要将永久代替换成Metaspace？

1、字符串存在永久代中，容易出现性能问题和内存溢出。
2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
4、Oracle 可能会将HotSpot 与 JRockit 合二为一。

Java堆

堆是jvm内存管理的最大的一块区域，此内存区域的唯一目的就是存放对象的实例，所有对象实例与数组都要在堆上分配内存。它也是垃圾收集器的主要管理区域。java对可以处于物理上不连续的空间，只要逻辑上是连续的即可。线程共享的区域。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将抛出OutOfMemoryError异常。

为了支持垃圾收集，堆被分为三个部分：

年轻代 ：常常又被划分为Eden区和Survivor（From Survivor To Survivor）区(Eden空间、From Survivor空间、To Survivor空间（空间分配比例是8：1：1）
老年代
永久代 （jdk 8已移除永久代，取而代之的是另一块与堆不相连的本地内存——元空间）

JVM内存分代

JVM内存分代模型1

JVM内存分代模型2

在 Java 中，堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old)。新生代 ( Young ) 又被划分为三个区域：Eden、S0、S1。这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象，包括内存的分配以及回收。

Java 中的堆也是 GC 收集垃圾的主要区域。GC 分为两种：Minor GC、Full GC ( 或称为 Major GC )。

这里写图片描述

垃圾回收过程

来源

（转）Java垃圾回收基本过程 - hy_wx - 博客园

过程描述

1、首先，将任何新对象分配给eden空间。两个survivor空间都是空的。

2、当eden空间填满时，会触发轻微的垃圾收集。

3、引用的对象被移动到第一个survivor空间。清除eden空间时，将删除为引用的对象。

4、在下一次Minor GC中，Eden区也会做同样的操作。删除未被引用的对象，并将被引用的对象移动到Survivor区。然而，这里，他们被移动到了第二个Survivor区（S1）。此外，第一个Survivor区（S0）中，在上一次Minor GC幸存的对象，会增加年龄，并被移动到S1中。待所有幸存对象都被移动到S1后，S0和Eden区都会被清空。注意，Survivor区中有了不同年龄的对象。

5、在下一次Minor GC中，会重复同样的操作。不过，这一次Survivor区会交换。被引用的对象移动到S0.幸存的对象增加年龄。Eden区和S1被清空。

6、此幻灯片演示了promotion。在较小的GC之后，当老化的物体达到一定的年龄阈值（在该示例中为8）时，它们从年轻一代晋升到老一代。

7、随着较小的GC持续发生，物体将继续被推广到老一代空间。

8、所以这几乎涵盖了年轻一代的整个过程。最终，将主要对老一代进行GC，清理并最终压缩该空间。

一段形象的描述

Jvm区域总体分两类，heap区和非heap区。heap区又分：Eden Space（伊甸园）、Survivor Space(幸存者区)、Tenured Gen（老年代-养老区）。非heap区又分：Code Cache(代码缓存区)、Perm Gen（永久代）、Jvm Stack(java虚拟机栈)、Local Method Statck(本地方法栈)。

HotSpot虚拟机GC算法采用分代收集算法：

1、一个人（对象）出来（new 出来）后会在Eden Space（伊甸园）无忧无虑的生活，直到GC到来打破了他们平静的生活。GC会逐一问清楚每个对象的情况，有没有钱（此对象的引用）啊，因为GC想赚钱呀，有钱的才可以敲诈嘛。然后富人就会进入Survivor Space（幸存者区），穷人的就直接kill掉。

2、并不是进入Survivor Space（幸存者区）后就保证人身是安全的，但至少可以活段时间。GC会定期（可以自定义）会对这些人进行敲诈，亿万富翁每次都给钱，GC很满意，就让其进入了Genured Gen(养老区)。万元户经不住几次敲诈就没钱了，GC看没有啥价值啦，就直接kill掉了。

3、进入到养老区的人基本就可以保证人身安全啦，但是亿万富豪有的也会挥霍成穷光蛋，只要钱没了，GC还是kill掉。

JVM常用参数

来源

JVM常用基础参数-栈内存Xss讲解_泷泷养的乔小胖-CSDN博客_jvm xss

-Xms                                       初始堆内存大小，默认物理内存64/1

                                                -Xms = -XX:InitialHeapSize

-Xmx                                        最大堆内存，默认物理内存4/1

                                                 -Xmx = -XX:MaxHeapSize

-Xss                                        栈内存大小

                                                 设置单个线程栈大小，一般默认512~1024kb。

                                                 单个线程栈大小跟操作系统和JDK版本都有关系

                                                 -Xss = -XX:ThreadStackSize

-Xmn                                        年轻代大小

-XX:MetaspaceSize                    元空间大小

                                     元空间本质跟永久代类似，都是对JVM规范中方法区的实现。

                                     不过元空间与永久代最大的区别在于：元空间并不在虚拟机中，而是使用本机内存。

                                     因此，元空间大小仅受本地内存限制。

-XX:MetaspaceSize                    初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值

-XX:MaxMetaspaceSize               最大空间，默认是没有限制的

-XX:MinMetaspaceFreeRatio       在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集

-XX:MaxMetaspaceFreeRatio       在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集

-XX:+PrintGCDetails                  打印GC详细日志信息

-XX:SurvivorRatio                    幸存者比例设置

                                     2个Survivor区(From幸存区或To幸存区)和Eden区的比值

-XX:NewRatio                         新生代比例设置

                                      新生代（Eden + 2*S）与老年代（不包括永久区）的比值

-XX:MaxTenuringThreshold        进入老年代阈值设置

JVM监控分析

来源

dump分析工具_JVM实战：JVM常用监控工具_weixin_39757169的博客-CSDN博客

在线监控工具

JPS （打印Java进程信息）

常用命令： jps -l

Jstat （JVM统计信息）

使用场景：用于查看各个功能和区域的统计信息（如：类加载、编译相关信息统计，各个内存区域GC概况和统计）

格式： jstat 【选项】【进程ID】 [间隔时间/毫秒 ] [查询次数]

常用指令：jstat -gc PID

查看即时内存使用情况、垃圾回收统计信息，用于分析GC情况。

指令: jstat -gc 16462 1000 5
//查看16462进程应用的堆内存使用、垃圾回收统计信息，每个1000毫秒输出一次，总共输入5次。

参数说明

S0C 和 S0U //S0区的总内存大小和已使用的内存大小。

S1C: 和S1U //S1区的总内存大小和已使用的内存大小。。

EC 和 EU //Eden区的总内存大小和已使用的内存大小。

OC和OU //Old区的总内存大小和已使用的内存大小。

MC和MU //方法区的总内存大小和已使用的内存大小。

CCSC和CCSU //压缩类空间大小和已使用的内存大小。

YGC和 YGCT //Young GC 的总次数和消耗总时间。

FGC和 FGCT //Full Gc的总次数和消耗总时间。

GCT //所有GC的消耗时间。

jvm耗时和频率计算

来源

java ygc 频繁_jvm之判断ygc耗时和频率_琥蛮的博客-CSDN博客

ygc平均耗时=YGCT/YGC(s)

ygc时间间隔=程序的运行时间/YGC

fgc平均耗时=FGCT/FGC(s)

fgc时间间隔=程序的运行时间/FGC

程序运行总时间查看

ps -p {pid} -o etime

总结

如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化；如果GC时间超过1?3 秒，或者频繁G C ,则必须优化。如果满足下面的指标，则一般不需要进行GC调整。

Jinfo（JVM参数查看修改）

使用场景： 查看和调整JVM启动和运行参数。

案例一：查看JVM整个系统参数信息

比如：输出16462进程jvm的全部参数和系统属性。

指令： jinfo 16462

案列二：查看某个具体参数

比如：查看老年代内存大小

指令：jinfo -flag OldSize 16462

案列三：启用某个配置

比如：开启堆内存溢出日志打印（默认是关闭的）。

指令：jinfo -flag +PrintGCDetails 16462

案例四：修改某个参数值

比如：修改当堆内存对象所占空间超过80%时进行扩容

指令：jinfo -flag MaxHeapFreeRatio=80 16462

案列五：启用某个配置

比如：启动GC日志打印

指令：jinfo -flag +PrintGCDetails 16462

Jmap(JVM内存信息监控)

使用场景： 监控堆内存使用情况和对象占用情况，生成堆内存快照文件，查看堆内存区域配置信息。注意生产环境中如果程序的堆占用内存已经很大的话，不建议用这个分析。

格式：jmap 【选项】【进程ID】

案例一：查看堆内存的配置和使用情况

jmap -heap 18230

Heap Configuration:
MinHeapFreeRatio = 0 //JVM堆缩减空间比率，低于则进行内存缩减
MaxHeapFreeRatio = 100 //JVM堆扩大内存空闲比例，高于则进行内存扩张
MaxHeapSize = 994050048 (948.0MB) //堆最大内
NewSize = 20971520 (20.0MB) //新生代初始化内存大小
MaxNewSize = 331350016 (316.0MB) //新生代最大内存大小
OldSize = 41943040 (40.0MB) //老年代内存大小
NewRatio = 2 //新生代和老年代占堆内存比率
SurvivorRatio = 8 //s区和Eden区占新生代内存比率
MetaspaceSize = 21807104 (20.796875MB) //元数据初始化空间大小
CompressedClassSpaceSize = 1073741824 (1024.0MB) //类指针压缩空间大小
MaxMetaspaceSize = 17592186044415 MB //元数据最大内存代销
G1HeapRegionSize = 0 (0.0MB) //G1收集器Region单元大小

Heap Usage:
PS Young Generation
Eden Space:
capacity = 303038464 (289.0MB) //Eden区总容量
used = 22801000 (21.744728088378906MB) //Eden区已使用荣浪
free = 280237464 (267.2552719116211MB) //Eden区剩余容量
7.524127366221075% used //Eden区使用比例
From Space: //From区(也就是Survivor中的S1区)
capacity = 13107200 (12.5MB) //S1区总容量大小
used = 5364536 (5.116020202636719MB) //S1区已使用大小
free = 7742664 (7.383979797363281MB) //S1区剩余大小
40.92816162109375% used //S1使用比例
To Space: //To区 (也就是Survivor中的S2区)
capacity = 13631488 (13.0MB) //S2区总容量大小
used = 0 (0.0MB) //S2区已使用大小
free = 13631488 (13.0MB) //S2区剩余大小
0.0% used //S2区使用比率
PS Old Generation
capacity = 110624768 (105.5MB) //老年代总容量大小
used = 49431224 (47.14128875732422MB) //老年代已使用大小
free = 61193544 (58.35871124267578MB) //老年代剩余大小
44.68368602589973% used //老年代使用功能比例

案例二：查看JVM中对应类型对象的数量、占用内存情况

统计实例最多的类前十位有哪些

jmap -histo 18230 | sort -n -r -k 2 | head -10

统计合计容量前十的类有哪些

jmap -histo 18230 | sort -n -r -k 3 | head -10

案例三：dump 堆快照

命令:jmap -dump:live,format=b,file=/home/myheapdump.hprof 18230

live 加上live代表只dump存活的对象；
fomat 格式
filie 导出的文件名
18230 java进程ID

这里生成的 dump文件可以用我们后面讲的可视化工具VisualVM来打开文件对里面的内容进行分析。

VisualVM分析dump文件

来源

用jvisualvm分析dump文件_huangpeigui的专栏-CSDN博客_jvisualvm分析dump文件

注意装入时候选择的文件类型

VisualVM插件安装

来源

jvisualvm 无法下载插件解决方案_xixingzhe2的博客-CSDN博客

url地址:

https://visualvm.github.io/pluginscenters.html

选择对应版本的地址进入

复制Catalog URL

插件中心配置

将复制的地址拷贝到插件中心的地址中

第三方在线监控工具(Arthas)

Arthas 是Alibaba开源的Java诊断工具，它可以帮助我们解决在线环境的以下问题

监控到JVM的实时运行状态（涵盖Jps ,jstat ,jinfo ,jstack ,部分Jmap功能）。
在不需要重新部署服务的情况下修改业务代码。
以局视角来查看系统的运行状况。

JVM调优总结

GC大致流程

来源:

JVM GC调优一则--增大Eden Space提高性能_anningzhu的博客-CSDN博客

大部分新对象在Eden Space上分配，当Eden Space满了，则要用到Survivor Space来回收。YGC的算法是很快的。

多次YGC之后，还存活的对象就会被移到Old Generation（old space）上，当Old Generation满了的时候，就会FGC，FGC有通常比较慢。

Permanent Space只要你在开始时分配了足够大的空间，那它可以不用管

理想的GC/内存使用情况:

Old Space增长缓慢，FullGC次数少，FullGC的时间短（大部情况应该要在1秒内）。

总结:

尽量少加上一些默认参数。这点我很赞同RednaxelaFX的看法，配置了默认参数除了让后面调优的人蛋疼之外，没有太多的帮助。

GC调优就是一个取舍权衡的过程，有得必有失，最好可以在多个不同的实例里，配置不同的参数，然后进行比较。

尽可能最小化"短暂对象"移动到老年代的数量，同时最小化年轻代GC的次数和持续时间，要找到适当的折衷方案，首先要了解应用程序中对象年龄的分布情况。

有很多命令行工具或者图形工具可以使用，好的工具事半功倍。

调优总结：

1.新生代（Young generation）的空间太小，导致有一些本应该可以很快就被回收的对象被放到了老生代（Old generation）里，导致老生代上涨很快，频繁Full GC

2.内存泄露（Memory Leak）：程序在申请内存后，对象没有被GC所回收，它始终占用内存，内存泄漏的堆积最终会造成内存溢出。

3.内存溢出（Memory Overflow）：程序运行过程中无法申请到足够的内存而导致的一种错误。内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。通常都是由于内存泄露导致堆栈内存不断增大，从而引发内存溢出。

4.如果Eden区域设置太大

新生成的对象会被分配在Eden区，Eden空间不足时会触发MinorGC。理想状态下，如果所有对象在这个阶段全部被回收，Eden区域被清空，不会出什么问题。如果GC后还存在一部分幸存的对象，则会被复制到To Survivor区域，此时因为Survivor区域空间太小无法容纳这些对象，结果大部分幸存对象只在进行一次或很少次的GC后就会被移动到老年代，也就是说从某种程度上来讲失去了MinorGC的初衷，这种情况是肯定不被允许的。

5.Eden区域设置太小

Eden区域设置太小，意味着其空间很快就会被占满，也就是说增加了新生代的GC次数，而频繁的GC会降低整体JVM性能。

6.年轻代大小选择

响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

7.年老代大小选择
响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：
并发垃圾收集信息
持久代并发收集次数
传统GC信息
花在年轻代和年老代回收上的时间比例
减少年轻代和年老代花费的时间，一般会提高应用的效率

吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。

8.较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：
-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩。

来源：JVM调优总结 + jstat 分析【转】 - daddy再出发 - 博客园

9 Full GC过多

出现full gc的原因多是慢处理和高并发
(1）内存分配不合理，导致对象频繁进入老年代，进而引发频繁的Full GC；
(2) 存在内存泄漏等问题，就是内存里驻留了大量的对象塞满了老年代，导致稍微有一些对象进入老年代就会引发Full GC；
(3) 永久代里的类太多，触发了Full GC

导出dump文件
jmap -dump:live,format=b,file=/home/server/heap.bin 55025
使用mat分析
https://www.eclipse.org/mat/downloads.php

10. cpu过高
(1)一般是创建过多线程并发执行，且工作负载都很重，
(2) 频繁full gc

11.堆内存溢出

原因：高并发，慢查询

12.永久代（元空间）内存溢出

原因：使用字节码技术生产了太多的类

13.OOM处理排查

我们可以让JVM在OOM时dump一份内存快照，事后我们只要分析这个内存快照，一下就可以知道是哪些可恶的对象占用了所有的内存，并且还无法释放。

-XX:+HeapDumpOnOutOfMemoryError 在OOM的时候自动dump内存快照出来
-XX:HeapDumpPath=/usr/local/app/oom 把内存快照放到哪儿去

14.内存耗费过高

内存耗费超过50%感到有点惊讶，因为这说明他几乎快要把分配给他的内存消耗殆尽了！
1 在内存使用这么高的情况下会发生什么？

第一种:是内存使用率居高不下，导致频繁的进行full gc，gc带来的stop the world问题影响了服务。
第二种:是内存使用率过多，导致JVM自己发生OOM。
第三种:是内存使用率过高，也许有的时候会导致这个进程因为申请内存不足，直接被操作系统把这个进程给杀掉了！

15.常见内存溢出

（1） java.lang.OutOfMemoryError: Java heap space —-JVM Heap（堆）溢出

解决方法：手动设置 JVM Heap（堆）的大小。

（2） java.lang.OutOfMemoryError: PermGen space —- PermGen space溢出。

解决方法：手动设置 MaxPermSize 大小

（3） java.lang.StackOverflowError —- 栈溢出

解决方法：修改程序。

（4）java.lang.StackOverflowError异常

解决方法：Java中，栈的大小通过-Xss来设置，当栈中存储数据比较多时，需要适当调大这个值

来源

jvm日志分析_姚灿鹏的博客-CSDN博客

Tomcat的JVM调优

来源：

修改Tomcat使用的JVM内存大小_翻越山峰-CSDN博客_tomcat修改jvm内存大小

文件配置

Linux下修改JVM内存大小:

要添加在tomcat 的bin 下catalina.sh 里，位置cygwin=false前。注意引号要带上,红色的为新添加的.

# OS specific support. $var _must_ be set to either true or false.
JAVA_OPTS="-Xms256m -Xmx512m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m"
cygwin=false

windows下修改JVM内存大小:

情况一:解压版本的Tomcat, 要通过startup.bat启动tomcat才能加载配置

要添加在tomcat 的bin 下catalina.bat 里

rem Guess CATALINA_HOME if not defined
set CURRENT_DIR=%cd%后面添加,红色的为新添加的.

set JAVA_OPTS=-Xms256m -Xmx512m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m -Djava.awt.headless=true