几台服务器的JVM占用内存总是持续增长，大大超过-Xmx设定的值，服务器物理内存几乎被耗尽。

使用jmap查看JVM的内存使用，发现jvm的堆大小完全在-Xmx参数设定的范围之内，那问题只能处在别的地方了。

JVM除了堆内存之外，就只有栈内存和DirectMemory了。栈空间每个线程是固定的，线程数也没可能多到可以占用这么多内存的程序，所以怀疑的目标就在DirectMemory上了。

DirectMemory是java nio引入的，直接以native的方式分配内存，不受jvm管理。这种方式是为了提高网络和文件IO的效率，避免多余的内存拷贝而出现的。DirectMemory占用的大小没有直接的工具或者API可以查看，不过这个在Bits类中是有两个字段存储了最大大小和已分配大小的，使用反射可以拿到这个数据：

Class<?> c = Class.forName("java.nio.Bits");
Field maxMemory = c.getDeclaredField("maxMemory");
maxMemory.setAccessible(true);
Field reservedMemory = c.getDeclaredField("reservedMemory");
reservedMemory.setAccessible(true);
Long maxMemoryValue = (Long)maxMemory.get(null);
Long reservedMemoryValue = (Long)reservedMemory.get(null);

结果证实了猜测，DirectMemory增长失控了。

原来，DirectMemory 的默认大小是64M，而JDK6之前和JDK6的某些版本的SUN JVM，存在一个BUG，在用-Xmx设定堆空间大小的时候，也设置了DirectMemory的大小。加入设置了-Xmx2048m，那么jvm最终可分配的内存大小为4G多一些，是预期的两倍。

解决方式是设置jvm参数-XX:MaxDirectMemorySize=128m，指定DirectMemory的大小。

Garbage-first garbage collector，简称G1 GC，是最终将用于代替Concurrent Mark-Sweep garbage collector(CMS GC)的新一代垃圾回收器。原本的计划是作为JDK7新特性的一部分发布，但其后JDK7一直在坚持不懈的跳票，G1也无法再等下去了。目前JDK1.6update14及以后版本的jvm中已经继承了G1 GC，可以使用参数-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC来启用。

G1是一个适用于服务器端、大内存、多CPU情景的垃圾收集器，主要目标是在维持高效率回收(high thoughput)的同时，提供软实时中断特性。用户可以指定一个时间上限，如果垃圾回收导致的程序暂停超过了用户设定的时间上限，会打断垃圾回收，恢复程序的执行。

G1的原理在于将堆划分成等一系列大小的区域，每一个区域都有一个对应的remembered set结构，用来记录指向这个区域中的地址的其他区域的指针。 在垃圾回收时，选择记录最少的一个区域进行，按找这种方式选择出来的区域，通常是有用数据最少、垃圾最多的区域，这也就是“Garbage-first ”名称的由来。假如没有外部的指针指向这个区域，就可以直接回收整块区域而不用进行内存Copy，这种情况真是太好了。

以区域为单位的回收，时间粒度更小，这也是实现垃圾回收软实时中断的基础。

G1付出的代价之一是额外的空间占用(用于remembered set)。

附送SUN公司的一篇论文，供想了解更多细节的人观览。

目前Oracle有两个JVM，一个是JRockit， 这是两年前收购BEA Systems时得到的；另一个则是Sun的Hotspot VM，这是前不久收购Sun时得到的。在上个月举行的Sun-Oracle未来路线图会议上，Oracle的管理团队表示要合并这两个项目。Oracle 首席工程师、Sun前雇员Mark Reinhold最近在播客上透露该合并计划“仍在进行当 中”，为此也“召开了很多会议”。

Reinhold说到：

从长期的合并计划来看，目前很难对这二者作出取舍。现在我们还不会停止这两个JVM的开发工作，因为有很多客户的产品是运行在这 两个JVM之上并且使用了每个JVM独有的特性。我们可不想搞出什么震荡，那样只会把系统搞死，但还是衷心希望未来能有JVM一统天下。

Reinhold说这个计划至少还需要一年半到两年的时间才能成行。

这两个JVM各具优缺点，因此最好的方式还是取其精华，弃其糟粕。Reinhold说“在Oracle内，无论是工程团队还是管理团队都在尽最大努 力找出每个JVM的优点”。他接着说到：

坦率地说，我们这几年一直在嫉妒JRockit中的某些特性，其任务控制特性就非常棒。

而HotSpot的性能优势是比较明显的，他说到“我们对HotSpot代码基，尤其是server编译器的印象是其有很多的head room，这是一个更加复杂的系统”。

前几个月我们一直在学习JRockit，这真是一段令人难忘的时光。JRockit绝对是世界一流的VM，但其内部却是那么的不 同。JRockit和HotSpot各具优势，因此我们将要创建一个非常帅的项目——综合JRockit和HotSpot各自的优势。

Reinhold推测合并后的VM将使用JRockit的垃圾回收器与服务功能，使用HotSpot的运行时编译器与混合的运行时系统。

在播客中，Reinhold还提到了JDK7的模块化特性（模块化可以让Java更有效地进入到小型设备领域）、通过invokeDynamic实 现的多语言能力以及通过ProjectCoin提升Java语言本身的生产力。开发者应该玩玩Jigsaw，而openJDK Build 88则将于下月中旬发布。

查看英文原文：Mark Reinhold Talks About JRockit/Hotspot Integration

来自IBM的一组统计数据：
98％的java对象，在创建之后不久就变成了非活动对象；只有2％的对象，会在长时间一直处于活动状态。
如果能对这两种对象区分对象，那么会提交GC的效率。在sun jdk gc中（具体的说，是在jdk1.4之后的版本），提出了不同生命周期的GC策略。

young generation：

生命周期很短的对象，归为young generation。由于生命周期很短，这部分对象在gc的时候，很大部分的对象已经成为非活动对象。因此针对young  generation的对象，采用copy算法，只需要将少量的存活下来的对象copy到to space。存活的对象数量越少，那么copy算法的效率越高。

young generation的gc称为minor gc。经过数次minor gc，依旧存活的对象，将被移出young generation，移到tenured generation

young generation分为：
eden：每当对象创建的时候，总是被分配在这个区域
survivor1：copy算法中的from space
survivor2：copy算法中的to sapce （备注：其中survivor1和survivor2的身份在每次minor gc后被互换）
minor gc的时候，会把eden+survivor1(2)的对象copy到survivor2(1)去。

tenured generation：
生命周期较常的对象，归入到tenured generation。一般是经过多次minor gc，还 依旧存活的对象，将移入到tenured generation。（当然，在minor gc中如果存活的对象的超过survivor的容量，放不下的对象会直接移入到tenured generation）
tenured generation的gc称为major gc，就是通常说的full gc。
采用compactiion算法。由于tenured generaion区域比较大，而且通常对象生命周期都比较长，compaction需要一定时间。所以这部分的gc时间比较长。
minor gc可能引发full gc。当eden＋from space的空间大于tenured generation区的剩余空间时，会引发full gc。这是悲观算法，要确保eden＋from space的对象如果都存活，必须有足够的tenured generation空间存放这些对象。

Permanet Generation：
该区域比较稳定，主要用于存放classloader信息，比如类信息和method信息。
对于spring hibernate这些需要动态类型支持的框架，这个区域需要足够的空间。
这部分内容相对比较理论，可以结合jstat，jmap等命令（当然也可以使用jconsole，jprofile，gciewer等工具），观察jdk gc的情

前面我们提到用-XX作为前缀的参数列表在jvm中可能是不健壮的，SUN也不推荐使用，后续可能会在没有通知的情况下就直接取消了；但是由于这些参数中的确有很多是对我们很有用的，比如我们经常会见到的-XX:PermSize、-XX:MaxPermSize等等；

下面我们将就Java HotSpot VM中-XX:的可配置参数列表进行描述；
这些参数可以被松散的聚合成三类：
行为参数（Behavioral Options）：用于改变jvm的一些基础行为；
性能调优（Performance Tuning）：用于jvm的性能调优；
调试参数（Debugging Options）：一般用于打开跟踪、打印、输出等jvm参数，用于显示jvm更加详细的信息；

由于sun官方文档中对各参数的描述也都非常少（大多只有一句话），而且大多涉及OS层面的东西，很难描述清楚，所以以下是挑选了一些我们开发中可能会用得比较多的配置项，若需要查看所有参数列表，可以点击HotSpot VM Specific Options.查看原文；

首先来介绍行为参数：

-XX:-DisableExplicitGC
     禁止调用System.gc()；但jvm的gc仍然有效

-XX:+MaxFDLimit
     最大化文件描述符的数量限制

-XX:+ScavengeBeforeFullGC
     新生代GC优先于Full GC执行

-XX:+UseGCOverheadLimit
     在抛出OOM之前限制jvm耗费在GC上的时间比例

-XX:-UseConcMarkSweepGC
     对老生代采用并发标记交换算法进行GC

-XX:-UseParallelGC
     启用并行GC

-XX:-UseParallelOldGC
     对Full GC启用并行，当-XX:-UseParallelGC启用时该项自动启用

-XX:-UseSerialGC
     启用串行GC

-XX:+UseThreadPriorities
     启用本地线程优先级

jvm中GC执行的三种方式，即串行、并行、并发；
串行（SerialGC）是jvm的默认GC方式，一般适用于小型应用和单处理器，算法比较简单，GC效率也较高，但可能会给应用带来停顿；
并行（ParallelGC）是指GC运行时，对应用程序运行没有影响，GC和app两者的线程在并发执行，这样可以最大限度不影响app的运行；
并发（ConcMarkSweepGC）是指多个线程并发执行GC，一般适用于多处理器系统中，可以提高GC的效率，但算法复杂，系统消耗较大；

性能调优参数列表：

-XX:LargePageSizeInBytes=4m
     设置用于Java堆的大页面尺寸

-XX:MaxHeapFreeRatio=70
     GC后java堆中空闲量占的最大比例

-XX:MaxNewSize=size
     新生成对象能占用内存的最大值

-XX:MaxPermSize=64m
     老生代对象能占用内存的最大值

-XX:MinHeapFreeRatio=40
     GC后java堆中空闲量占的最小比例

-XX:NewRatio=2
     新生代内存容量与老生代内存容量的比例

-XX:NewSize=2.125m
     新生代对象生成时占用内存的默认值

-XX:ReservedCodeCacheSize=32m
     保留代码占用的内存容量

-XX:ThreadStackSize=512
     设置线程栈大小，若为0则使用系统默认值

-XX:+UseLargePages
     使用大页面内存

调试参数列表：

-XX:-CITime
     打印消耗在JIT编译的时间

-XX:ErrorFile=./hs_err_pid .log
     保存错误日志或者数据到文件中

-XX:-ExtendedDTraceProbes
     开启solaris特有的dtrace探针

-XX:HeapDumpPath=./java_pid .hprof
     指定导出堆信息时的路径或文件名

-XX:-HeapDumpOnOutOfMemoryError
     当首次遭遇OOM时导出此时堆中相关信息

-XX:OnError=";"
     出现致命ERROR之后运行自定义命令

-XX:OnOutOfMemoryError=";"
     当首次遭遇OOM时执行自定义命令

-XX:-PrintClassHistogram
     遇到Ctrl-Break后打印类实例的柱状信息，与jmap -histo功能相同

-XX:-PrintConcurrentLocks
     遇到Ctrl-Break后打印并发锁的相关信息，与jstack -l功能相同

-XX:-PrintCommandLineFlags
     打印在命令行中出现过的标记

-XX:-PrintCompilation
     当一个方法被编译时打印相关信息

-XX:-PrintGC
     每次GC时打印相关信息

-XX:-PrintGC Details
     每次GC时打印详细信息

-XX:-PrintGCTimeStamps
     打印每次GC的时间戳

-XX:-TraceClassLoading
     跟踪类的加载信息

-XX:-TraceClassLoadingPreorder 跟踪被引用到的所有类的加载信息
-XX:-TraceClassResolution 跟踪常量池
-XX:-TraceClassUnloading 跟踪类的卸载信息
-XX:-TraceLoaderConstraints 跟踪类加载器约束的相关信息

当系统出现问题的时候，又不能使用外部跟踪工具（比如JProfiler……）的情况下，以上的这些参数就会发挥重大作用了，比如dump堆信信息、打印并发锁……

非标准参数又称为扩展参数，其列表如下：
-Xint
     设置jvm以解释模式运行，所有的字节码将被直接执行，而不会编译成本地码。
-Xbatch
     关闭后台代码编译，强制在前台编译，编译完成之后才能进行代码执行；
     默认情况下，jvm在后台进行编译，若没有编译完成，则前台运行代码时以解释模式运行。
-Xbootclasspath:bootclasspath
     让jvm从指定路径（可以是分号分隔的目录、jar、或者zip）中加载bootclass，用来替换jdk的rt.jar；若非必要，一般不会用到；
-Xbootclasspath/a:path
     将指定路径的所有文件追加到默认bootstrap路径中；
-Xbootclasspath/p:path
     让jvm优先于bootstrap默认路径加载指定路径的所有文件；
-Xcheck:jni
     对JNI函数进行附加check；此时jvm将校验传递给JNI函数参数的合法性，在本地代码中遇到非法数据时，jmv将报一个致命错误而终止；使用该参数后将造成性能下降，请慎用。
-Xfuture
     让jvm对类文件执行严格的格式检查（默认jvm不进行严格格式检查），以符合类文件格式规范，推荐开发人员使用该参数。
-Xnoclassgc
     关闭针对class的gc功能；因为其阻止内存回收，所以可能会导致OutOfMemoryError错误，慎用；
-Xincgc
     开启增量gc（默认为关闭）；这有助于减少长时间GC时应用程序出现的停顿；但由于可能和应用程序并发执行，所以会降低CPU对应用的处理能力。
-Xloggc:file
     与-verbose:gc功能类似，只是将每次GC事件的相关情况记录到一个文件中，文件的位置最好在本地，以避免网络的潜在问题。
若与verbose命令同时出现在命令行中，则以-Xloggc为准。
-Xmsn
     指定jvm堆的初始大小，默认为物理内存的1/64，最小为1M；可以指定单位，比如k、m，若不指定，则默认为字节。
-Xmxn
     指定jvm堆的最大值，默认为物理内存的1/4或者1G，最小为2M；单位与-Xms一致。
-Xprof
     跟踪正运行的程序，并将跟踪数据在标准输出输出；适合于开发环境调试。
-Xrs
     减少jvm对操作系统信号（signals）的使用，该参数从1.3.1开始有效；
     从jdk1.3.0开始，jvm允许程序在关闭之前还可以执行一些代码（比如关闭数据库的连接池），即使jvm被突然终止；
     jvm 关闭工具通过监控控制台的相关事件而满足以上的功能；更确切的说，通知在关闭工具执行之前，先注册控制台的控制handler，然后对 CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT这几类事件直接返回true。
     但如果jvm以服务的形式在后台运行（比如servlet引擎），他能接收CTRL_LOGOFF_EVENT事件，但此时并不需要初始化关闭程序；为了避免类似冲突的再次出现，从jdk1.3.1开始提供-Xrs参数；当此参数被设置之后，jvm将不接收控制台的控制handler，也就是说他不监控和处理CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, or CTRL_SHUTDOWN_EVENT事件。
-Xssn
     设置单个线程栈的大小，一般默认为512k。

上面这些参数中，比如-Xmsn、-Xmxn……都是我们性能优化中很重要的参数；
-Xprof、-Xloggc:file等都是在没有专业跟踪工具情况下排错的好手；
在上一小节中提到的关于 JProfiler的配置中就使用到了-Xbootclasspath/a:path；

Java启动参数共分为三类；
其一是标准参数（-），所有的JVM实现都必须实现这些参数的功能，而且向后兼容；
其二是非标准参数（-X），默认jvm实现这些参数的功能，但是并不保证所有jvm实现都满足，且不保证向后兼容；
其三是非Stable参数（-XX），此类参数各个jvm实现会有所不同，将来可能会随时取消，需要慎重使用；
本文主要描述标准参数部分，剩下的两个部分将会陆续推出；

标准参数列表如下：
-client
设置jvm使用client模式，特点是启动速度比较快，但运行时性能和内存管理效率不高，通常用于客户端应用程序或者PC应用开发和调试。

-server
设置jvm使server模式，特点是启动速度比较慢，但运行时性能和内存管理效率很高，适用于生产环境。在具有64位能力的jdk环境下将默认启用该模式，而忽略-client参数。

-agentlib:libname[=options]
用于装载本地lib包；
其中 libname为本地代理库文件名，默认搜索路径为环境变量PATH中的路径，options为传给本地库启动时的参数，多个参数之间用逗号分隔。在 Windows平台上jvm搜索本地库名为libname.dll的文件，在linux上jvm搜索本地库名为libname.so的文件，搜索路径环境变量在不同系统上有所不同，比如Solaries上就默认搜索LD_LIBRARY_PATH。
比如：-agentlib:hprof
用来获取jvm的运行情况，包括CPU、内存、线程等的运行数据，并可输出到指定文件中；windows中搜索路径为JRE_HOME/bin/hprof.dll。

-agentpath:pathname[=options]
按全路径装载本地库，不再搜索PATH中的路径；其他功能和agentlib相同；更多的信息待续，在后续的JVMTI部分会详述。

-classpath classpath
-cp classpath
告知jvm搜索目录名、jar文档名、zip文档名，之间用分号;分隔；使用-classpath后jvm将不再使用CLASSPATH中的类搜索路径，如果-classpath和CLASSPATH都没有设置，则jvm使用当前路径(.)作为类搜索路径。
jvm搜索类的方式和顺序为：Bootstrap，Extension，User。
Bootstrap中的路径是jvm自带的jar或zip文件，jvm首先搜索这些包文件，用System.getProperty("sun.boot.class.path")可得到搜索路径。
Extension是位于JRE_HOME/lib/ext目录下的jar文件，jvm在搜索完Bootstrap后就搜索该目录下的jar文件，用System.getProperty("java.ext.dirs")可得到搜索路径。
User搜索顺序为当前路径.、CLASSPATH、-classpath，jvm最后搜索这些目录，用System.getProperty("java.class.path")可得到搜索路径。

-Dproperty=value
设置系统属性名/值对，运行在此jvm之上的应用程序可用System.getProperty("property")得到value的值。
如果value中有空格，则需要用双引号将该值括起来，如-Dname="space string"。
该参数通常用于设置系统级全局变量值，如配置文件路径，以便该属性在程序中任何地方都可访问。

-enableassertions[: "..." | : ]
-ea[: "..." | : ]
上述参数就用来设置jvm是否启动断言机制（从JDK 1.4开始支持），缺省时jvm关闭断言机制。
用-ea 可打开断言机制，不加 和classname时运行所有包和类中的断言，如果希望只运行某些包或类中的断言，可将包名或类名加到-ea之后。例如要启动包com.wombat.fruitbat中的断言，可用命令java -ea:com.wombat.fruitbat...

-disableassertions[: "..." | :
-da[: "..." | : ]
用来设置jvm关闭断言处理，packagename和classname的使用方法和-ea相同，jvm默认就是关闭状态。
该参数一般用于相同package内某些class不需要断言的场景，比如com.wombat.fruitbat需要断言，但是com.wombat.fruitbat.Brickbat该类不需要，则可以如下运行：
java -ea:com.wombat.fruitbat...-da:com.wombat.fruitbat.Brickbat

-jar
指定以jar包的形式执行一个应用程序。
要这样执行一个应用程序，必须让jar包的manifest文件中声明初始加载的Main-class，当然那Main-class必须有public static void main(String[] args)方法。

-javaagent:jarpath[=options]
指定jvm启动时装入java语言设备代理。
Jarpath 文件中的mainfest文件必须有Agent-Class属性。代理类也必须实现公共的静态public static void premain(String agentArgs, Instrumentation inst)方法（和main方法类似）。当jvm初始化时，将按代理类的说明顺序调用premain方法；具体参见 java.lang.instrument软件包的描述。

-verbose
-verbose:class
输出jvm载入类的相关信息，当jvm报告说找不到类或者类冲突时可此进行诊断。
-verbose:gc
输出每次GC的相关情况。
-verbose:jni
输出native方法调用的相关情况，一般用于诊断jni调用错误信息。
-version
输出java的版本信息，比如jdk版本、vendor、model。
-version:release
指定class或者jar运行时需要的jdk版本信息；若指定版本未找到，则以能找到的系统默认jdk版本执行；一般情况下，对于jar文件，可以在manifest文件中指定需要的版本信息，而不是在命令行。
release中可以指定单个版本，也可以指定一个列表，中间用空格隔开，且支持复杂组合，比如：
-version:"1.5.0_04 1.5*&1.5.1_02+"
指定class或者jar需要jdk版本为1.5.0_04或者是1.5系列中比1.5.1_02更高的所有版本。

-showversion
输出java版本信息（与-version相同）之后，继续输出java的标准参数列表及其描述。
-?
-help
输出java标准参数列表及其描述。
-X
输出非标准的参数列表及其描述。

以上的这些参数我们经常会在很多情况下用到多个的组合，比如我们在用JProfiler进行跟踪监控时，需要在被监控java启动参数中加上如下配置：
-agentlib:jprofilerti=port=8849 -Xbootclasspath/a:/usr/local/jprofiler5/bin/agent.jar
其中就用到两个-agentlib和-X参数，bootclasspath参数的详细信息将会在非标准参数中详细说明

堆大小设置

JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。

典型设置：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m：
    设置JVM最大可用内存为3550M。
-Xms3550m：
    设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g：
    设置年轻代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss128k：
    设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在 3000~5000左右。

java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:
    设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4：
    设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:
    设置持久代大小为16m。
-XX:MaxTenuringThreshold=0：
    设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

回收器选择

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

1.吞吐量优先的并行收集器

如上文所述，并行收集器主要以到达一定的吞吐量为目标，适用于科科学技术和后台处理等。
典型配置：
java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:
    +UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。
-XX:
    ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:
    +UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100
-XX:
    MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
-XX:
    +UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。

2.响应时间优先的并发收集器

如上文所述，并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。
典型配置：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:
    +UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。
-XX:
    +UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:
    +UseCMSCompactAtFullCollection
-XX:
    CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:
    +UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片

辅助信息

JVM提供了大量命令行参数，打印信息，供调试使用。主要有以下一些：
-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 -XX:+PrintGC：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前后的详细堆栈信息
-Xloggc:filename:
    与上面几个配合使用，把相关日志信息记录到文件以便分析。

常见配置汇总

堆设置
    -Xms:初始堆大小
    -Xmx:最大堆大小
    -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:+UseSerialGC:设置串行收集器
    -XX:+UseParallelGC:设置并行收集器
    -XX:+UseParalledlOldGC:设置并行年老代收集器
    -XX:+UseConcMarkSweepGC:设置并发收集器
垃圾回收统计信息
    -XX:+PrintGC
    -XX:+PrintGCDetails
    -XX:+PrintGCTimeStamps
    -Xloggc:filename
并行收集器设置
    -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
    -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
    -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
并发收集器设置
    -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
    -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

调优总结

年轻代大小选择
响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
年老代大小选择
响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：
    并发垃圾收集信息
    持久代并发收集次数
    传统GC信息
    花在年轻代和年老代回收上的时间比例
    减少年轻代和年老代花费的时间，一般会提高应用的效率
吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：
    -XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
    -XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩

      作者：江南白衣，最新版链接：http://blog.csdn.net/calvinxiu/archive/2007/05/18/1614473.aspx，版权所有，转载请保留原文链接。

      原本想把题目更简单的定为--《不要停》的，但还是自己YY一下就算了。
      Java开发Server最大的障碍，就是JDK1.4版之前的的串行垃圾收集机制会引起长时间的服务暂停，明白原理后，想想那些用JDK1.3写Server的先辈，不得不后怕。
     好在JDK1.4已开始支持多线程并行的后台垃圾收集算法，JDK5.0则优化了默认值的设置。

一、参考资料：

1. Tuning Garbage Collection with the 5.0 Java Virtual Machine 官方指南。
2. Hotspot memory management whitepaper 官方白皮书。
3. Java Tuning White Paper 官方文档。
4. FAQ about Garbage Collection in the Hotspot  官方FAQ，JVM1.4.2。
5. Java HotSpot 虚拟机中的垃圾收集 JavaOne2004上的中文ppt
6. A Collection of JVM Options JVM选项的超完整收集。

二、基本概念

1、堆(Heap)

JVM管理的内存叫堆。在32Bit操作系统上有1.5G-2G的限制，而64Bit的就没有。

JVM初始分配的内存由-Xms指定，默认是物理内存的1/64但小于1G。

JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4但小于1G。

默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制，可以由-XX:MinHeapFreeRatio=指定。
默认空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制，可以由-XX:MaxHeapFreeRatio=指定。

服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小，所以上面的两个参数没啥用。 

2.基本收集算法

1. 复制：将堆内分成两个相同空间，从根(ThreadLocal的对象，静态对象）开始访问每一个关联的活跃对象，将空间A的活跃对象全部复制到空间B，然后一次性回收整个空间A。
   因为只访问活跃对象，将所有活动对象复制走之后就清空整个空间，不用去访问死对象，所以遍历空间的成本较小，但需要巨大的复制成本和较多的内存。
2. 标记清除(mark-sweep)：收集器先从根开始访问所有活跃对象，标记为活跃对象。然后再遍历一次整个内存区域，把所有没有标记活跃的对象进行回收处理。该算法遍历整个空间的成本较大暂停时间随空间大小线性增大，而且整理后堆里的碎片很多。
3. 标记整理(mark-sweep-compact)：综合了上述两者的做法和优点，先标记活跃对象，然后将其合并成较大的内存块。

    可见，没有免费的午餐，无论采用复制还是标记清除算法，自动的东西都要付出很大的性能代价。

3.分代

    分代是Java垃圾收集的一大亮点，根据对象的生命周期长短，把堆分为3个代：Young，Old和Permanent，根据不同代的特点采用不同的收集算法，扬长避短也。

Young(Nursery)，年轻代。研究表明大部分对象都是朝生暮死，随生随灭的。因此所有收集器都为年轻代选择了复制算法。
    复制算法优点是只访问活跃对象，缺点是复制成本高。因为年轻代只有少量的对象能熬到垃圾收集，因此只需少量的复制成本。而且复制收集器只访问活跃对象，对那些占了最大比率的死对象视而不见，充分发挥了它遍历空间成本低的优点。

    Young的默认值为4M，随堆内存增大，约为1/15，JVM会根据情况动态管理其大小变化。
    -XX:NewRatio= 参数可以设置Young与Old的大小比例，-server时默认为1:2，但实际上young启动时远低于这个比率？如果信不过JVM，也可以用-Xmn硬性规定其大小，有文档推荐设为Heap总大小的1/4。

    Young的大小非常非常重要，见“后面暂停时间优先收集器”的论述。

    Young里面又分为3个区域，一个Eden，所有新建对象都会存在于该区，两个Survivor区，用来实施复制算法。每次复制就是将Eden和第一块 Survior的活对象复制到第2块，然后清空Eden与第一块Survior。Eden与Survivor的比例由 -XX:SurvivorRatio=设置，默认为32。Survivio大了会浪费，小了的话，会使一些年轻对象潜逃到老人区，引起老人区的不安，但这 个参数对性能并不重要。 

Old(Tenured)，年老代。年轻代的对象如果能够挺过数次收集，就会进入老人区。老人区使用标记整理算 法。因为老人区的对象都没那么容易死的，采用复制算法就要反复的复制对象，很不合算，只好采用标记清理算法，但标记清理算法其实也不轻松，每次都要遍历区 域内所有对象，所以还是没有免费的午餐啊。

-XX:MaxTenuringThreshold=设置熬过年轻代多少次收集后移入老人区，CMS中默认为0，熬过第一次GC就转入，可以用-XX:+PrintTenuringDistribution查看。

Permanent，持久代。装载Class信息等基础数据，默认64M，如果是类很多很多的服务程序，需要加 大其设置-XX:MaxPermSize=，否则它满了之后会引起fullgc()或Out of Memory。 注意Spring，Hibernate这类喜欢AOP动态生成类的框架需要更多的持久代内存。

4.minor/major collection

    每个代满了之后都会促发collection，（另外Concurrent Low Pause Collector默认在老人区68%的时候促发)。GC用较高的频率对young进行扫描和回收，这种叫做minor collection。
而因为成本关系对Old的检查回收频率要低很多，同时对Young和Old的收集称为major collection。
    System.gc()会引发major collection，使用-XX:+DisableExplicitGC禁止它，或设为CMS并发-XX:+ExplicitGCInvokesConcurrent。

5.小结

Young -- minor collection -- 复制算法

Old(Tenured) -- major colletion -- 标记清除/标记整理算法

三、收集器

1.古老的串行收集器(Serial Collector)

    使用 -XX:+UseSerialGC，策略为年轻代串行复制，年老代串行标记整理。

2.吞吐量优先的并行收集器(Throughput Collector)

    使用 -XX:+UseParallelGC ，也是JDK5 -server的默认值。策略为：
    1.年轻代暂停应用程序，多个垃圾收集线程并行的复制收集，线程数默认为CPU个数，CPU很多时，可用–XX:ParallelGCThreads=减少线程数。
    2.年老代暂停应用程序，与串行收集器一样，单垃圾收集线程标记整理。

    所以需要2+的CPU时才会优于串行收集器，适用于后台处理，科学计算。

    可以使用-XX:MaxGCPauseMillis= 和 -XX:GCTimeRatio 来调整GC的时间。

3.暂停时间优先的并发收集器(Concurrent Low Pause Collector-CMS)

    前面说了这么多，都是为了这节做铺垫......

    使用-XX:+UseConcMarkSweepGC，策略为：
    1.年轻代同样是暂停应用程序，多个垃圾收集线程并行的复制收集。
    2.年老代则只有两次短暂停，其他时间应用程序与收集线程并发的清除。

3.1 年老代详述

    并行(Parallel)与并发(Concurrent)仅一字之差，并行指多条垃圾收集线程并行，并发指用户线程与垃圾收集线程并发，程序在继续运行，而垃圾收集程序运行于另一个个CPU上。

    并发收集一开始会很短暂的停止一次所有线程来开始初始标记根对象，然后标记线程与应用线程一起并发运行，最后又很短的暂停一次，多线程并行的重新标记之前可能因为并发而漏掉的对象，然后就开始与应用程序并发的清除过程。可见，最长的两个遍历过程都是与应用程序并发执行的，比以前的串行算法改进太多太多了！！！

    串行标记清除是等年老代满了再开始收集的，而并发收集因为要与应用程序一起运行，如果满了才收集，应用程序就无内存可用，所以系统默认68%满的时候就开 始收集。内存已设得较大，吃内存又没有这么快的时候，可以用-XX:CMSInitiatingOccupancyFraction=恰当增大该比率。

3.2 年轻代详述

   可惜对年轻代的复制收集，依然必须停止所有应用程序线程，原理如此，只能靠多CPU，多收集线程并发来提高收集速度，但除非你的Server 独占整台服务器，否则如果服务器上本身还有很多其他线程时，切换起来速度就..... 所以，搞到最后，暂停时间的瓶颈就落在了年轻代的复制算法上。

    因此Young的大小设置挺重要的，大点就不用频繁GC，而且增大GC的间隔后，可以让多点对象自己死掉而不用复制了。但Young增大时，GC造成的停 顿时间攀升得非常恐怖，比如在我的机器上，默认8M的Young，只需要几毫秒的时间，64M就升到90毫秒，而升到256M时，就要到300毫秒了，峰 值还会攀到恐怖的800ms。谁叫复制算法，要等Young满了才开始收集，开始收集就要停止所有线程呢。

3.3 持久代

可设置-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled，使CMS收集持久代的类，而不是fullgc，netbeans5.5 performance文档的推荐。

4.增量(train算法)收集器(Incremental Collector)

已停止维护，–Xincgc选项默认转为并发收集器。

四、暂停时间显示

 加入下列参数 (请将PrintGC和Details中间的空格去掉，CSDN很怪的认为是禁止字句） 

-verbose:gc -XX:+PrintGC Details  -XX:+PrintGCTimeStamps

会程序运行过程中将显示如下输出

 9.211: [GC 9.211: [ParNew: 7994K->0K(8128K), 0.0123935 secs] 427172K->419977K(524224K), 0.0125728 secs]

 显示在程序运行的9.211秒发生了Minor的垃圾收集，前一段数据针对新生区，从7994k整理为0k，新生区总大小为8128k，程序暂停了12ms，而后一段数据针对整个堆。

对于年老代的收集，暂停发生在下面两个阶段，CMS-remark的中断是17毫秒：

[GC [1 CMS-initial-mark: 80168K(196608K)] 81144K(261184K), 0.0059036 secs] 

[1 CMS-remark: 80168K(196608K)] 82493K(261184K),0.0168943 secs]

再加两个参数 -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime对暂停时间看得更清晰。

五、真正不停的BEA JRockit 与Sun RTS2.0

   Bea的JRockit 5.0 R27 的特色之一是动态决定的垃圾收集策略，用户可以决定自己关心的是吞吐量，暂停时间还是确定的暂停时间，再由JVM在运行时动态决定、改变改变垃圾收集策略。
   
   它的Deterministic GC的选项是-Xgcprio: deterministic，号称可以把暂停可以控制在10-30毫秒，非常的牛，一句Deterministic道尽了RealTime的真谛。 不过细看一下文档，30ms的测试环境是1 GB heap 和 平均  30% 的活跃对象(也就是300M)活动对象，2 个 Xeon 3.6 GHz  4G内存 ，或者是4 个Xeon 2.0 GHz，8G内存。

  最可惜JRockt的license很奇怪，虽然平时使用免费，但这个30ms的选项就需要购买整个Weblogic Real Time Server的license。 

  其他免费选项，有：

• -Xgcprio:pausetime -Xpausetarget=210ms 
    因为免费，所以最低只能设置到200ms pause target。 200ms是Sun认为Real-Time的分界线。
• -Xgc:gencon
  普通的并发做法，效率也不错。

  JavaOne2007上有Sun的 Java Real-Time System 2.0 的介绍，RTS2.0基于JDK1.5，在Real-Time  Garbage Collctor上又有改进，但还在beta版状态，只供给OEM，更怪。

六、JDK 6.0的改进

因为JDK5.0在Young较大时的表现还是不够让人满意，又继续看JDK6.0的改进，结果稍稍失望，不涉及我最头痛的年轻代复制收集改良。

1.年老代的标识-清除收集，并行执行标识
  JDK5.0只开了一条收集进程与应用线程并发标识，而6.0可以开多条收集线程来做标识，缩短标识老人区所有活动对象的时间。

2.加大了Young区的默认大小
默认大小从4M加到16M，从堆内存的1/15增加到1/7

3.System.gc()可以与应用程序并发执行
使用-XX:+ExplicitGCInvokesConcurrent 设置

七、小结

1. JDK5.0/6.0

对于服务器应用，我们使用Concurrent Low Pause Collector，对年轻代，暂停时多线程并行复制收集；对年老代，收集器与应用程序并行标记--整理收集，以达到尽量短的垃圾收集时间。

本着没有深刻测试前不要胡乱优化的宗旨，命令行属性只需简单写为：

然后要根据应用的情况，在测试软件辅助可以下看看有没有JVM的默认值和自动管理做的不够的地方可以调整，如-xmn 设Young的大小，-XX:MaxPermSize设持久代大小等。

2. JRockit 6.0 R27.2

但因为JDK5的测试结果实在不能满意，后来又尝试了JRockit，总体效果要好些。
 JRockit的特点是动态垃圾收集器是根据用户关心的特征动态决定收集算法的，参数如下

来自：wangyuanzju.blog.163.com