2-JVM-虚拟机参数

作者: 宠辱不惊的咸鱼 | 来源:发表于2018-01-27 23:50 被阅读6次

2-JVM-虚拟机参数
eclipse 和 IDEA 设置虚拟机启动参数
JVM中参数
虚拟机调试（八）eclipse的debug知多少？
写个 Java 程序让 Metaspace 溢出
性能监控与调优
查看JVM使用的什么垃圾收集器
jvm参数使用说明
虚拟机参数
虚拟机参数

堆大小设置

JVM堆大小限制因素
- 操作系统位数
- 系统可用物理内存
- 系统可用虚拟内存
- x32：Windows一般1.5~2G；Linux 2~3G
- x64：无限制
典型设置

-Xms3550M -Xmx3550M -Xmn2G -Xss128K 
-XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:PermSize=16M -XX:MaxPermSize=16M -XX:MaxTenuringThreshold=0

参数说明
- -Xms3550M：JVM初始内存
- -Xmx3550M：JVM最大内存，等于Xms可避免自扩容和压缩
- -Xmn2G：年轻代大小
  - JVM内存 = 年轻代 + 年老代 + 永久代
  - 永久代一般固定为64M，增大年轻代后，将会减小年老代；Sun官方推荐配置为整个堆的3/8。
- -Xss128K：每个线程栈大小
  - JDK 5以后每个线程栈大小为1M，以前为256K
  - 相同物理内存下，减小这个值能生成更多的线程；但操作系统对一个进程内的线程数有限制，不能无限生成，经验值在3000~5000左右
- -XX:NewRatio=4
  - 年轻代与老年代的比例
  - 设置为4，年轻代：老年代为1：4
  - -XX:SurvivorRatio=8
    - Eden与Survivor比例
    - 设置为8，Survivor：Eden为2：8，一个Survivor区占1/10
- -XX:PermSize=6M：初始永久代大小
- -XX:MaxPermSize=16M：最大永久代大小
- -XX:MaxTenuringThreshold=0
  - 年轻代对象最大年龄
  - 设置为0时，年轻代对象不经过Survivor，直接进入年老代
  - 对于老年代对象比较多的应用，可以提高效率
  - 如果设置为一个较大值，则对象会在Survivor区进行多次复制，可以增加对象在年轻代的存活时间，增加在年轻代被回收的概率

收集器选择

串行
- 小数据量场景
- JDK 5以前默认
- JDK 5开始会自动调整
并行
- 吞吐量优先
- 科学计算和后台处理
并发
- 响应时间优先
- 应用服务器
并行典型配置

-XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelOldGC -XX:MaxGCPauseMillis=100 -XX:GCTimeRatio=n
-XX:+UseAdaptiveSizePolicy

参数说明
- -XX:+UseParallelGC
  - 并行收集器，仅对年轻代有效；年老代仍使用串行
- -XX:ParallelGCThreads=20
  - 并行收集线程数，最好与处理器数目相等
- -XX:+UseParallelOldGC
  - 年老代并行；JDK 6开始支持
- -XX:MaxGCPauseMillis=100
  - 年轻代回收最长时间；若无法满足，JVM会自动调整年轻代大小
- -XX:GCTimeRatio=n
  - 垃圾收集时间占比1/(n+1)
- -XX:+UseAdaptiveSizePolicy
  - 并行收集器自动选择年轻代大小和相应的Survivor比例，以达到最低响应时间或收集频率，建议使用并行收集器时一直打开
并发典型配置

-XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=5
-XX:+CMSIncrementalMode

-XX:+UseConcMarkSweepGC
- 年老代并发收集
- 测试中该配置后，-XX:NewRatio=4失效，原因不明；此时年轻代最好用-Xmn设置
-XX:+UseParNewGC
- 年轻代并行收集
- 可与CMS同时使用
- JDK 5以上，JVM会根据系统配置自行设置，所以无需再设置
-XX:+UseCMSCompactAtFullCollection
- 打开压缩，可能会影响性能
-XX:CMSFullGCsBeforeCompaction
- CMS不进行压缩整理，所以会产生碎片
- 运行多少次GC后对内存进行压缩整理
-XX:+CMSIncrementalMode
- 应该已废弃

G1

-XX:+UseG1GC # G1

辅助信息

选项

-XX:+PrintGC

输出形式

[GC 118250K->113543K(130112K), 0.0094143 secs]
[Full GC 121376K->10414K(130112K), 0.0650971 secs]

选项

-XX:+PrintGCDetails

输出形式

[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs]118250K->113543K(130112K), 0.0124633 secs]
[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs]121376K->10414K(130112K), 0.0436268 secs]

选项

-XX:+PrintGCTimeStamps

-输出形式

11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

选项

-XX:+PrintGCApplicationConcurrentTime # 每次垃圾回收前，程序未中断的执行时间

输出形式

Application time: 0.5291524 seconds

选项

-XX:+PrintGCApplicationStoppedTime # 垃圾回收期间程序暂停的时间

输出形式

Total time for which application threads were stopped: 0.0468229 seconds

选项

-XX:PrintHeapAtGC # 打印GC前后的详细堆栈信息

输出形式

34.702: [GC {Heap before gc invocations=7:
def new generation total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
  eden space 49152K,  99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
  from space 6144K,  55% used [0x221d0000, 0x22527e10, 0x227d0000)
  to space 6144K, 0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
tenured generation total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)the space 69632K, 3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)

34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)
Heap after gc invocations=8:
def new generation total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
  eden space 49152K, 0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
  from space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
  to space 6144K, 0% used [0x221d0000, 0x221d0000, 0x227d0000)
tenured generation total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)the space 69632K, 4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}, 0.0757599 secs]

选项

-Xloggc:filename # 记录日志到文件

调优总结

年轻代大小
- 响应时间优先
  - 尽可能大，接近系统最低响应时间限制；此种情况下，年轻代收集频率最小；同时，减少到达年老代的对象
- 吞吐量优先
  - 尽可能大，可能到达GB；因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用
老年代大小
- 响应时间优先
  - 年老代使用并发，所以大小需小心设置，一般要考虑并发会话率和会话持续时间等一些参数；若堆设置小了，可能因高回收频率及碎片引起的空间不足，导致并发收集停止，而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间
- 吞吐量优先
  - 一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代
  - 原因是：尽可能回收掉大部分短期对象，减少中期对象，而年老代仅存放长期存活对象
- 较小堆引起的碎片问题
  - 年老代并发收集器使用标记清除算法，不会进行压缩
  - 堆空间较小时，运行一段时间出现碎片，并发收集器找不到足够空间，就会停止；然后使用传统的标记清除方式进行回收
  - 若出现碎片，可考虑
    - -XX:+UseCMSCompactAtFullCollection
    - -XX:CMSFullGCsBeforeCompaction=0