V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
mko0okmko0
V2EX  ›  Java

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

  •  
  •   mko0okmko0 · 2015-11-10 17:51:29 +08:00 · 3185 次点击
    这是一个创建于 3061 天前的主题,其中的信息可能已经有所发展或是发生改变。

    原始文章我发在:
    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 线程都觉得慢.而且设太多线程又会产生锁竞争(多核)或是锁虚耗(单核).

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

    5 条回复    2015-11-11 23:04:06 +08:00
    hantsy
        1
    hantsy  
       2015-11-11 10:38:45 +08:00
    -XX:PermSize=8m #设多小能正常用就设多小,反正都是省 ram .
    -XX:MaxPermSize=512m #记忆体够大就设大点,可避免异常,反正是按需使用.

    对于 Java 8 早没有用了。
    HentaiMew
        2
    HentaiMew  
       2015-11-11 12:26:27 +08:00
    你这些参数把我吓到了,虽然 JVM 可以配置的属性上百个,但是还真没发现什么能对比默认情况下差异能大到多明显的(除了故意错误配置)。
    你说能自适应可伸缩,听起来很好... 要是能上几张内存监控的对比图那就更好了。。。我还真想见识以下,打消我一直觉得折腾 JVM 参数是浪费精力的观点。
    那些牛 X 的公司很多都是基于 openjava 二次开发 JVM..... 好像也少折腾这些参数
    iyangyuan
        3
    iyangyuan  
       2015-11-11 13:42:57 +08:00 via iPhone
    这个要看实际程序的特点吧,还有通用的。。。
    mko0okmko0
        4
    mko0okmko0  
    OP
       2015-11-11 22:22:05 +08:00
    因为正在熬夜加班赶工中,所以有些回应要过一阵子等我出差工作完.

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

    @HentaiMew 图表我过一阵子弄
    ipeony
        5
    ipeony  
       2015-11-11 23:04:06 +08:00
    持续关注
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3478 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 10:56 · PVG 18:56 · LAX 03:56 · JFK 06:56
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.