常见的JVM参数

(后边学习到新的会进行补充)

-XX:MaxTenuringThreshold:对象晋升老年代的阈值,默认值15(并不是绝对的,如果在Survivor空间中相同年龄所有对象大小的综合大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代)<br />-XX:MaxPermSize~~:永久代大小<br />-XX:MaxDirectMemorySize:直接内存大小,默认与-Xmx一致<br />-XX:+/-UseTLAB:是否开启TLAB<br />-XX:MaxMetaspace=256m:元数据区,默认为无限大,受Java进程所使用的内存影响<br />-XX:FieldsAllocationStyle:对象内存分布中的实例数据区域的存储顺序<br />-XX:CompactFields=true:由于HotSpot在分配对象实例数据时相同大小的字段总是被分配到一起存储,在满足这个条件下因此父类中定义的变量会出现在子类之前,开启此参数那子类中较小的变量也允许插入父类变量的空隙中,以节省一点空间<br />-XX:+UseCondCardMark:是否开启JVM卡表条件判断,尽量减少伪共享带来的性能损耗<br />-XX:MaxGCPauseMillis(毫秒 >0):控制最大垃圾收集停顿时间,默认值200<br />-XX:ParallelGCThreads=NUM:垃圾收集并行执行线程数,默认为CPU的核数<br />-XX:+UseAdaptiveSizePolicy:是否开启自适应调节策略,JDK8默认开启<br />-XX:SurvivorRatio:Eden和Survivor区的比例<br />-XX:PretenureSizeThreshold:晋升老年代对象大小,超过指定大小直接在老年代分配,默认为0<br />-XX:+PrintGCDetails:打印GC详细日志<br />-XX:+PrintHeapAtGC:打印每次GC前后堆、方法区可用容量变化<br />-XX:+PrintGCApplicationConcurrentTime :查看GC过程中用户线程并发时间<br />-XX:+PrintGCApplicationStoppedTime:查看GC过程中用户线程停顿时间<br />-XX:+PrintFlagsFinal:查看JVM参数的默认值
<a name="nkixU"></a>

垃圾收集器相关:

CMS相关见文章<br />-XX:+UseConMarkSweepGC:开启使用CMS垃圾收集器,新生代使用ParNew 老年代使用CMS<br />-XX:CMSInitiatingOccupancyFraction=70:CMS垃圾收集器的回收阈值(老年代),JDK5及之前默认为68%,JDK6之后调整为92%。<br />-XX:+UseCMSInitiatingOccupancyOnly:与XX:CMSInitiatingOccupancyFraction配合使用,只是用设定的回收阈值(上面指定的70%),如果不指定,JVM仅在第一次使用设定值,后续则自动调整。<br />-XX:+/-CMSPrecleaningEnabled:开启/关闭CMS并发预清理。<br />
<br />-XX:CMSScheduleRemarkEdenSizeThreshold:CMS可取消并发预处理阶段开启条件-->默认为2M<br />-XX:CMSMaxAbortablePrecleanLoops:CMS可取消并发预处理阶段取消条件-->循环次数,默认为0<br />-XX:CMSMaxAbortablePrecleanTime:CMS可取消并发预处理阶段取消条件-->最长执行时间,默认为5000毫秒<br />-XX:CMSScheduleRemarkEdenPenetration:CMS可取消并发预处理阶段取消条件-->Eden区的内存使用率大于此配置后取消,默认值为50<br />-XX:+UseCMSCompactAtFullCollection:在进行Full GC之前进行一次内存整理,默认开启<br />-XX:CMSFullGCBeforeCompaction=N:当执行过N此无碎片整理Full GC后,下次Full GC之前进行一次内存整理,默认为0,表示每次都进内存整理<br />-XX:+CMSScavengeBeforeRemark:强制在CMS最终/重标记阶段前进行一次Minor GC,防止可中断预清理一直没有等到年轻代Minor GC而导致年轻代对象太多而导致最终标记时间过长,导致停顿时间过长<br />-XX:+CMSPermGenSweepingEnabled:开启CMS对永久代(元空间)的垃圾收集,默认不开启<br />-XX:+CMSClassUnloadingEnabled:与-XX:+CMSPermGenSweepingEnabled配合使用,收集永久代时卸载不用的类<br />G1l垃圾收集器<br />-XX:G1HeapRegionSize=8:设置G1垃圾收集器Region大小,取值范围应为1MB ~ 32MB,且应为2的N次幂。<br />-XX:G1NewSizePercent:新生代最小值,默认值5%<br />-XX:G1MaxNewSizePercent:新生代最大值,默认值60%<br />-XX:ParallelGCThreads:STW期间,并行GC线程数<br />-XX:ConcGCThreads=n:并发标记期间,GC线程数<br />-XX:InitiatingHeapOccupancyPercent:设置触发标记周期的 Java 堆占用率阈值。默认值是45%。这里的java堆占比指的是nonyoungcapacitybytes,包括old+humongous<br />-XX:G1HeapWastePercent:G1停止回收的最小内存,默认是堆的5%,就是说不必要每次回收就把所有的垃圾的处理完,可遗留少量的下次处理,这样也降低了单次GC消耗的时间<br />-XX:+GCTimeRatio:计算花在Java应用线程上和花在GC线程上时间比率,默认是9,跟新生代内存的分配比例一样。参数的主要目的是让用户可以控制花在应用上的时间,G1的计算公式是100/(1+GCTimeRatio)。如果参数设置为9,则最多花10%的时间在GC上面,Parallel GC默认值是99,表示1%的时间被用在GC上面,这是因为Parallel GC贯穿整个GC,而G1则根据Region来进行划分,不需要全局性扫描整个内存<br />-XX:G1ReserverPercent:G1为分配担保预留的空间比例,默认10%,也就是老年代会预留10%的空间来给新生代对象晋升,如果经常由于新生代对象晋升失败导致FullGC,可以适当调大此参数(调大此参数同时意味着老年代可使用的空间减少)
<a name="DvDjB"></a>

堆内存参数

在这里插入图片描述

<br />-Xmx:指定最大堆内存,如-Xmx49。但这只是限制了堆内存Heap部分的最大值,不包括堆外内存和栈内存<br />-Xms:指定堆内存的初始化大小,最小值,如Xms4g。而且指定的内存大小,并不是操作系统实际分配的初始值,而是GC先规划好,应用到才分配。专用服务需上需要保持-Xmx-Xms保持一致,否则应用刚启动可能就会有好几个FullGC。当两者配置不同时,堆内存扩容可能导致性能抖动。<br />-Xmn:等价于-XX:NewSize,Young区的大小,使用G1垃圾收集器不应该设置该选项,在其他的某些业务场景可以设置,官方建议设置为-Xmx的1/2~1/4<br />-XX:MaxPerSize:这是jdk1.7前使用的,JDK8后Meta空间默认无限大,此参数无效<br />-XX:MetaspeaceSize:Java8默认不限制Meta空间,一般不允许设置该选项<br />-XX:MaxDirectMemorySize:系统可食用的最大堆外内存,这个参数跟-Dsun.nio.MaxDirectMemorySize=1m等价<br />-Xss:设置每个线程栈的字节数,影响栈的深度
<a name="ZWpzW"></a>

分析诊断相关

-XX:+-HeapDumpOnOutOfMemoryError:当OOMError产生时,自动Dump堆内存<br />-XX:HeapDumpPath:与HeapDumpOnOutOfMemoryError搭配使用,指定内存溢出时Dump文件的目录,默认为启动Java程序的工作目录下<br />-XX:OnError:发生致命错误时执行的脚本<br />-XX:OnOutOfMemoryError:抛出OOMError错误是执行的脚本<br />-XX:ErrorFile=fileName:致命错误的日志文件名,绝对路径或者相对路径<br />-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1506:开启远程调试<br /><br />
<a name="YJpQl"></a>

运行模式

  • -server:设置JVM使用server模式,特点是启动速度比较慢,但运行时性能和内存管理效率很高,适用于生产环境。在具有64位JDK环境下将默认启用此模式,而忽略-client参数
  • -clinet:JDK1.7之前在32位的X86机器上的默认值是-client选项。设置JVM使用client模式,特点是启动速度较快,但运行时性能和内存管理效率不高,通常用于客户端程序或者本地PC机开发和调试。
  • -Xint:在解释模式下运行,-Xint标记会强制JVM解释所有的字节码,这会降低运行速度,通常低10倍或者更多
  • -Xcomp:-Xcomp参数与-Xint正好相反,JVM会在第一次使用时把所有的字节码编译成本地代码,从而带来最大程度的优化。[注意预热]
  • -Xmixed:-Xmixed是混合模式,将解释模式和编译模式进行混合使用,有JVM自己决定,这是JVM的默认模式,也是推荐模式,使用java -version可以看到 mixed mode等信息;
在这里插入图片描述

<a name="FxWab"></a>

编译优化

-XX:+DoEscapeAnalysis:开启逃逸分析<br />-XX:+EliminateAllocations:开启标量替换<br />-XX:+EliminateLocks :开启同步消除<br />相关文章见:编译优化技术<br />

参考资料

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,651评论 6 501
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,468评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,931评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,218评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,234评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,198评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,084评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,926评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,341评论 1 311
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,563评论 2 333
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,731评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,430评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,036评论 3 326
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,676评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,829评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,743评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,629评论 2 354

推荐阅读更多精彩内容