我的 JVM 参数,as 和 eclipse 也可用,重点是自大部分都是适应参数,少部分需要用户依环境小改.特色是按需伸缩使用资源,适合桌面作业,或是不同规格虚拟机的预设参数. 一个 GC 的实验与结论,感觉猛,于是整理后再次分享

[mko0okmko0]

原始文章我发在:
https://www.v2ex.com/t/234287#reply5
结果很多条想要解释清楚又重新查说明.
结果又实验出更快的参数
不过我不知道该如何编辑已存在文章(会的回文教我啊)
"#"号后面是注解,含#号之后都可删除
-server #先调到 server 模式,很多预设参数直接优化了,启动稍慢但资源消耗有比较好.据说已经是预设值,但还是加入确保.
-Xms4m #我喜欢先设小,然后依需求消耗 ram , 并设定回收百分比参数提早回收 . 一开始就设大 , 你的 ram 肯定回收不了,设小才有回收机会
-Xmx1280m #除非是 jdk6 / jre6 , 或是 32bit 的 jvm , 否则请依照你开机好之后可用的空闲 ram 的 80~90% 设定 , 不然 ram 会用不到 .
-Xss512k # ram 很少就设小一点 , 很多人都设到 256K 都没问题,可等到异常再调大一点 .
-XX:+AggressiveOpts #开启官方激进优化.
-XX:PermSize=8m #设多小能正常用就设多小,反正都是省 ram .
-XX:MaxPermSize=512m #记忆体够大就设大点,可避免异常,反正是按需使用.
-XX:+UseG1GC #个人喜观不分新旧带的混合回收管理,用 AggressiveOpts 才有.大家依照自己喜欢的选 cms 爆发回收或是并行回收.
-XX:MaxGCPauseMillis=200 #每次回收资源的时间不要超过 0.2 秒,避免卡,但会增加顿的机会,用顿换不卡
-XX:+UseStringDeduplication #G1GC 送的字串重复空间回收,据说省 80%重复字串资源.
-XX:G1ReservePercent=20 #G1GC 当可回收的比例达 N%就回收,设大比较稳但吃 ram,很多人测试结果 20%是最佳 CP 值.ram 很多的人设 25~30%也可以.
-XX:InitiatingHeapOccupancyPercent=0 #G1GC 一直标记可回收 ram.我喜欢持续回收.用顿换不卡
-XX:+ScavengeBeforeFullGC #简单说,回收卡死之前尝试再次局部回收.用顿换不卡
-XX:MaxHeapFreeRatio=40 #当多余 40%空闲 ram 就还给系统 ram.
-XX:MinHeapFreeRatio=30 #当少于 30%空闲已用 ram 就申请 ram 来用
-XX:+DoEscapeAnalysis #启动 EliminateLocks 的前置条件
-XX:+EliminateLocks #分析并且消除线程锁.能提高性能.
-XX:+UseBiasedLocking #线程锁偏转,在竞争小的情况能优化锁竞争表现,但竞争太多就没效果,反正也不会更糟糕了就加上去.预设执行 3~5 秒后才有
-XX:BiasedLockingStartupDelay=0 #一开始执行就使用线程锁偏转.
-XX:+UseFastAccessorMethods #优化产生的 BIN,执行过程提速
-XX:+UseFastEmptyMethods #优化产生的 BIN,执行过程提速
-XX:+UseFastJNIAccessors #优化产生的 BIN,执行过程提速
-XX:+OptimizeStringConcat #字串+字串,会产生资源碎片,自动使用 stringbuilder 处理+字串.
-XX:UseAVX=2 #不加这个买赛扬算了,浪费好 CPU,=2:当你有小于 2 的 AVX 或是没有会自动降级和停用,所以加了也没差.
-XX:UseSSE=5 #不加这个买赛扬算了,浪费好 CPU,=5:当你有小于 5 的(s)sse 或是没有会自动降级和停用,所以加了也没差.不能大于 5 会出错.
-XX:+UseSSE42Intrinsics #不加这个买赛扬算了,浪费好 CPU,sse4.2 ,要这条才能启动.
-XX:+UseTLAB #动态化使用资源
-XX:+ResizeTLAB #动态化使用资源
-XX:+UseAdaptiveGCBoundary #动态化使用资源
-XX:+UseAdaptiveSizePolicy #动态化使用资源
-XX:CompileThreshold=8000 #-server 后有效,当 jvm 用脚本模式执行某程式某段几次后转成原生 BIN,次数将影响产生的 BIN 品质,越小越差但越快完成,经大量测试,8000 次之后的数字优化结果几乎同等 8000 所以是 8000 次后转 BIN.
-XX:+BackgroundCompilation #转 BIN 的时候用最低优先权的背景线程去转,让你的桌面工作顺畅.效果超级明显顺畅.
-XX:+TieredCompilation #当转 BIN 之后执行 8000 次再用这个 BIN 产生的资讯转第 2 次 BIN,终极优化 BIN.
-XX:+BindGCTaskThreadsToCPUs #如果你的 GC 线程跟 CPU 核心都大于 1,将 GC 线程分配到个别的 CPU 核心.
-XX:GCTimeRatio=1 #每一个 GC 线程最多可用 n/(1+n)=50%的 CPU 资源,只在回收工作中有消耗,所以总 GC 消耗不会差太远,但更快回收完就更快取得可用资源,所以让回收越快越好,请看下方特别解释:
-Djdk.map.althashing.threshold=0 #当有泛型容器放非常大量的物件在内,容易产生 hash 碰撞跟查找效率降低,用此参数能改善,原因太长不写了,大家可以查网路.

特别解释:
观察 GC 线程数量,发现即使用 G1GC,部分 GC 参数还是受到 CMS(爆发)GC 跟 Parallel(并行)GC 的部分参数影响.

ConcGCThreads(爆发 GC)不硬性设定时=(ParallelGCThreads+3)/4.
而 ParallelGCThreads(并行)不硬性输入的话自动同等 CPU 核心总数.

查了一堆优化说明,大都有提到,所谓线程就是将 CPU 时间切片来切换执行,所以越多线程,切换线程的消耗越大,但其实这些消耗都算虚耗,越少切换越好.多线程切换和锁的消耗真正的用处,是在多 CPU 核心之间的存取.
如果没有多核心,线程和锁大多是虚耗的,我们的参数应该尽可能的减少同核心内的线程切换和锁虚耗.所以我加上 BindGCTaskThreadsToCPUs.

观察发现,不管设定多少线程,GC 完成的总消耗其实蛮接近的,所以给 GC 线程的 CPU 资源越少,其实回收越久.而给 GC 线程的 CPU 资源越多,回收越快,而且回收完就不再消耗 CPU 资源.

所以我实验性的设定 GCTimeRatio=1(50%CPU),居然爆快阿!!而且观察 GC 线程只有 1,由此确认 G1GC 的 GC 线程数量受到 ConcGCThreads 影响.(我 4 核心 i7)

观察结论:
1 个吃 CPU 核心(最多)50%资源的 GC 线程,比 4 个 GC 并且一个吃 CPU 核心(最多)20%资源的 GC 线程还要快很多.
而预设的 GCTimeRatio=19(5%CPU 资源)...难怪设多少 GC 线程都觉得慢.而且设太多线程又会产生锁竞争(多核)或是锁虚耗(单核).

以上欢迎大家实验和讨论.我们应该去发掘结果不一的原因来讨论,而不是谩骂与虚耗.

[hantsy]

-XX:PermSize=8m #设多小能正常用就设多小,反正都是省 ram .
-XX:MaxPermSize=512m #记忆体够大就设大点,可避免异常,反正是按需使用.

对于 Java 8 早没有用了。

[HentaiMew]

你这些参数把我吓到了，虽然 JVM 可以配置的属性上百个，但是还真没发现什么能对比默认情况下差异能大到多明显的（除了故意错误配置）。
你说能自适应可伸缩，听起来很好... 要是能上几张内存监控的对比图那就更好了。。。我还真想见识以下，打消我一直觉得折腾 JVM 参数是浪费精力的观点。
那些牛 X 的公司很多都是基于 openjava 二次开发 JVM..... 好像也少折腾这些参数

[iyangyuan]

这个要看实际程序的特点吧，还有通用的。。。

[mko0okmko0]

因为正在熬夜加班赶工中,所以有些回应要过一阵子等我出差工作完.

@hantsy 你是对的,我没有把 java6/7/8 个别的分开,我过一阵子整理一下.

@HentaiMew 图表我过一阵子弄

[ipeony]

持续关注