zoukankan      html  css  js  c++  java
  • JVM优化-JVM参数配置

    配置方式:

      java [options] MainClass [arguments]

      options - JVM启动参数。 配置多个参数的时候,参数之间使用空格分隔。

      参数命名: 常见为 -参数名

      参数赋值: 常见为 -参数名=参数值 | -参数名:参数值

    内存参数:

      -Xms:初始堆大小,JVM启动的时候,给定堆空间大小。

      -Xmx:最大堆大小,JVM运行过程中,如果初始堆空间不足的时候,最大可以扩展到多少。

      -Xmn:设置年轻代大小。整个堆大小=年轻代大小+年老代大小+持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

      -Xss: 设置每个线程的Java栈大小。JDK5.0以后每个线程Java栈大小为1M,以前每个线程堆栈大小为256K。根据应用的线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。

      -XX:NewSize=n:设置年轻代大小

      -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3,表示年轻代与年老代比值为1:3,年轻代占整个年轻代+年老代和的1/4

      -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如:3,表示Eden:Survivor=3:2,一个Survivor区占整个年轻代的1/5

      -XX:MaxPermSize=n:设置持久代大小

      -XX:MaxTenuringThreshold:设置垃圾最大年龄。如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概率。

    内存配置:

      JVM中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制;系统的可用虚拟内存限制;系统的可用物理内存限制。32位系统 下,一般限制在1.5G~2G;64为操作系统对内存无限制。

      Tomcat配置方式: 编写catalina.bat|catalina.sh,增加JAVA_OPTS参数设置。windows和linux配置方式不同。windows - set "JAVA_OPTS=%JAVA_OPTS% 自定义参数";linux - JAVA_OPTS="$JAVA_OPTS 自定义参数"

    常见设置如下:

      -Xmx3550m -Xms3550m -Xmn2g -Xss128k 适合开发过程的测试应用。要求物理内存大于4G。

      -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=160m -XX:MaxTenuringThreshold=0 适合高并发本地测试使用。且大数据对象相对较多(如IO流)

      -Xmx10G -Xms10G -Xss1M -XX:NewRatio=3 -XX:SurvivorRatio=4 -XX:MaxPermSize=2048m -XX:MaxTenuringThreshold=5 环境:16G物理内存,高并发服务,重量级对象中等(线程池,连接池等),常用对象比例为40%(运行过程中产生的对象40%是生命周期较长的)

    收集器参数

    收集器配置的时候,次收集器和全收集器必须匹配

      -XX:+UseSerialGC:设置串行收集器,年轻带收集器, 次收集器

      -XX:+UseParallelGC:设置并行收集器

      -XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上,JVM会根据系统配置自行设置,所以无需再设置此值。

      -XX:+UseParallelOldGC:设置并行年老代收集器,JDK6.0支持对年老代并行收集。

      -XX:+UseConcMarkSweepGC:设置年老代并发收集器,测试中配置这个以后,-XX:NewRatio的配置失效,原因不明。所以,此时年轻代大小最好用-Xmn设置。

      -XX:+UseG1GC:设置G1收集器

    类似日志的配置信息。会有控制台相关信息输出。 商业项目上线的时候,不允许使用。一定使用loggc

      -XX:+PrintGC

      -XX:+Printetails

      -XX:+PrintGCTimeStamps

      -Xloggc:filename

    并行收集器参数如下:

      -XX:ParallelGCThreads=n:设置并行收集器收集时最大线程数使用的CPU数。并行收集线程数。

      -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间,单位毫秒。可以减少STW时间。

      -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)并发收集器设置

      -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。

      -XX:+UseAdaptiveSizePolicy:设置此选项后,并行收集器会自动选择年轻代区大小和相应的Survivor区比例,以达到目标系统规定的最低相应时间或者收集频率等,此值建议使用并行收集器时,一直打开。

      -XX:CMSFullGCsBeforeCompaction=n:由于并发收集器不对内存空间进行压缩、整理,所以运行一段时间以后会产生“碎片”,使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。

      -XX:+UseCMSCompactAtFullCollection:打开对年老代的压缩。可能会影响性能,但是可以消除碎片

    收集器设置

      关于收集器的选择JVM给了三种选择:串行收集器、并行收集器、并发收集器,但是串行收集器只适用于小数据量的情况,所以这里的选择主要针对并行收集器和并发收集器。默认情况下,JDK5.0以前都是使用串行收集器,如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后,JVM会根据当前系统配置进行判断。

    常见配置:

      并行收集器主要以到达一定的吞吐量为目标,适用于科学计算和后台处理等。

      -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20

      使用ParallelGC作为并行收集器, GC线程为20(CPU核心数>=20时),内存问题根据硬件配置具体提供。建议使用物理内存的80%左右作为JVM内存容量。

      -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC

      指定老年代收集器,在JDK5.0之后的版本,ParallelGC对应的全收集器就是ParallelOldGC。可以忽略

      -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100

      指定GC时最大暂停时间。单位是毫秒。每次GC最长使用100毫秒。可以尽可能提高工作线程的执行资源。

      -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy

      UseAdaptiveSizePolicy是提高年轻代GC效率的配置。次收集器执行效率。

      并发收集器主要是保证系统的响应时间,减少垃圾收集时的停顿时间。适用于应用服务器、电信领域、互联网领域等。

      -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

      指定年轻代收集器为ParNew,年老代收集器ConcurrentMarkSweep,并发GC线程数为20(CPU核心>=20),并发GC的线程数建议使用(CPU核心数+3)/4或CPU核心数【不推荐使用】。

      -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection

      CMSFullGCsBeforeCompaction=5执行5次GC后,运行一次内存的整理。

      UseCMSCompactAtFullCollection执行老年代内存整理。可以避免内存碎片,提高GC过程中的效率,减少停顿时间。

    优化思路

    年轻代大小选择

      响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择)。在此种情况下,年轻代收集发生的频率也是最小的。同时,减少到达年老代的对象。

      吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度。因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用。

    年老代大小选择

      响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了,可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间。最优化的方案,一般需要参考以下数据获得:

      并发垃圾收集信息

      持久代并发收集次数

      传统GC信息

      花在年轻代和年老代回收上的时间比例

      减少年轻代和年老代花费的时间,一般会提高应用的效率

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

      较小堆引起的碎片问题,因为年老代的并发收集器使用标记、清除算法,所以不会对堆进行压缩。当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象。但是,当堆空间较小时,运行一段时间以后,就会出现“碎片”,如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记、整理方式进行回收。如果出现“碎片”,可能需要进行如下配置:

      -XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩。

      -XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩

  • 相关阅读:
    Android常用URI收藏
    2017 ZSTU寒假排位赛 #3
    HDU 3689 Infinite monkey theorem ——(自动机+DP)
    CodeForces 755D PolandBall and Polygon ——(xjbg)
    2017 ZSTU寒假排位赛 #2
    HDU 3264 Open-air shopping malls ——(二分+圆交)
    HDU 1255 覆盖的面积 ——(线段树+扫描线)
    HDU 3265 Posters ——(线段树+扫描线)
    2017 ZSTU寒假排位赛 #1
    UVA 11853 Paintball ——(dfs+圆交判定)
  • 原文地址:https://www.cnblogs.com/guanghe/p/10636010.html
Copyright © 2011-2022 走看看