JVM调优
建议级别 |
含义 | |
---|---|---|
1 |
强制 |
必须要设置该参数 |
2 |
强烈建议 |
无特殊情况,应当设置该参数 |
3 |
建议 |
各应用根据实际情况决定是否设置 |
4 |
一般建议 |
不做要求 |
序号 |
项目 |
配置项 |
含义 |
默认值 |
建议级别 |
建议值 |
说明 |
相关Case |
---|---|---|---|---|---|---|---|---|
1 |
内存 |
-Xms |
初始堆大小 |
操作系统物理内存的1/64但小于1G |
强制 |
4g |
JVM启动时申请的初始Heap值。 默认当空余堆内存大于70%时,JVM会减小heap的大小到-Xms指定的大小,可通过-XX:MaxHeapFreeRation=来指定这个比列 |
https://coe.mws.sankuai.com/detail/13573 内存使用不当,读取了大量数据进内存且在使用中不能释放:一次线上频繁fullgc原因排查 CaseStudy-20170713-闪惠服务大量fullgc导致前端调用超时 JVM 年轻代和年老代分配不合理:2016-04-30 活动大群连续解散引起的问题 |
2 |
-Xmx |
最大堆大小 |
物理内存的1/4但小于1G |
强制 |
4g |
默认当空余堆内存小于40%时,JVM会增大Heap到-Xmx指定的大小,可通过-XX:MinHeapFreeRation=来指定这个比列 |
||
3 |
-Xmn |
java堆Young区大小 |
强制 |
2g |
Sun官方推荐配置为整个堆的3/8。 可通过-Xmn参数来指定年轻代的大小,还可以通过-XX:SurvivorRation来调整Eden Space及SurvivorSpace的大小。 如果使用cms收集器(-XX:+UseConcMarkSweepGC),且未设置新生代大小或比例,新生代大小是计算出来的。见:https://www.jianshu.com/p/832fc4d4cb53 |
|||
4 |
-Xss |
java线程栈大小 |
JDK5.0以后每个线程堆栈大小为1M。 之前为256K |
一般建议 |
128k~256k |
在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。 |
||
5 |
-XX:SurvivorRation |
新生代中Eden区和Survivor区域大小比值 |
默认为8 |
一般建议 |
使用默认值 |
默认Eden : Survivor = 8:1 |
||
6 |
-XX:MetaspaceSize |
方法区大小 |
20.75M |
强制 |
256~512M |
如果meta区使用达到了该值,会触发fullgc、扩容. 即使设置为512M,也不会给程序分配512M内存,而是用多少分配多少 |
https://coe.mws.sankuai.com/detail/32907 |
|
7 |
-XX:MaxMetaspaceSize |
方法区最大大小 |
强制 |
256~512M |
如果这个参数没有设置,则是无穷大。 建议与MetaspaceSize设置成一样大 |
|||
8 |
-XX:+HeapDumpOnOutOfMemoryError |
oom时dump文件 |
一般建议 |
|||||
9 |
-XX:+HeapDumpPath |
dump文件的路径 |
一般建议 |
|||||
10 |
gc |
-XX:+UseSerialGC |
使用串行GC(SerialGC) 使用Serial + Serial Old的收集器组合 |
不设置 |
串行(SerialGC)是jvm的默认GC方式,一般适用于小型应用和单处理器,算法比较简单,GC效率也较高,但可能会给应用带来停顿。
|
|||
11 |
-XX:+UseParallelGC |
使用Parallel Scavenge + Serial Old的收集器组合 |
虚拟机运行在server模式下的默认值 |
不设置 |
并行(ParallelGC)是指多个线程并行执行GC,一般适用于多处理器系统中,可以提高GC的效率,但算法复杂,系统消耗较大。(配合使用:-XX:ParallelGCThreads=8,并行收集器的线程数,此值最好配置与处理器数目相等) |
|||
12 |
-XX:+UseParNewGC |
使用ParNew + Serial Old的收集器组合 |
JVM会根据系统配置自行设置,所以无需设置此值。 |
|||||
13 |
-XX:+UseParallelOldGC |
使用Parallel Scavenge + Parallel Old |
不设置 |
JKD6.0出现的参数选项 |
||||
14 |
-XX:ParallelGCThreads=n |
设置并行收集线程数 |
一般建议 |
与处理器数目相等 |
同样适用于CMS |
|||
15 |
-XX:+UseConcMarkSweepGC |
设置使用cms收集器 |
强烈建议 |
响应时间优先的应用,建议使用cms收集器 |
并发(ConcMarkSweepGC)是指GC运行时,对应用程序运行几乎没有影响(也会造成停顿,不过很小而已),GC和app两者的线程在并发执行,这样可以最大限度不影响app的运行。 |
|||
16 |
-XX:+UseCMSCompactAtFullCollection |
使用cms在Full GC的时候,对老年代进行压缩整理 |
强烈建议 |
打开 |
CMS是不会移动内存的,因此非常容易产生内存碎片。因此增加这个参数就可以在FullGC后对内存进行压缩整理,消除内存碎片。当然这个操作也有一定缺点,就是会增加CPU开销与GC时间,所以可以通过-XX:CMSFullGCsBeforeCompaction=3 这个参数来控制多少次Full GC以后进行一次碎片整理。 |
|||
17 |
-XX:CMSFullGCsBeforeCompaction |
多少次后进行内存压缩 |
XX:+UseCMSCompactAtFullCollection打开时,默认值为0 |
强烈建议 |
0~3 |
由于并发收集器不对内存空间进行压缩,整理,所以运行一段时间以后会产生"碎片",使得运行效率降低.此值设置运行多少次GC以后对内存空间进行压缩,整理. |
||
18 |
-XX:+CMSInitiatingOccupancyFraction |
使用cms时,老年代进行Full GC的空间占比,即使用空间达到设定比例值时, |
通常是92 |
强制 |
70~75 即老年代使用空间占比达到70%(或75%)时触发Full gc |
不设置的话,走自适应,一般是92%,容易造成担保失败。 建议配合-XX:+UseCMSInitiatingOccupancyOnly 使用,否则仅仅启动后第一次fullgc是按照设置的比例,后面仍然走自适应 |
||
19 |
-XX:+UseCMSInitiatingOccupancyOnly |
指定JVM总是使用-XX:CMSInitiatingOccupancyFraction的值作为老年代的空间使用率限制来启动CMS垃圾回收 |
强制 |
打开开关 |
使用-XX:+CMSInitiatingOccupancyFraction设定的阈值 |
|||
20 |
-XX:+CMSParallelRemarkEnabled |
降低标记停顿 |
强烈建议 |
打开 |
Remark阶段的并行,是指暂停了所有应用程序后,启动一定数目的垃圾回收进程进行并行标记,此时的应用线程是暂停的 |
|||
21 |
-XX:+PretenureSizeThreshold |
直接晋升到老年代的对象大小 |
不设置 |
设置该参数后,大于该值的对象直接在老年代分配 |
||||
22 |
-XX:+MaxTenuringThreshold |
晋升到老年代的对象年龄 |
不设置 |
每经过一次Minor gc,对象年龄加1,超过该值时晋升进入老年代。如果设置为0,则年轻代对象不经过Survivor区,直接进入老年代。 |
||||
23 |
-XX:+DisableExplicitGC |
关闭System.gc() |
不设置 |
打开开关可能导致nio的buffer内存泄漏 |
||||
24 |
gc log |
XX:+PrintGC |
打印gc日志 |
输出形式: [GC 118250K->113543K(130112K), 0.0094143 secs] |
||||
25 |
-XX:+PrintGCDetails |
打印gc详细 |
建议 |
打开 |
输出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] |
|||
26 |
-XX:+PrintGCTimeStamps |
建议 |
打开 |
|||||
27 |
-XX:+PrintGC:PrintGCTimeStamps |
建议 |
打开 |
可与-XX:+PrintGC -XX:+PrintGCDetails混合使用 |
||||
28 |
XX:+PrintGCDateStamps |
建议 |
打开 |
|||||
29 |
-XX:+PrintGCApplicationStoppedTime |
打印垃圾回收期间程序暂停的时间.可与上面混合使用 |
输出形式:Total time for which application threads were stopped: 0.0468229 seconds |
|||||
30 |
-XX:+PrintGCApplicationConcurrentTime |
打印每次垃圾回收前,程序未中断的执行时间.可与上面混合使用 |
输出形式:Application time: 0.5291524 seconds |
|||||
31 |
-XX:+PrintHeapAtGC |
打印GC前后的详细堆栈信息 |
||||||
32 |
-Xloggc:filename |
把相关日志信息记录到文件以便分析. |
建议 |
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战