JVM参数

1.verbose:gc

表示，启动jvm的时候，输出jvm里面的gc信息。格式如下：

[Full GC 178K->99K(1984K)， 0.0253877 secs]

解读 ：Full GC 就表示执行了一次Full GC的操作，178K 和99K 就表示执行GC前内存容量和执行GC后的内存容量。

1984K就表示内存总容量。后面那个是执行本次GC所消耗的时间，单位是秒。

2.-XX:+printGC

这个打印的GC信息跟上个一样，就不做介绍了。

3.-XX:+PrintGCDetails

打印GC的详细信息。格式如下：

解读：new generation 就是堆内存里面的新生代。total的意思就是一共的，所以后面跟的就是新生代一共的内存大小。

used也就是使用了多少内存大小。0x开头的那三个分别代表的是 底边界，当前边界，高边界。也就是新生代这片内存的起始点，当前使用到的地方和最大的内存地点。

eden space 这个通常被翻译成伊甸园区，是在新生代里面的，一些创建的对象都会先被放进这里。后面那个12288K就表示伊甸园区一共的内存大小，91% used，很明显，表示已经使用了百分之多少。后面的那个0x跟上一行的解释一样。

from space 和to space 是幸存者的两个区。也是属于新生代的。他两个区的大小必须是一样的。因为新生代的GC采用的是复制算法，每次只会用到一个幸存区，当一个幸存区满了的时候，把还是活的对象复制到另个幸存区，上个直接清空。

这样做就不会产生内存碎片了。

tenured generation 就表示老年代。

compacting perm 表示永久代。由于这两个的格式跟前面我介绍的那个几乎一样，我就不必介绍了。

4.-XX:+PrintGCTimeStamps

打印GC发生的时间戳。格式如下：

解读：289.556表示从jvm启动到发生垃圾回收所经历的的时间。GC表示这是新生代GC（Minor GC）。

PSYoungGen表示新生代使用的是多线程垃圾回收器Parallel Scavenge。314113K->15937K(300928K)]这个跟上面那个GC格式一样，只不过，这个是表示的是新生代，幸存者区。

后面那个是整个堆的大小，GC前和GC后的情况。Times这个显而易见，代表GC的所消耗的时间，用户垃圾回收的时间和系统消耗的时间和最终真实的消耗时间。

5.-X:loggc:log/gc.log

这个就表示，指定输出gc.log的文件位置。（我这里写的log/gc.log就表示在当前log的目录里，把GC日志写到叫gc.log的文件里。）

6.-XX:+PrintHeapAtGC

表示每次GC后，都打印堆的信息。（这个打印的基本格式跟上面第二条的基本类似，我也就不比多说了。）

7.-XX:+TraceClassLoading

监控类的加载。格式如下：

使用这个参数就能很清楚的看到那些类被加载的情况了。

8.-XX:+PrintClassHistogram

跟踪参数。这个按下Ctrl+Break后，就会打印一下信息：

–分别显示：序号、实例数量、总大小、类型。

这里面那个类型，B和C的其实就是byte和char类型。

9.-Xmx -Xms

这个就表示设置堆内存的最大值和最小值。这个设置了最大值和最小值后，jvm启动后，并不会直接让堆内存就扩大到指定的最大数值。

而是会先开辟指定的最小堆内存，如果经过数次GC后，还不能，满足程序的运行，才会逐渐的扩容堆的大小，但也不是直接扩大到最大内存。

10.-Xmn

设置新生代的内存大小。

11.-XX:NewRatio

新生代和老年代的比例。比如：1：4，就是新生代占五分之一。

12.-XX:SurvivorRatio

设置两个Survivor区和eden区的比例。比如：2：8 ，就是一个Survivor区占十分之一。

13.-XX:+HeapDumpOnOutMemoryError

发生OOM时，导出堆的信息到文件。

14.-XX:+HeapDumpPath

表示，导出堆信息的文件路径。

15.-XX:OnOutOfMemoryError

当系统产生OOM时，执行一个指定的脚本，这个脚本可以是任意功能的。比如生成当前线程的dump文件，或者是发送邮件和重启系统。

16.-XX:PermSize -XX:MaxPermSize

设置永久区的内存大小和最大值。永久区内存用光也会导致OOM的发生。

17.-Xss

设置栈的大小。栈都是每个线程独有一个，所有一般都是几百k的大小。

AutoBoxCacheMax

JAVA进程启动的时候,会加载rt.jar这个核心包的,rt.jar包里的Integer自然也是被加载到JVM中,Integer里面有一个IntegerCache缓存,如下:

 

private static class IntegerCache {
        static final int low = -128;
        static final int high;
        static final Integer cache[];

        static {
            // high value may be configured by property
            int h = 127;
            String integerCacheHighPropValue =
                sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
            if (integerCacheHighPropValue != null) {
                int i = parseInt(integerCacheHighPropValue);
                i = Math.max(i, 127);
                // Maximum array size is Integer.MAX_VALUE
                h = Math.min(i, Integer.MAX_VALUE - (-low) -1);
            }
            high = h;

            cache = new Integer[(high - low) + 1];
            int j = low;
            for(int k = 0; k < cache.length; k++)
                cache[k] = new Integer(j++);
        }

        private IntegerCache() {}
}

 

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

超过这个范围的,就只能构造新的Integer对象了。

public static Integer valueOf(int i) {
        assert IntegerCache.high >= 127;
        if (i >= IntegerCache.low && i <= IntegerCache.high)
            return IntegerCache.cache[i + (-IntegerCache.low)];
        return new Integer(i);
}

因此可以根据实际情况把AutoBoxCacheMax的值设置的大写,比如江南白衣推荐的

-XX:AutoBoxCacheMax=20000

-XX:+AlwaysPreTouch

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

1、GC的时候,新生代的对象要晋升到老年代的时候,需要内存,这个时候操作系统才真正分配内存,这样就会加大young gc的停顿时间;

2、可能存在内存碎片的问题。

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

-XX:+AlwaysPreTouch

参数,这样JVM就会先访问所有分配给它的内存,让操作系统把内存真正的分配给JVM.后续JVM就可以顺畅的访问内存了。

GC参数

JAVA 1.7用的垃圾收集算法还是CMS,下文提到的参数都是针对CMS的。

CMSInitiatingOccupancyFraction

之前写过一篇java垃圾回收算法之-CMS(并发标记清除),里面提到垃圾收集线程会跟应用的线程一起并行的工作,万一垃圾收集线程在工作的时候,老年代内存不足怎么办?因此最好还是提前启动CMS来收集垃圾(CMS GC)。

可以通过设置

CMSInitiatingOccupancyFraction=75

那么当老年代堆空间的使用率达到75%的时候就开始执行垃圾回收,CMSInitiatingOccupancyFraction默认值是92%,这个就太大了。

CMSInitiatingOccupancyFraction参数必须跟下面两个参数一起使用才能生效的。

-XX:+UseConcMarkSweepGC

-XX:+UseCMSInitiatingOccupancyOnly

MaxTenuringThreshold

新生代是使用copy算法来进行垃圾回收的,可以参看

java垃圾回收算法之-coping复制

默认情况下,当新生代执行了15次young gc后,如果还有对象存活在Survivor区中,那么就可以直接将这些对象晋升到老年代,但是由于新生代使用copy算法,

如果Survivor区存活的对象太久的话,Survivor区存活的对象就越多,这个就会影响copy算法的性能,使得young gc停顿的时间加长,建议设置成6。

-XX:MaxTenuringThreshold=6

ExplicitGCInvokesConcurrent

如果系统使用堆外内存,比如用到了Netty的DirectByteBuffer类,那么当想回收堆外内存的时候,需要调用

System.gc()

而这个方法将进行full gc,整个应用将会停顿,如果是使用CMS垃圾收集器,那么可以设置

-XX:+ExplicitGCInvokesConcurrent

这个参数来改变System.gc()的行为,让其从full gc --> CMS GC,CMS GC是并发收集的,且中间执行的过程中,只有部分阶段需要stop the world。

注意:设置了ExplicitGCInvokesConcurrent,那就不要设置DisableExplicitGC参数来禁掉System.gc()。

内存参数

-Xmx, -Xms

这两个一般都是设置4个g

NewRatio

GC最多的还是发生在新生代的young gc,所以可以提高一下新生代在整个堆的占用比例,建议设置为对半分,尽量避免young gc

-XX:NewRatio=1

 

 

参考

JVM调优-学习篇