Intellij IDEA 设置启动JVM参数

目录

• 采用CMS垃圾回收配置：
• 采用G1垃圾回收配置：
• 参数说明：
  • 通用参数：
  • CMS机制才有的参数：
  • G1机制才有的参数：
• 参考：

打开 IDEA 安装目录，看到有一个 bin 目录，其中有两个 vmoptions 文件，需针对不同的JDK进行配置：

采用CMS垃圾回收配置：#

Copy
-server
-Xms1024m
-Xmx2048m
-XX:MaxPermSize=1024m
-XX:ReservedCodeCacheSize=512m
-XX:+UseConcMarkSweepGC
-XX:+UseCodeCacheFlushing
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Dsun.awt.keepWorkingSetOnMinimize=true
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-Djsse.enablesSNIExtension=false
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-Dfile.encoding=UTF-8
-Duser.name=qhong

采用G1垃圾回收配置：#

Copy
-server
-XX:MetaspaceSize=128M 
-XX:MaxMetaspaceSize=512M 
-XX:+AlwaysPreTouch 
-Xms128m
-Xmx4g
-XX:ReservedCodeCacheSize=512m
-XX:+UseG1GC
-XX:+UseStringDeduplication
-XX:AutoBoxCacheMax=20000
-ea
-Dsun.io.useCanonCaches=false
-Dsun.awt.keepWorkingSetOnMinimize=true
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-Djsse.enablesSNIExtension=false
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-Dfile.encoding=UTF-8
-Duser.name=qhong

参数说明：#

通用参数：#

Xms#

初始化堆内存大小

Xmx#

堆内存最大值

ReservedCodeCacheSize#

-XX:InitialCodeCacheSize and -XX:ReservedCodeCacheSize

JVM一个有趣的，但往往被忽视的内存区域是“代码缓存”，它是用来存储已编译方法生成的本地代码。代码缓存确实很少引起性能问题，但是一旦发生其影响可能是毁灭性的。如果代码缓存被占满，JVM会打印出一条警告消息，并切换到interpreted-only 模式：JIT编译器被停用，字节码将不再会被编译成机器码。因此，应用程序将继续运行，但运行速度会降低一个数量级，直到有人注意到这个问题。就像其他内存区域一样，我们可以自定义代码缓存的大小。相关的参数是-XX:InitialCodeCacheSize 和-XX:ReservedCodeCacheSize，它们的参数和上面介绍的参数一样，都是字节值。

UseCodeCacheFlushing#

如果代码缓存不断增长，例如，因为热部署引起的内存泄漏，那么提高代码的缓存大小只会延缓其发生溢出。为了避免这种情况的发生，我们可以尝试一个有趣的新参数：当代码缓存被填满时让JVM放弃一些编译代码。通过使用-XX:+UseCodeCacheFlushing 这个参数，我们至少可以避免当代码缓存被填满的时候JVM切换到interpreted-only 模式

该值默认是开启的

AutoBoxCacheMax=20000#

JVM在加载Integer这个类时,会优先加载静态的代码。当JVM进程启动完毕后, -128 ~ +127 范围的数字会被缓存起来,调用valueOf方法的时候,如果是这个范围内的数字,则直接从缓存取出。

AlwaysPreTouch#

JAVA进程启动的时候,虽然我们可以为JVM指定合适的内存大小,但是这些内存操作系统并没有真正的分配给JVM,而是等JVM访问这些内存的时候,才真正分配,这样会造成以下问题。

• GC的时候,新生代的对象要晋升到老年代的时候,需要内存,这个时候操作系统才真正分配内存,这样就会加大young gc的停顿时间;
• 可能存在内存碎片的问题。

可以在JVM启动的时候,配置

Copy
-XX:+AlwaysPreTouch

CMS机制才有的参数：#

XX:+UseConcMarkSweepGC#

采用cms垃圾回收机制

PermSize#

JVM初始分配的非堆内存,就是永久代

Copy
-XX:PermSize=64M 
-XX:MaxPermSize=128M

MaxPermSize#

JVM最大允许分配的非堆内存，按需分配

G1机制才有的参数：#

XX:+UseG1GC#

G1垃圾回收机制

XX:MetaspaceSize#

初始元空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值

XX:MaxMetaspaceSize#

最大元空间，默认是没有限制的。

XX:+UseStringDeduplication#

G1垃圾回收器的时候，通过 JVM参数 -XX:+UseStringDeduplication 。 我们可以通过删除重复的字符串，只保留一个char[]来优化堆内存。

参考：#

JVM调优-学习篇

Metaspace 之一：Metaspace整体介绍（永久代被替换原因、元空间特点、元空间内存查看分析方法）

JVM实用参数（四）内存调优