java 内存回收参数_Java内存回收优化及配置

原文链接：http://eol.cqu.edu.cn/eol/jpk/course/preview/jpkmaterials_folder_txtrtfview.jsp?resId=23156&columnId=19322

通过对GC 理论部分的学习已经对JVM GC 有了比较全面的了解，已经了解了GC 的几种类型已经工作流程。本节主要从实践角度分门别类的了解GC 的各方面信息。

在HotSpot JVM 中有三种概念，分别代表了不同代中发生的GC 动作。

Minor GC：指发生在新生代的垃圾收集动作，由于新生代中对象生命周期较短，更新速度迅速，所以Minor GC 也会比较频繁，Minor GC 的回收速度也比较快。Minor GC 通常使用copying 算法，此算法一般为最有效的。

Major GC：指发生在老年代或永久代的垃圾收集动作，出现了Major GC，通常会伴随至少一次的 Minor GC(但有的收集策略会只有Major GC)。MajorGC 的速度一般会比比较慢。

Full GC：指对堆内存整体进行垃圾收集(包含新生代，老年代，永久代)，有时可以理解为仅是Major GC，又可以理解为Major GC + Minor GC，因为概念理解上的差异我们理解Full GC 为清理所有内存即可。

下面是内存及GC 的相关参数：

内存相关设置(32位系统Heap 最大支持2GB，64位以上无限制)

-Xms：初始堆(Heap)大小，默认3670k。当空闲堆内存小于40%时，JVM 就会增大堆内存直到-Xmx 所设置的最大值，可以通过-XX:MinHeapFreeRatio=n 设置其比例。

-Xmx：最大堆(Heap)大小，默认64m。当空闲堆内存大于70%时，JVM 会减少堆内存直到-Xms 所设置的最小值，可以通过-XX:MaxHeapFreeRatio=n 设置其比例。

-Xmn：新生代大小，增大新生代后会相应减小老年代大小。此值对系统性能影响较大，Java 官方推荐配置为整个堆大小的3/8。

-Xss：设置每个线程栈的大小。Java1.5

以后每个线程栈默认大小为1M，之前每个线程栈默认大小为256K。可以根据应用的线程所需内存大小进行调整。一般情况下默认值已经能满足绝大部分情景的

应用，如果想更进一步优化则需要非常细致的测试。在相同物理内存下，减小这个值能生成更多的线程，进程中可容纳线程数量与很多因素有关，感兴趣的可以详细

了解下，据说可以达到6500个以上。

-XX:MinHeapFreeRatio=40：如果发现空闲堆内存占到整个预估上限值的40%，则增大上限值。

-XX:MaxHeapFreeRatio=70：如果发现空闲堆内存占到整个预估上限值的70%，则收缩预估上限值。

-XX:NewRatio=2：设置年轻代和老年代的比值。例如：n=3，则表示年轻代与老年代比值为1:3，年轻代占整个年轻代与老年代之和的1/4。

-XX:SurvivorRatio=8：Eden 与Survivor 的占用比例。例如8表示，一个survivor 区占用 1/8 的Eden 内存，即1/10的新生代内存，此处需注意年轻代有2个survivor 区，所以比例为1:10。

-XX:TargetSurvivorRatio=50：实际使用的survivor 空间大小占比。默认是47%，最高90%。

-XX:MaxPermSize=64m：设置持久代(即方法区)占整个堆内存的最大值。

-XX:MaxTenuringThreshold=0：设置对象最大年龄。即对象在在Eden 与Survivor 区之间被复制的次数，每被复制一次就增加1岁，默认值为15。如果设置为0的话，则Eden 中对象不经过Survivor 区直接进入老年代。

收集器设置

-XX:-DisableExplicitGC：禁止在运行期显式地调用System.gc()，开启该选项后，GC 的触发时机将由Garbage Collector 全权掌控，默认：关闭。

-XX:+ScavengeBeforeFullGC：在Full GC前触发一次Minor GC，默认：启用。

-XX:+UseGCOverheadLimit：限制GC的运行时间。如果GC耗时过长，就抛OutOfMemoryError。

-XX:ParallelGCThreads=n：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

-XX:+UseTLAB：启用线程本地缓存区(Thread Local)。

-XX:+UseSerialGC：使用串行收集器。

-XX:+UseParallelGC：使用并行收集器。

-XX:+UseParallelOldGC：使用并行压缩收集器。

-XX:+UseConcMarkSweepGC：使用CMS 收集器。

G1收集器设置

-XX:+UseG1GC：使用G1收集器。

-XX:MaxGCPauseMillis=n：设置并行收集最大暂停时间，这是一个理想目标，JVM 将尽最大努力来实现它。

GC 日志设置

-XX:+PrintGC：开启GC日志打印。

-XX:+PrintGCDetails：打印GC回收的详细信息。

-XX:+PrintGCTimeStamps：打印GC停顿耗时。

-Xloggc:：输出GC 详细日志信息至指定文件。

-XX:+UseGCLogFileRotation：开启GC 日志文件切分功能，前置选项 -Xloggc。

-XX:NumberOfGClogFiles=1：设置切分GC 日志文件数量，文件命名格式：.0, .1, ..., .n-1。

-XX:GCLogFileSize=8K：GC日志文件切分大小。

参数的意义基本已经了解，下面就讲一讲如何使我们的程序运行的更快，更稳定。

1.内存相关设置

(1)首先是操作系统的选择，在32位操作系统下JVM 只支持最大2GB Heap 大小，所以这大大的局限了程序的运行性能。然而在64位操作系统下则没有任何限制，所以推荐使用64位操作系统。

(2)然后是硬件方面，可以根据经济情况相应增加CPU 数量及物理内存大小，这样利用并行收集器可以带来很高的垃圾清理效率。

(3)Heap 相关参数设置，大型的应用系统常常会被两个问题困扰：一个是启动缓慢，因为初始Heap 非常小，必须由很多major

收集器来调整内存大小；另一个更加严重的问题就是默认的Heap

最大值对于应用程序来说“太可怜了”。根据以下经验法则(即拇指规则，指根据经验大多数情况下成立，但不保证绝对)：

1)给于虚拟机更大的内存设置，往往默认的64mb 对于现代系统来说太小了。

2)将-Xms 与-Xmx 设置为相同值，这样做的好处是GC 后不用再频繁的根据内存使用情况去动态修改Heap 内存大小了，而且只有当内存使用达到-Xmx 设置的最大值时才会触发垃圾收集，这给GC 及系统减轻了负担。

3)设置过堆大小之后，可以根据程序创建对象的频率来调整新生代的内存大小，如果程序中创建新对象的频率比较搞可以适当调大新生代，但不要盲目调整，因为

新生代的大小对JVM 及系统性能影响较大，Java 官方推荐配置为整个堆大小的3/8，此值可以通过非标准参数-Xmn

直接调整大小或不稳定参数-XX:NewRatio=2 间接调整新生代与老年代的大小比值。

4)线程中栈的大小调整也是如此，需要比较谨慎及细致的测试之后修改。

2.GC 收集器的选择

在HotSpot JVM 中有大致5类收集器：串行收集器，并行收集器，并行压缩收集器，CMS 收集器，G1收集器。其中并行被并行压缩收集器所替代，CMS 收集器被G1收集器所替代，所以可供选择的只剩下三种。

(1)串行收集器(Serial Collector)

在同一时间只会执行一件垃圾清理任务，非常适用于单线程，单CPU 架构的程序，串行收集器的开销也比较小，在老年代中使用mark-sweep-compact(标记—扫描-压缩)算法， 对于堆内存不是很大的程序比较适用。

串行收集器适用场景：客户端程序(-client)和单线程比较小的应用。可以声明-XX:+UseSerialGC 选项使用串行收集器。

(2)并行压缩收集器(Parallel Compacting Collector)

并行压缩收集器是在J2SE1.5后引入，与并行收集器(并行收集器又被称作吞吐量收集器)最大的不同是对老年代的回收使用了不同的算法，并行压缩收集器

最终会取代并行收集器。并行压缩收集器最大的优点就是在消耗部分硬件性能及多CPU 支持下可以做到更短的stop-the-world

暂停，使回收效率更高从而增加了程序的吞吐量。

并行压缩收集器适用场景：程序稳定长期运行，希望任何时候我们的程序都能得到响应，即使程序执行速度缓慢，例如一些后台程序。硬件水平较高，例如多

CPU，多物理内存的服务器可以选择并行压缩收集器。可以声明-XX:+UseParallelOldGC 选项使用并行压缩收集器。

(3)CMS 收集器(Concurrent Mark-Sweep (CMS) Collector)

在很多应用中，更加注重快速的相应时间而不是吞吐量。新生代的垃圾回收通常不会造成长时间的应用程序中断，但是，对于老年代，特别是当Heap

已使用量比较大的时候会导致长时间的程序中断(虽然这种情况不常发生)。Hotspot JVM 引入CMS 的目的就是为了解决这个问题。

CMS 收集器适用场景(G1同理)：对于老年代使用率比较高的应用程序适合CMS 收集器，对停顿时间有较严格要求的程序也比较适合使用CMS

收集器。所以CMS

收集器多用于应用服务器程序上，例如web系统等。这类系统的共同特点就是响应时间一般较短，否则容易造成用户体验差的评价。可以声明

-xx:+UseConcMarkSweepGC 选项使用CMS。如果你还想让CMS

运行与增量模式下，则可声明–XX:+CMSIncrementalMode

选项启用增量模式。增量模式指的是把收集器的工作分成多个时间块，然后在两次新生代的回收期间加以运行，这种方式可以更进一步减少暂停的时间。

3.GC 日志的使用

然后来看一段非常简单的代码：

Java代码

public class GCTest {

public static void main(String[] args){

for (;;) {

System.gc();

}

}

}

Java 代码编译后，在控制台输入如下命令来运行此程序：

Java代码

java -server -verbose:gc GCTest

或

java -server -XX:+PrintGC GCTest

运行结果：

.....

[GC 160K->160K(125312K), 0.0004590 secs]

[Full GC 160K->160K(125312K), 0.0063689 secs]

.....

从运行结果我们可以看到GC 的执行情况，-verbose:gc 与-XX:+PrintGC 两个参数的作用相同，都是打印GC 基本信息，但基本信息中可参考的内容基本没有。

需要更加详细的GC 信息输出，可以使用-XX:+PrintGCDetails 参数，来打印GC 详情信息：

Java代码

java -server -XX:+PrintGCDetails Contacts

运行结果：

.....

[Full GC (System) [PSYoungGen: 0K->0K(38144K)] [PSOldGen:

160K->160K(87168K)] 160K->160K(125312K) [PSPermGen:

2937K->2937K(21248K)], 0.0055359 secs] [Times: user=0.00 sys=0.00,

real=0.01 secs]

[GC [PSYoungGen: 654K->32K(38144K)] 814K->192K(125312K), 0.0002939 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

.....

小提示，java 参数需要在类名前，否则在类名后的参数会被舍弃掉，格式如下：

java [-options] class [args...]

(执行class 文件)

java [-options] -jar jarfile [args...]

(执行jar 文件)

除了将GC 信息直接打印到控制台外更常用的做法是以文件的形式存储日志信息，利用-Xloggc: 来实现：

Java代码

java -server -XX:+PrintGCDetails -Xloggc:d:\gc.log GCTest

GC 打印的日志信息有固定的格式，可以将每条日志拆分成几部分来分析。

Major GC：

Full GC：

日志中已经包含了上面所说的几种不同内存中的GC 执行情况，可以很方便的了解那部分内存使用出现了问题，这样就可以集中解决出现问题的部分。