JVM体系结构

部分转载部分原创！

Java虚拟机（Java VirtualMachine，JVM）是软件模拟的计算机，它可以在任何处理器上（无论是在计算机中还是在其他电子设备中）安全兼容地执行保存在.class文件中的字节码。Java虚拟机的“机器码”保存在.class文件中，有时也可以称之为字节码文件。

Java程序的跨平台特性主要是指字节码文件可以在任何具有Java虚拟机的计算机或者电子设备上运行，Java虚拟机中的Java解释器负责将字节码文件解释成为特定的机器码进行运行。因此在运行时，Java源程序需要通过编译器编译成为.class文件。

JVM工作原理:

1.创建JVM装载环境和配置

2.装载JVM.dll

3.初始化JVM.dll并挂界到JNIENV(JNI调用接口)实例

4.调用JNIEnv实例装载并处理class类。

一．JVM装入环境，JVM提供的方式是操作系统的动态连接文件．

既然是文件那就一个装入路径的问题，Java是怎么找这个路径的呢？当你在调用Javatest的时候，操作系统会在path下在你的Java.exe程序，Java.exe就通过下面一个过程来确定JVM的路径和相关的参数配置了．下面基于Windows的实现的分析．

首先查找jre路径，Java是通过GetApplicationHomeapi来获得当前的Java.exe绝对路径，c:\j2sdk1.4.2_09\bin\Java.exe,那么它会截取到绝对路径c:\j2sdk1.4.2_09\，判断c:\j2sdk1.4.2_09\bin\Java.dll文件是否存在，如果存在就把c:\j2sdk1.4.2_09\作为jre路径，如果不存在则判断c:\j2sdk1.4.2_09\jre\bin\Java.dll是否存在，如果存在这c:\j2sdk1.4.2_09\jre作为jre路径．如果不存在调用GetPublicJREHome查HKEY_LOCAL_MACHINE\Software\JavaSoft\JavaRuntime Environment\“当前JRE版本号”\JavaHome的路径为jre路径。

然后装载JVM.cfg文件JRE路径+\lib+\ARCH（CPU构架）+\JVM.cfgARCH（CPU构架）的判断是通过Java_md.c中GetArch函数判断的，该函数中windows平台只有两种情况：WIN64的‘ia64’，其他情况都为‘i386’。以我的为例：C:\j2sdk1.4.2_09\jre\lib\i386\JVM.cfg.主要的内容如下：

-client KNOWN   

-server KNOWN   

-hotspot ALIASED_TO -client  

-classic WARN   

-native ERROR   

-green ERROR  

在我们的jdk目录中jre\bin\server和jre\bin\client都有JVM.dll文件存在，而Java正是通过JVM.cfg配置文件来管理这些不同版本的JVM.dll的．通过文件我们可以定义目前jdk中支持那些JVM,前面部分（client）是JVM名称，后面是参数，KNOWN表示JVM存在，ALIASED_TO表示给别的JVM取一个别名，WARN表示不存在时找一个JVM替代，ERROR表示不存在抛出异常．在运行JavaXXX是，Java.exe会通过CheckJVMType来检查当前的JVM类型，Java可以通过两种参数的方式来指定具体的JVM类型，一种按照JVM.cfg文件中的JVM名称指定，第二种方法是直接指定，它们执行的方法分别是“Java-J”、“Java-XXaltJVM=”或“Java -J-XXaltJVM=”。如果是第一种参数传递方式，CheckJVMType函数会取参数‘-J’后面的JVM名称，然后从已知的JVM配置参数中查找如果找到同名的则去掉该JVM名称前的‘-’直接返回该值；而第二种方法，会直接返回“-XXaltJVM=”或“-J-XXaltJVM=”后面的JVM类型名称；如果在运行Java时未指定上面两种方法中的任一一种参数，CheckJVMType会取配置文件中第一个配置中的JVM名称，去掉名称前面的‘-’返回该值。CheckJVMType函数的这个返回值会在下面的函数中汇同jre路径组合成JVM.dll的绝对路径。如果没有指定这会使用JVM.cfg中第一个定义的JVM.可以通过set_Java_LAUNCHER_DEBUG=1在控制台上测试．

最后获得JVM.dll的路径，JRE路径+\bin+\JVM类型字符串+\JVM.dll就是JVM的文件路径了，但是如果在调用Java程序时用-XXaltJVM=参数指定的路径path,就直接用path+\JVM.dll文件做为JVM.dll的文件路径．

二：装载JVM.dll

通过第一步已经找到了JVM的路径，Java通过LoadJavaVM来装入JVM.dll文件．装入工作很简单就是调用WindowsAPI函数：

LoadLibrary装载JVM.dll动态连接库．然后把JVM.dll中的导出函数JNI_CreateJavaVM和JNI_GetDefaultJavaVMInitArgs挂接到InvocationFunctions变量的CreateJavaVM和GetDefaultJavaVMInitArgs函数指针变量上。JVM.dll的装载工作宣告完成。

三：初始化JVM，获得本地调用接口

这样就可以在Java中调用JVM的函数了．调用InvocationFunctions－>CreateJavaVM也就是JVM中JNI_CreateJavaVM方法获得JNIEnv结构的实例．

四：运行Java程序．

Java程序有两种方式一种是jar包，一种是class.运行jar,Java-jar XXX.jar运行的时候，Java.exe调用GetMainClassName函数，该函数先获得JNIEnv实例然后调用Java类Java.util.jar.JarFileJNIEnv中方法getManifest()并从返回的Manifest对象中取getAttributes("Main-Class")的值即jar包中文件：META-INF/MANIFEST.MF指定的Main-Class的主类名作为运行的主类。之后main函数会调用Java.c中LoadClass方法装载该主类（使用JNIEnv实例的FindClass）。main函数直接调用Java.c中LoadClass方法装载该类。如果是执行class方法。main函数直接调用Java.c中LoadClass方法装载该类。

然后main函数调用JNIEnv实例的GetStaticMethodID方法查找装载的class主类中

“public static void main(String[] args)”方法，并判断该方法是否为public方法，然后调用JNIEnv实例的

CallStaticVoidMethod方法调用该Java类的main方法。 

 

JVM体系结构：

JVM的内部体系结构分为三部分，分别是：类装载器（ClassLoader）子系统，运行时数据区，和执行引擎。

1、类装载器

顾名思义，就是用来装载.class文件的。JVM的两种类装载器包括：启动类装载器和用户自定义类装载器，启动类装载器是JVM实现的一部分，用户自定义类装载器则是Java程序的一部分，必须是ClassLoader类的子类。（下面所述情况是针对SunJDK1.2）

动类装载器：只在系统类(JavaAPI的类文件)的安装路径查找要装入的类

用户自定义类装载器：

系统类装载器：在JVM启动时创建，用来在CLASSPATH目录下查找要装入的类其他用户自定义类装载器：这里有必要先说一下ClassLoader类的几个方法，了解它们对于了解自定义类装载器如何装载.class文件至关重要。

protectedfinalClassdefineClass(Stringname,bytedata[],intoffset,intlength) 

protectedfinalClassdefineClass(Stringname,bytedata[],intoffset,intlength,ProtectionDomainprotectionDomain);protectedfinalClassfindSystemClass(Stringname) 

protectedfinalvoidresolveClass(Classc) 

defineClass用来将二进制class文件（新类型）导入到方法区,也就是这里指的类是用户自定义的类（也就是负责装载类）

findSystemClass通过类型的全限定名，先通过系统类装载器或者启动类装载器来装载，并返回Class对象。

ResolveClass:让类装载器进行连接动作（包括验证，分配内存初始化，将类型中的符号引用解析为直接引用），这里涉及到Java命名空间的问题，JVM保证被一个类装载器装载的类所引用的所有类都被这个类装载器装载，同一个类装载器装载的类之间可以相互访问，但是不同类装载器装载的类看不见对方，从而实现了有效的屏蔽。

2、执行引擎：

它或者在执行字节码，或者执行本地方法

要说执行引擎，就不得不的指令集，每一条指令包含一个单字节的操作码，后面跟0个或者多个操作数。

（一）指令集以栈为设计中心，而非以寄存器为中心这种指令集设计如何满足Java体系的要求：

平台无关性：以栈为中心使得在只有很少register的机器上实现Java更便利compiler一般采用stack向连接优化器传递编译的中间结果，若指令集以stack为基础，则有利于运行时进行的优化工作与执行即时编译或者自适应优化的执行引擎结合，通俗的说就是使编译和运行用的数据结构统一，更有利于优化的开展。

网络移动性：class文件的紧凑性。

安全性：指令集中绝大部分操作码都指明了操作的类型。（在装载的时候使用数据流分析期进行一次性验证，而非在执行每条指令的时候进行验证，有利于提高执行速度）。

（二）执行技术

主要的执行技术有:解释，即时编译，自适应优化、芯片级直接执行其中解释属于第一代JVM，即时编译JIT属于第二代JVM，自适应优化（目前Sun的HotspotJVM采用这种技术）则吸取第一代JVM和第二代JVM的经验，采用两者结合的方式

自适应优化：开始对所有的代码都采取解释执行的方式，并监视代码执行情况，然后对那些经常调用的方法启动一个后台线程，将其编译为本地代码，并进行仔细优化。若方法不再频繁使用，则取消编译过的代码，仍对其进行解释执行。

3、运行时数据区：

主要包括：方法区，堆，Java栈，PC寄存器，本地方法栈

方法区

（1）方法区和堆由所有线程共享

堆：存放所有程序在运行时创建的对象

方法区：当JVM的类装载器加载.class文件，并进行解析，把解析的类型信息放入方法区。

（2）Java栈和PC寄存器由线程独享，在新线程创建时间里

（3）本地方法栈：存储本地方法调用的状态

上边总体介绍了运行时数据区的主要内容，下边进行详细介绍，要介绍数据区，就不得不说明JVM中的数据类型。

JVM中的数据类型：JVM中基本的数据单元是word,而word的长度由JVM具体的实现者来决定

数据类型包括基本类型和引用类型，

（1）基本类型包括：数值类型(包括除boolean外的所有的Java基本数据类型)，boolean（在JVM中使用int来表示，0表示false，其他int值均表示true）和returnAddress（JVM的内部类型，用来实现finally子句）。

（2）引用类型包括：数组类型，类类型，接口类型

前边讲述了JVM中数据的表示，下面让我们输入到JVM的数据区

首先来看方法区：

上边已经提到，方法区主要用来存储JVM从class文件中提取的类型信息，那么类型信息是如何存储的呢？众所周知，Java使用的是大端序（big?endian:即低字节的数据存储在高位内存上，如对于1234，12是高位数据，34为低位数据，则Java中的存储格式应该为12存在内存的低地址，34存在内存的高地址，x86中的存储格式与之相反）来存储数据，这实际上是在class文件中数据的存储格式，但是当数据倒入到方法区中时，JVM可以以任何方式来存储它。

类型信息：包括class的全限定名，class的直接父类，类类型还是接口类型，类的修饰符（public,等），所有直接父接口的列表，Class对象提供了访问这些信息的窗口（可通过Class.forName(“”)或instance.getClass()获得），下面是Class的方法，相信大家看了会恍然大悟，（原来如此J）

getName(),getSuperClass(),isInterface(),getInterfaces(),getClassLoader();

static变量作为类型信息的一部分保存

指向ClassLoader类的引用：在动态连接时装载该类中引用的其他类

指向Class类的引用：必然的，上边已述

该类型的常量池：包括直接常量（String，integer和floatpoint常量）以及对其他类型、字段和方法的符号引用（注意：这里的常量池并不是普通意义上的存储常量的地方，这些符号引用可能是我们在编程中所接触到的变量），由于这些符号引用，使得常量池成为Java程序动态连接中至关重要的部分

字段信息：普通意义上的类型中声明的字段

方法信息：类型中各个方法的信息

编译期常量：指用final声明或者用编译时已知的值初始化的类变量

class将所有的常量复制至其常量池或者其字节码流中。

方法表：一个数组，包括所有它的实例可能调用的实例方法的直接引用（包括从父类中继承来的）

除此之外，若某个类不是抽象和本地的，还要保存方法的字节码，操作数栈和该方法的栈帧，异常表。

举例：

classLava{ 

privateintspeed=5; 

voidflow(){} 

classVolcano{ 

publicstaticvoidmain(String[]args){ 

Lavalava=newLava(); 

lava.flow(); 

} 

} 

运行命令JavaVolcano;

（1）JVM找到Volcano.class倒入，并提取相应的类型信息到方法区。通过执行方法区中的字节码，JVM执行main（）方法，（执行时会一直保存指向Vocano类的常量池的指针）

（2）Main（）中第一条指令告诉JVM需为列在常量池第一项的类分配内存（此处再次说明了常量池并非只存储常量信息），然后JVM找到常量池的第一项，发现是对Lava类的上海水力控制阀符号引用，则检查方法区，看Lava类是否装载，结果是还未装载，则查找“Lava.class”,将类型信息写入方法区，并将方法区Lava类信息的指针来替换Volcano原常量池中的符号引用，即用直接引用来替换符号引用。

（3）JVM看到new关键字，准备为Lava分配内存，根据Volcano的常量池的第一项找到Lava在方法区的位置，并分析需要多少对空间，确定后，在堆上分配空间，并将speed变量初始为0，并将lava对象的引用压到栈中

（4）调用lava的flow（）方法

好了，大致了解了方法区的内容后，让我们来看看堆

Java对象的堆实现

Java对象主要由实例变量（包括自己所属的类和其父类声明的）以及指向方法区中类数据的指针，指向方法表的指针，对象锁（非必需），等待集合（非必需），GC相关的数据（非必需）（主要视GC算法而定，如对于标记并清除算法，需要标记对象是否被引用，以及是否已调用finalize（）方法）。

那么为什么Java对象中要有指向类数据的指针呢？我们从几个方面来考虑

首先：当程序中将一个对象引用转为另一个类型时，如何检查转换是否允许？需用到类数据

其次：动态绑定时，并不是需要引用类型，而是需要运行时类型，

这里的迷惑是：为什么类数据中保存的是实际类型，而非引用类型？这个问题先留下来，我想在后续的读书笔记中应该能明白

指向方法表的指针：这里和C++的VTBL是类似的，有利于提高方法调用的效率

对象锁：用来实现多个线程对共享数据的互斥访问

等待集合：用来让多个线程为完成共同目标而协调功过。（注意Object类中的wait(),notify(),notifyAll()方法）。

Java数组的堆实现：数组也拥有一个和他们的类相关联的Class实例，具有相同dimension和type的数组是同一个类的实例。数组类名的表示：如[[LJava/lang/Object表示Object[][]，[I表示int[]，[[[B表示byte[][][]

至此，堆已大致介绍完毕，下面来介绍程序计数器和Java栈

程序计数器：为每个线程独有，在线程启动时创建，

若thread执行Java方法，则PC保存下一条执行指令的地址。

若thread执行native方法，则Pc的值为undefined

Java栈

Java栈以帧为单位保存线程的运行状态，Java栈只有两种操作，帧的压栈和出栈。

每个帧代表一个方法，Java方法有两种返回方式，return和抛出异常，两种方式都会导致该方法对应的帧出栈和释放内存。

帧的组成：局部变量区（包括方法参数和局部变量，对于instance方法，还要首先保存this类型，其中方法参数按照声明顺序严格放置，局部变量可以任意放置），操作数栈，帧数据区（用来帮助支持常量池的解析，正常方法返回和异常处理）。

本地方法栈：依赖于本地方法的实现，如某个JVM实现的本地方法借口使用C连接模型，则本地方法栈就是C栈，可以说某线程在调用本地方法时，就进入了一个不受JVM限制的领域，也就是JVM可以利用本地方法来动态扩展本身。

JAVA的垃圾回收

基本回收算法

1.    引用计数（ReferenceCounting）
比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。

2.    标记-清除（Mark-Sweep）
此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。

3.    复制（Copying）
此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。次算法每次只处理 正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不过出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。

4.    标记-整理（Mark-Compact）
此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。

5.    增量收集（IncrementalCollecting）
实施垃圾回收算法，即：在应用进行的同时进行垃圾回收。不知道什么原因JDK5.0中的收集器没有使用这种算法的。

6.    分代（GenerationalCollecting）
基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。现在的垃圾回收器（从J2SE1.2开始）都是使用此算法的。

分代垃圾回收详述

如上图所示，为Java堆中的各代分布。

1.    Young（年轻代）
年轻代分三个区。一个Eden区，两个Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。

2.    Tenured（年老代）
年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。

3.    Perm（持久代）
用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=进行设置。

垃圾回收（GC）类型

GC有两种类型：Scavenge GC和Full GC。

1.    Scavenge GC
一般情况下，当新对象生成，并且在Eden申请空间失败时，就好触发ScavengeGC，堆Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。

2.    Full GC
对整个堆进行整理，包括Young、Tenured和Perm。FullGC比ScavengeGC要慢，因此应该尽可能减少FullGC。有如下原因可能导致FullGC：

·        Tenured被写满

·        Perm域被写满

·        System.gc()被显示调用

·        上一次GC之后Heap的各域分配策略动态变化
分代垃圾回收过程演示

垃圾回收器

目前的收集器主要有三种：串行收集器、并行收集器、并发收集器。

串行收集器

使用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高。但是，也无法使用多处理器的优势，所以此收集器适合单处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的多处理器机器上。可以使用-XX:+UseSerialGC打开。

并行收集器

对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用。使用-XX:+UseParallelGC.打开。并行收集器在J2SE5.0第六6更新上引入，在Java SE6.0中进行了增强--可以堆年老代进行并行收集。如果年老代不使用并发收集的话，是使用单线程进行垃圾回收，因此会制约扩展能力。使用-XX:+UseParallelOldGC打开。

1. 使用-XX:ParallelGCThreads=设置并行垃圾回收的线程数。此值可以设置与机器处理器数量相等。

2. 此收集器可以进行如下配置：

§ 最大垃圾回收暂停:指定垃圾回收时的最长暂停时间，通过-XX:MaxGCPauseMillis=指定。为毫秒.如果指定了此值的话，堆大小和垃圾回收相关参数会进行调整以达到指定值。设定此值可能会减少应用的吞吐量。

§ 吞吐量:吞吐量为垃圾回收时间与非垃圾回收时间的比值，通过-XX:GCTimeRatio=来设定，公式为1/（1+N）。例如，-XX:GCTimeRatio=19时，表示5%的时间用于垃圾回收。默认情况为99，即1%的时间用于垃圾回收。

并发收集器

可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用。使用-XX:+UseConcMarkSweepGC打开。

1.  并 发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对象。在每个年老代垃圾回收周期中，在收集初期并发收集器会 对整个应用进行简短的暂停，在收集中还会再暂停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。

2.  并发收集器使用处理器换来短暂的停顿时间。在一个N个处理器的系统上，并发收集部分使用K/N个可用处理器进行回收，一般情况下1<=K<=N/4。

3.  在只有一个处理器的主机上使用并发收集器，设置为incremental mode模式也可获得较短的停顿时间。

4.  浮动垃圾：由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就造成了“Floating Garbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的预留空间用于这些浮动垃圾。

5.  ConcurrentMode Failure：并发收集器在应用运行时进行收集，所以需要保证堆在垃圾回收的这段时间有足够的空间供程序使用，否则，垃圾回收还未完成，堆空间先满了。这种情况下将会发生“并发模式失败”，此时整个应用将会暂停，进行垃圾回收。

6.  启动并发收集器：因为并发收集在应用运行时进行收集，所以必须保证收集完成之前有足够的内存空间供程序使用，否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=指定还有多少剩余堆时开始执行并发收集

小结

o   串行处理器：
 --适用情况：数据量比较小（100M左右）；单处理器下并且对响应时间无要求的应用。
 --缺点：只能用于小型应用

o   并行处理器：
 --适用情况：“对吞吐量有高要求”，多CPU、对应用响应时间无要求的中、大型应用。举例：后台处理、科学计算。
 --缺点：应用响应时间可能较长

o   并发处理器：
 --适用情况：“对响应时间有高要求”，多CPU、对应用响应时间有较高要求的中、大型应用。举例：Web服务器/应用服务器、电信交换、集成开发环境。

常见配置举例

1.    堆大小设置
JVM中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在WindowsServer 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区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

2.    回收器选择
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：打开对年老代的压缩。可能会影响性能，但是可以消除碎片

3.    辅助信息
JVM提供了大量命令行参数，打印信息，供调试使用。主要有以下一些：

·        -XX:+PrintGC
输出形式：[GC118250K->113543K(130112K), 0.0094143 secs]

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

·        -XX:+Printetails
输出形式：[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:打印每次垃圾回收前，程序未中断的执行时间。可与上面混合使用
输出形式：Applicationtime: 0.5291524 seconds

·        -XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂停的时间。可与上面混合使用
输出形式：Totaltime 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:与上面几个配合使用，把相关日志信息记录到文件以便分析。

常见配置汇总

1.    堆设置

·        -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:设置持久代大小

2.    收集器设置

·        -XX:+UseSerialGC:设置串行收集器

·        -XX:+UseParallelGC:设置并行收集器

·        -XX:+UseParalledlOldGC:设置并行年老代收集器

·        -XX:+UseConcMarkSweepGC:设置并发收集器

3.    垃圾回收统计信息

·        -XX:+PrintGC

·        -XX:+Printetails

·        -XX:+PrintGCTimeStamps

·        -Xloggc:filename

4.    并行收集器设置

·        -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。

·        -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间

·        -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

5.    并发收集器设置

·        -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。

·        -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

系统调优

调优步骤：衡量系统现状、设定调优目标、寻找性能瓶颈、性能调优、衡量是否到达目标(如果未到达目标，需重新寻找性能瓶颈）、性能调优结束。

性能瓶颈的表象：资源消耗过多、外部处理系统的性能不足、资源消耗不多但程序的响应速度却仍达不到要求。

资源消耗：CPU、文件IO、网络IO、内存。

外部处理系统的性能不足：所调用的其他系统提供的功能或数据库操作的响应速度不够。
资源消耗不多但程序的响应速度却仍达不到要求：程序代码运行效率不够高、未充分使用资源、程序结构不合理。

CPU

CPU消耗：

CPU主要用于中断、内核、用户进程的任务处理，优先级为中断>内核>用户进程。

上下文切换：

每个线程分配一定的执行时间，当到达执行时间、线程中有IO阻塞或高优先级线程要执行时，将切换执行的线程。在切换时要存储目前线程的执行状态，并恢复要执行的线程的状态。对于Java应用，典型的是在进行文件IO操作、网络IO操作、锁等待、线程Sleep时，当前线程会进入阻塞或休眠状态，从而触发上下文切换，上下文切换过多会造成内核占据较多的CPU的使用。

运行队列：

每个CPU核都维护一个可运行的线程队列。系统的load主要由CPU的运行队列来决定。
运行队列值越大，就意味着线程会要消耗越长的时间才能执行完成。

利用率：

CPU在用户进程、内核、中断处理、IO等待、空闲，这五个部分使用百分比。

CPU消耗严重的解决方法

 CPU us高的解决方法：

CPU us 高的原因主要是执行线程不需要任何挂起动作，且一直执行，导致CPU没有机会去调度执行其他的线程。

调优方案： 增加Thread.sleep，以释放CPU的执行权，降低CPU的消耗。以损失单次执行性能为代价的，但由于其降低了CPU的消耗，对于多线程的应用而言，反而提高了总体的平均性能。

（在实际的Java应用中类似场景， 对于这种场景最佳方式是改为采用wait/notify机制）

对于其他类似循环次数过多、正则、计算等造成CPU us过高的状况，则需要结合业务调优。

对于GC频繁，则需要通过JVM调优或程序调优，降低GC的执行次数。

 CPU sy高的解决方法：

CPU sy 高的原因主要是线程的运行状态要经常切换，对于这种情况，常见的一种优化方法是减少线程数。

调优方案： 将线程数降低

这种调优过后有可能会造成CPU us过高，所以合理设置线程数非常关键。

资源消耗不多但程序执行慢的情况的解决方法 

降低锁竞争：锁竞争的状况会比较明显，这时候线程很容易处于等待锁的状况，从而导致性能下降以及CPUsy上升。

使用并发包中的类：大多数采用了lock-free、nonblocking算法。

使用Treiber算法：基于CAS以及AtomicReference。

使用Michael-Scott非阻塞队列算法：基于CAS以及AtomicReference，典型ConcurrentLindkedQueue。

（基于CAS和AtomicReference来实现无阻塞是不错的选择，但值得注意的是，lock-free算法需不断的循环比较来保证资源的一致性的，对于冲突较多的应用场景而言，会带来更高的CPU消耗，因此不一定采用CAS实现无阻塞的就一定比采用lock方式的性能好。还有一些无阻塞算法的改进：MCAS、WSTM等）

尽可能少用锁：尽可能只对需要控制的资源做加锁操作（通常没有必要对整个方法加锁，尽可能让锁最小化，只对互斥及原子操作的地方加锁，加锁时尽可能以保护资源的最小化粒度为单位--如只对需要保护的资源加锁而不是this）。

拆分锁：独占锁拆分为多把锁（读写锁拆分、类似ConcurrentHashMap中默认拆分为16把锁），很多程度上能提高读写的性能，但需要注意在采用拆分锁后，全局性质的操作会变得比较复杂（如ConcurrentHashMap中size操作）。（拆分锁太多也会造成副作用，如CPU消耗明显增加）

去除读写操作的互斥：在修改时加锁，并复制对象进行修改，修改完毕后切换对象的引用，从而读取时则不加锁。这种称为CopyOnWrite，CopyOnWriteArrayList是典型实现，好处是可以明显提升读的性能，适合读多写少的场景，但由于写操作每次都要复制一份对象，会消耗更多的内存。

IO

文件IO消耗分析

Linux在操作文件时，将数据放入文件缓存区，直到内存不够或系统要释放内存给用户进程使用。所以通常情况下只有写文件和第一次读取文件时会产生真正的文件IO。

对于Java应用，造成文件IO消耗高主要是多个线程需要进行大量内容写入（例如频繁的日志写入）的动作、磁盘设备本身的处理速度慢、文件系统慢、操作的文件本身已经很大。
网络IO消耗分析
对于分布式Java应用，网卡中断是不是均衡分配到各CPU(cat/proc/interrupts查看)。

对于Java分布式应用，还有一种典型现象是应用中有较多的网络IO操作和确实需要一些锁竞争机制（如数据库连接池），但为了能够支撑搞得并发量，可采用协程（Coroutine）来支撑更高的并发量，避免并发量上涨后造成CPUsy消耗严重、系统load迅速上涨和系统性能下降。

 程序执行慢原因分析

锁竞争激烈：很多线程竞争互斥资源，但资源有限， 造成其他线程都处于等待状态。

未充分使用硬件资源：线程操作被串行化。

数据量增长：单表数据量太大（如1个亿）造成数据库读写速度大幅下降（操作此表）。

在Java中实现协程的框架有Kilim，Kilim执行一项任务创建Task，使用Task的暂停机制，而不是Thread，Kilim承担了线程调度以及上下切换动作，Task相对于原生Thread而言就轻量级多了，且能更好利用CPU。Kilim带来的是线程使用率的提升，但同时由于要在JVM堆中保存Task上下文信息，因此在采用Kilim的情况下要消耗更多的内存。（目前JDK7中也有一个支持协程方式的实现，另外基于JVM的Scala的Actor也可用于在Java使用协程）

文件IO消耗严重的解决方法

从程序的角度而言，造成文件IO消耗严重的原因主要是多个线程在写进行大量的数据到同一文件，导致文件很快变得很大，从而写入速度越来越慢，并造成各线程激烈争抢文件锁。

 常用调优方法：

异步写文件

批量读写

限流

限制文件大小

 网络IO消耗严重的解决方法

从程序的角度而言，造成网络IO消耗严重的原因主要是同时需要发送或接收的包太多。

 常用调优方法：

限流，限流通常是限制发送packet的频率，从而在网络IO消耗可接受的情况下来发送packget。

内存

内存消耗分析（-Xms和-Xmx设为相同的值，避免运行期JVM堆内存要不断申请内存）
对于Java应用，内存的消耗主要在Java堆内存上，只有创建线程和使用DirectByteBuffer才会操作JVM堆外的内存。
JVM内存消耗过多会导致GC执行频繁，CPU消耗增加，应用线程的执行速度严重下降，甚至造成OutOfMemoryError，最终导致Java进程退出。

内存消耗严重的解决方法

释放不必要的引用：代码持有了不需要的对象引用，造成这些对象无法被GC，从而占据了JVM堆内存。（使用ThreadLocal：注意在线程内动作执行完毕时，需执行ThreadLocal.set把对象清除，避免持有不必要的对象引用）

使用对象缓存池：创建对象要消耗一定的CPU以及内存，使用对象缓存池一定程度上可降低JVM堆内存的使用。

采用合理的缓存失效算法：如果放入太多对象在缓存池中，反而会造成内存的严重消耗， 同时由于缓存池一直对这些对象持有引用，从而造成FullGC增多，对于这种状况要合理控制缓存池的大小，避免缓存池的对象数量无限上涨。（经典的缓存失效算法来清除缓存池中的对象：FIFO、LRU、LFU等）

合理使用SoftReference和WeekReference：SoftReference的对象会在内存不够用的时候回收，WeekReference的对象会在FullGC的时候回收。

JVM堆外的内存

代大小调优：避免新生代大小设置过小、避免新生代大小设置过大、避免Survivor设置过小或过大、合理设置新生代存活周期。

-Xmn 调整新生代大小，新生代越大通常也意味着更多对象会在minorGC阶段被回收，但可能有可能造成旧生代大小，造成频繁触发FullGC，甚至是OutOfMemoryError。

-XX:SurvivorRatio调整Eden区与Survivor区的大小，Eden区越大通常也意味着minorGC发生频率越低，但可能有可能造成Survivor区太小，导致对象minorGC后就直接进入旧生代，从而更频繁触发FullGC。

GC策略的调优：CMS GC多数动作是和应用并发进行的，确实可以减小GC动作给应用造成的暂停时间。对于Web应用非常需要一个对应用造成暂停时间短的GC，再加上Web应用的瓶颈都不在CPU上，在G1还不够成熟的情况下，CMSGC是不错的选择。（如果系统不是CPU密集型，且从新生代进入旧生代的大部分对象是可以回收的，那么采用CMSGC可以更好地在旧生代满之前完成对象的回收，更大程度降低FullGC发生的可能）

在调整了内存管理方面的参数后应通过-XX:PrintGCDetails、-XX:+PrintGCTimeStamps、-XX:+PrintGCApplicationStoppedTime以及jstat或visualvm等方式观察调整后的GC状况。

出内存管理以外的其他方面的调优参数：-XX:CompileThreshold、-XX:+UseFastAccessorMethods、-XX:+UseBaiasedLocking。

swap的消耗、物理内存的消耗、JVM内存的消耗。

1.    年轻代大小选择

·        响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。

·        吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

2.    年老代大小选择

·        响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：

·        并发垃圾收集信息

·        持久代并发收集次数

·        传统GC信息

·        花在年轻代和年老代回收上的时间比例

减少年轻代和年老代花费的时间，一般会提高应用的效率

·        吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。

3.    较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间 较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：

·        -XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。

·        -XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次FullGC后，对年老代进行压缩

充分利用CPU

在能并行处理的场景中未使用足够的线程（线程增加：CPU资源消耗可接受且不会带来激烈竞争锁的场景下），例如单线程的计算，可以拆分为多个线程分别计算，最后将结果合并，JDK 7中的fork-join框架。

Amdahl定律公式：1/(F+(1-F)/N)。 

充分利用内存

数据的缓存、耗时资源的缓存（数据库连接创建、网络连接的创建等）、页面片段的缓存。毕竟内存的读取肯定远快于硬盘、网络的读取，在内存消耗可接受、GC频率、以及系统结构（例如集群环境可能会带来缓存的同步）可接受情况下，应充分利用内存来缓存数据，提升系统的性能。

总结：

好的调优策略是收益比（调优后提升的效果/调优改动所需付出的代价）最高的，通常来说简单的系统调优比较好做，因此尽量保持单机上应用的纯粹性，这是大型系统的基本架构原则。

调优的三大有效原则：充分而不过分使用硬件资源、合理调整JVM、合理使用JDK包。

附录：JVM常用参数配置 

1:heap size 
a: -Xmx<n> 
指定 jvm 的最大 heap 大小, 如:-Xmx=2g 
b: -Xms<n> 
指定 jvm 的最小 heap 大小, 如 :-Xms=2g ， 高并发应用，建议和-Xmx一样， 防止因为内存收缩／突然增大带来的性能影响。 
c: -Xmn<n> 
指定 jvm 中 New Generation 的大小 , 如:-Xmn256m。 这个参数很影响性能， 如果你的程序需要比较多的临时内存， 建议设置到512M， 如果用的少，尽量降低这个数值， 一般来说128／256足以使用了。 

d: -XX:PermSize=<n> 
指定 jvm 中 Perm Generation 的最小值 , 如:-XX:PermSize=32m。 这个参数需要看你的实际情况，。 可以通过jmap 命令看看到底需要多少。 

e: -XX:MaxPermSize=<n> 
指定 PermGeneration 的最大值 , 如 :-XX:MaxPermSize=64m 

f: -Xss<n> 
指定线程桟大小 , 如 :-Xss128k，一般来说，webx框架下的应用需要256K。 如果你的程序有大规模的递归行为，请考虑设置到512K／1M。 这个需要全面的测试才能知道。 不过，256K已经很大了。 这个参数对性能的影响比较大的。 

g: -XX:NewRatio=<n> 
指定 jvm 中 Old Generation heap size 与 New Generation 的比例 , 在使用CMS GC 的情况下此参数失效 , 如 :-XX:NewRatio=2 

h: -XX:SurvivorRatio=<n> 
指 定 New Generation 中 Eden Space 与一个Survivor Space 的 heap size 比例 ,-XX:SurvivorRatio=8, 那么在总共 New Generation 为 10m 的情况下,Eden Space 为 8m 

i: -XX:MinHeapFreeRatio=<n> 
指定 jvm heap 在使用率小于 n 的情况下 ,heap 进行收缩,Xmx==Xms 的情况下无效 , 如 :-XX:MinHeapFreeRatio=30 

j: -XX:MaxHeapFreeRatio=<n> 
指定 jvm heap 在使用率大于 n 的情况下 ,heap 进行扩张,Xmx==Xms 的情况下无效 , 如 :-XX:MaxHeapFreeRatio=70 

k: -XX:LargePageSizeInBytes=<n> 
指定 Java heap 的分页页面大小 , 如 :-XX:LargePageSizeInBytes=128m 

2: garbage collector 

a: -XX:+UseParallelGC 
指 定在 New Generation 使用 parallel collector, 并行收集 , 暂停app threads, 同时启动多个垃圾回收 thread, 不能和 CMS gc 一起使用. 系统吨吐量优先 , 但是会有较长长时间的 app pause, 后台系统任务可以使用此 gc 

b: -XX:ParallelGCThreads=<n> 
指定 parallelcollection 时启动的 thread 个数 , 默认是物理processor的个数 , 

c: -XX:+UseParallelOldGC 
指定在 OldGeneration 使用 parallelcollector 

d: -XX:+UseParNewGC 
指定在 NewGeneration 使用 parallelcollector, 是UseParallelGC 的 gc 的升级版本 , 有更好的性能或者优点 , 可以和 CMS gc 一起使用

e: -XX:+CMSParallelRemarkEnabled 
在使用 UseParNewGC的情况下 , 尽量减少 mark 的时间 

f: -XX:+UseConcMarkSweepGC 
指 定在 Old Generation 使用 concurrent cmark sweep gc,gc thread 和 app thread 并行( 在 init-mark 和 remark 时pause app thread). app pause 时间较短, 适合交互性强的系统 , 如 web server 

g: -XX:+UseCMSCompactAtFullCollection 
在使用 concurrentgc 的情况下 , 防止 memory fragmention, 对 live object 进行整理, 使 memory 碎片减少 

h: -XX:CMSInitiatingOccupancyFraction=<n> 
指示在 oldgeneration 在使用了 n% 的比例后 , 启动concurrent collector, 默认值是68, 如:-XX:CMSInitiatingOccupancyFraction=70 

i: -XX:+UseCMSInitiatingOccupancyOnly 
指示只有在 oldgeneration 在使用了初始化的比例后 concurrentcollector 启动收集 

3:others 

a: -XX:MaxTenuringThreshold=<n> 
指 定一个 object 在经历了n 次 young gc 后转移到 old generation 区 , 在linux64 的 java6 下默认值是 15, 此参数对于 throughput collector 无效 , 如:-XX:MaxTenuringThreshold=31 

b: -XX:+DisableExplicitGC 
禁止 java 程序中的 full gc, 如System.gc() 的调用. 最好加上么， 防止程序在代码里误用了。对性能造成冲击。 

c: -XX:+UseFastAccessorMethods 
get,set 方法转成本地代码 

d: -XX:+PrintGCDetails 
打应垃圾收集的情况如 : 
[GC 15610.466: [ParNew: 229689K->20221K(235968K), 0.0194460 secs]1159829K->953935K(2070976K), 0.0196420 secs] 

e: -XX:+PrintGCTimeStamps 
打应垃圾收集的时间情况 , 如 : 
[Times: user=0.09 sys=0.00, real=0.02 secs] 

f: -XX:+PrintGCApplicationStoppedTime 
打应垃圾收集时 , 系统的停顿时间 , 如 : 
Total time for which application threads were stopped: 0.0225920 seconds 

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html