Java 虚拟机有自己完善的硬件架构, 如处理器、堆栈、寄存器等，还具有相应的指令系统。JVM 屏蔽了与具体操作系统平台相关的信息，使得 Java 程序只需生成在 Java 虚拟机上运行的目标代码 (字节码), 就可以在多种平台上不加修改地运行。
线程共享区域为：
1、java堆
2、方法区
线程私有区域为：
3、JVM栈
4、本地方法栈
5、程序计数器
各区域作用：
1、java堆：
java堆是jvm内存管理中最大的一块，线程共享。在jvm启动的时候创建。此区域唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。但是随着JIT编译器（即时编译器）的发展与逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙变化（对象可能会分配到栈上），所以这种所有对象都分配在堆上也不是那么绝对的。
java堆细分为新生代和老年代，新生代又分为Eden空间、From Survivor空间、To Survivor空间，新生代中垃圾回收算法为复制算法，复制算法是先将内存分为连个部分，一部分用来放入对象，而另一部分暂时不用，当使用的一部分内存要进行垃圾回收的时候会将不需要回收的对象复制保存在另一个空间中，然后再对使用过的那部分区域进行垃圾回收，这样虽然效率很高，但是很浪费空间，所以一般将新生代分为Eden空间和两个Survivor空间，其大小在HotSpot虚拟机中默认比例为8：1：1，这样在新生代中采用复制算法回收垃圾效率就很高了，具体回收过程是将Eden区域和From Survivor区域作为对象的存储空间，当要进行垃圾回收的时候先将这两个区域中不需要回收的对象复制保存在To Survivor区域中，然后再进行垃圾回收。另外有一点是当一个对象在Eden区域和From Survivor区域中存储的时候发现内存不足，这时会进行内存分配担保，就是将此对象直接存入在老年代中。
关于对象的分配：对象优先在Eden区域分配，大对象会直接进入老年代，长期存活的对象会进入老年代，这里的长期存活是根据新生代中的对象年龄阈值来定义的，对象刚分配到新生代的时候年龄为1，每进行一次GC对象的年龄会加1，HotSpot中默认的阈值是15，也就是说对象年龄达到15岁的时候会被分配到老年区，这个值是可以通过参数配置的。
在进行垃圾回收的时候新生代GC又叫minor GC，老年代GC可以设置内存容量达到百分比的多少的时候进行GC，老年代的GC又叫Full GC，minor GC时间短，频率高，而Full GC时间长，频率低。
2、方法区
方法区又被称为永久区，线程共享，是用来存储已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。方法区为堆的一个逻辑部分，但是在JDK1.7的HotSpot中已经将方法区中的字符串常量池移出，部分资料显示JDK1.8已经去除了方法区（不确定）。不过已经可以猜测此区域将会被本地内存逐步取代。
这个区域很少进行垃圾回收，回收目标主要是针对常量池的回收和对类型的卸载。
3、JVM栈
JVM栈是线程私有的，它的生命周期与线程相同。JVM栈描述的是java方法执行的内存模型，每个方法在执行的同时都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
局部变量表中存放了编译期可知的各种基本数据类型、对象的引用类型。局部变量表中需要的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
4、本地方法栈
本地方法栈和JVM栈非常相似，它们之间的区别不过是jvm栈是为执行java方法服务，而本地方法栈是为jvm使用到对的本地方法服务。HotSpot虚拟机中直接把本地方法栈和JVM栈合二为一了。
5、程序计数器
程序计数器是一块较小的内存空间，线程私有。它可以看作是当前线程所执行的字节码的行号指示器。在jvm的概念模型里，字节码解释器工作就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
如果线程正在执行的是一个java方法，这个计数器记录的是正在执行的jvm字节码指令的地址；如果正在执行的是本地方法，这个计数器值则为空。
总结：
在jvm划分的内存区域中JVM栈和本地方法栈可能会抛出StackOverflowError异常和OutOfMemoryError异常。java堆和方法区可能会抛出OutOfMemoryError异常。程序计数器中没有地方规定会抛出这两个异常。
2.gc基础
2.1垃圾收集算法
序号算法说明优/缺点
1引用计数法 (Reference Counting)对于一个对象 A，只要有任何一个对象引用了 A，则 A 的引用计数器就加 1。无法处理循环引用的情况。因此，在 Java 的垃圾回收器中没有使用这种算法。
循环引用问题描述如下：有对象 A 和对象 B，对象 A 中含有对象 B 的引用，对象 B 中含有对象 A 的引用。此时，对象 A 和对象 B 的引用计数器都不为 0。但是在系统中却不存在任何第 3 个对象引用了 A 或 B。也就是说，A 和 B 是应该被回收的垃圾对象，但由于垃圾对象间相互引用，从而使垃圾回收器无法识别，引起内存泄漏。
2标记-清除算法 (Mark-Sweep)将垃圾回收分为两个阶段：标记阶段和清除阶段。
一种可行的实现是，在标记阶段首先通过根节点，标记所有从根节点开始的较大对象。因此，未被标记的对象就是未被引用的垃圾对象。然后，在清除阶段，清除所有未被标记的对象。最大的问题是存在大量的空间碎片，因为回收后的空间是不连续的。在对象的堆空间分配过程中，尤其是大对象的内存分配，不连续的内存空间的工作效率要低于连续的空间。
3复制算法 (Copying)将现有的内存空间分为两快，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。
如果系统中的垃圾对象很多，复制算法需要复制的存活对象数量并不会太大。因此在真正需要垃圾回收的时刻，复制算法的效率是很高的。又由于对象在垃圾回收过程中统一被复制到新的内存空间中，因此，可确保回收后的内存空间是没有碎片的。该算法的缺点是将系统内存折半。
4标记-压缩算法 (Mark-Compact)复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在年轻代经常发生，但是在老年代更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活的对象较多，复制的成本也将很高。
标记-压缩算法是一种老年代的回收算法，它在标记-清除算法的基础上做了一些优化。也首先需要从根节点开始对所有可达对象做一次标记，但之后，它并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端。之后，清理边界外所有的空间。这种方法既避免了碎片的产生，又不需要两块相同的内存空间，因此，其性价比比较高。
5增量算法 (Incremental Collecting)在垃圾回收过程中，应用软件将处于一种 CPU 消耗很高的状态。在这种 CPU 消耗很高的状态下，应用程序所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性。
增量算法的基本思想是，如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。
2.2JVM 垃圾回收器分类
根据垃圾回收对象的特性，不同阶段最优的方式是使用合适的算法用于本阶段的垃圾回收。
从不同角度分析垃圾收集器，可以将其分为不同的类型。
1. 按线程数分，可以分为串行垃圾回收器和并行垃圾回收器。串行垃圾回收器一次只使用一个线程进行垃圾回收；并行垃圾回收器一次将开启多个线程同时进行垃圾回收。在并行能力较强的 CPU 上，使用并行垃圾回收器可以缩短 GC 的停顿时间。
2. 按照工作模式分，可以分为并发式垃圾回收器和独占式垃圾回收器。并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间；独占式垃圾回收器 (Stop the world) 一旦运行，就停止应用程序中的其他所有线程，直到垃圾回收过程完全结束。
3. 按碎片处理方式可分为压缩式垃圾回收器和非压缩式垃圾回收器。压缩式垃圾回收器会在回收完成后，对存活对象进行压缩整理，消除回收后的碎片；非压缩式的垃圾回收器不进行这步操作。
4. 按工作的内存区间，又可分为新生代垃圾回收器和老年代垃圾回收器。
可以用以下指标评价一个垃圾处理器的好坏。
吞吐量：指在应用程序的生命周期内，应用程序所花费的时间和系统总运行时间的比值。系统总运行时间=应用程序耗时+GC 耗时。如果系统运行了 100min，GC 耗时 1min，那么系统的吞吐量就是 (100-1)/100=99%。
垃圾回收器负载：和吞吐量相反，垃圾回收器负载指来记回收器耗时与系统运行总时间的比值。
停顿时间：指垃圾回收器正在运行时，应用程序的暂停时间。对于独占回收器而言，停顿时间可能会比较长。使用并发的回收器时，由于垃圾回收器和应用程序交替运行，程序的停顿时间会变短，但是，由于其效率很可能不如独占垃圾回收器，故系统的吞吐量可能会较低。
垃圾回收频率：指垃圾回收器多长时间会运行一次。一般来说，对于固定的应用而言，垃圾回收器的频率应该是越低越好。通常增大堆空间可以有效降低垃圾回收发生的频率，但是可能会增加回收产生的停顿时间。
反应时间：指当一个对象被称为垃圾后多长时间内，它所占据的内存空间会被释放。
堆分配：不同的垃圾回收器对堆内存的分配方式可能是不同的。一个良好的垃圾收集器应该有一个合理的堆内存区间划分。
垃圾收集器种类：
新生代串行收集器
串行收集器主要有两个特点：第一，它仅仅使用单线程进行垃圾回收；第二，它独占式的垃圾回收。
在 HotSpot 虚拟机中，使用-XX：+UseSerialGC参数可以指定使用新生代串行收集器和老年代串行收集器。当 JVM 在 Client 模式下运行时，它是默认的垃圾收集器。
老年代串行收集器
老年代串行收集器使用的是标记-压缩算法。
可以尝试使用以下参数：-XX:+UseSerialGC: 新生代、老年代都使用串行回收器。
如果使用-XX:+UseParNewGC 参数设置，表示新生代使用并行收集器，老年代使用串行收集器
如果使用-XX:+UseParallelGC 参数设置，表示新生代和老年代均使用并行回收收集器。
并行收集器
并行收集器是工作在新生代的垃圾收集器，它只简单地将串行回收器多线程化。它的回收策略、算法以及参数和串行回收器一样。
并行回收器也是独占式的回收器，在收集过程中，应用程序会全部暂停。但由于并行回收器使用多线程进行垃圾回收，因此，在并发能力比较强的 CPU 上，它产生的停顿时间要短于串行回收器，而在单 CPU 或者并发能力较弱的系统中，并行回收器的效果不会比串行回收器好，由于多线程的压力，它的实际表现很可能比串行回收器差。
设置参数-XX:+UseConcMarkSweepGC可以要求新生代使用并行收集器，老年代使用 CMS。
并行收集器工作时的线程数量可以使用-XX:ParallelGCThreads 参数指定。一般，最好与 CPU 数量相当，避免过多的线程数影响垃圾收集性能。在默认情况下，当 CPU 数量小于 8 个，ParallelGCThreads 的值等于 CPU 数量，大于 8 个，ParallelGCThreads 的值等于 3+[5*CPU_Count]/8]。
新生代并行回收 (Parallel Scavenge) 收集器
新生代并行回收收集器也是使用复制算法的收集器。从表面上看，它和并行收集器一样都是多线程、独占式的收集器。但是，并行回收收集器有一个重要的特点：它非常关注系统的吞吐量。
新生代并行回收收集器可以使用以下参数启用：
-XX:+UseParallelGC:新生代使用并行回收收集器，老年代使用串行收集器。
-XX:+UseParallelOldGC:新生代和老年代都是用并行回收收集器。
-XX:+MaxGCPauseMills:设置最大垃圾收集停顿时间，它的值是一个大于 0 的整数。收集器在工作时会调整 Java 堆大小或者其他一些参数，尽可能地把停顿时间控制在 MaxGCPauseMills 以内。如果希望减少停顿时间，而把这个值设置得很小，为了达到预期的停顿时间，JVM 可能会使用一个较小的堆 (一个小堆比一个大堆回收快)，而这将导致垃圾回收变得很频繁，从而增加了垃圾回收总时间，降低了吞吐量。
-XX:+GCTimeRatio：设置吞吐量大小，它的值是一个 0-100 之间的整数。假设 GCTimeRatio 的值为 n，那么系统将花费不超过 1/(1+n) 的时间用于垃圾收集。比如 GCTimeRatio 等于 19，则系统用于垃圾收集的时间不超过 1/(1+19)=5%。默认情况下，它的取值是 99，即不超过 1%的时间用于垃圾收集。
除此之外，并行回收收集器与并行收集器另一个不同之处在于，它支持一种自适应的 GC 调节策略，使用-XX:+UseAdaptiveSizePolicy 可以打开自适应 GC 策略。在这种模式下，新生代的大小、eden 和 survivor 的比例、晋升老年代的对象年龄等参数会被自动调整，以达到在堆大小、吞吐量和停顿时间之间的平衡点。在手工调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆、目标的吞吐量 (GCTimeRatio) 和停顿时间 (MaxGCPauseMills)，让虚拟机自己完成调优工作。
老年代并行回收收集器
和新生代并行回收收集器一样，它也是一种关注吞吐量的收集器。老年代并行回收收集器使用标记-压缩算法，JDK1.6 之后开始启用、
CMS 收集器
与并行回收收集器不同，CMS 收集器主要关注于系统停顿时间。CMS 是 Concurrent Mark Sweep 的缩写，意为并发标记清除，从名称上可以得知，它使用的是标记-清除算法，同时它又是一个使用多线程并发回收的垃圾收集器。
CMS 工作时，主要步骤有：初始标记、并发标记、重新标记、并发清除和并发重置。其中初始标记和重新标记是独占系统资源的，而并发标记、并发清除和并发重置是可以和用户线程一起执行的。因此，从整体上来说，CMS 收集不是独占式的，它可以在应用程序运行过程中进行垃圾回收。
CMS 默认启动的线程数是 (ParallelGCThreads+3)/4),ParallelGCThreads 是新生代并行收集器的线程数
CMS 收集器不会等待堆内存饱和时才进行垃圾回收，而是当前堆内存使用率达到某一阈值时，便开始进行回收，以确保应用程序在 CMS 工作过程中依然有足够的空间支持应用程序运行。
这个回收阈值可以使用-XX:CMSInitiatingOccupancyFraction来指定，默认是 68。即当老年代的空间使用率达到 68%时，会执行一次 CMS 回收。如果应用程序的内存使用率增长很快，在 CMS 的执行过程中，已经出现了内存不足的情况，此时，CMS 回收将会失败，JVM 将启动老年代串行收集器进行垃圾回收。
G1 收集器 (Garbage First)
G1 收集器的目标是作为一款服务器的垃圾收集器，因此，它在吞吐量和停顿控制上，预期要优于 CMS 收集器。
与 CMS 收集器相比，G1 收集器是基于标记-压缩算法的。因此，它不会产生空间碎片，也没有必要在收集完成后，进行一次独占式的碎片整理工作。G1 收集器还可以进行非常精确的停顿控制。它可以让开发人员指定当停顿时长为 M 时，垃圾回收时间不超过 N。使用参数-XX:+UnlockExperimentalVMOptions –XX:+UseG1GC 来启用 G1 回收器，设置 G1 回收器的目标停顿时间：-XX:MaxGCPauseMills=20,-XX:GCPauseIntervalMills=200。
3.虚拟机&GC 相关参数总结
虚拟机提供了-XX:+PrintGCDetails参数打印收集器日志，并且在进程退出时输出当前内存各区域的分配情况。
例如 通过 -Xms20M -Xmx20M -Xmn10M这3个参数限制java堆大小为20MB，且不可扩展。其中10MB分配给新生代，剩下的10MB分配给老年代。
-XX:SurvivorRatio=8 决定了新生代中Eden区与一个Survivor区的比例为8:1，即Eden区=8MB，一个Survivor=1MB,另一个Surviveor也为1MB。
1. 与串行回收器相关的参数
-XX:+UseSerialGC:在新生代和老年代使用串行回收器。
-XX:+SuivivorRatio:设置 eden 区大小和 survivor 区大小的比例。
-XX:+PretenureSizeThreshold:设置大对象直接进入老年代的阈值。当对象的大小超过这个值时，将直接在老年代分配。
-XX:MaxTenuringThreshold:设置对象进入老年代的年龄的最大值。每一次 Minor GC 后，对象年龄就加 1。任何大于这个年龄的对象，一定会进入老年代。
2. 与并行 GC 相关的参数
-XX:+UseParNewGC: 在新生代使用并行收集器。
-XX:+UseParallelOldGC: 老年代使用并行回收收集器。
-XX:ParallelGCThreads：设置用于垃圾回收的线程数。通常情况下可以和 CPU 数量相等。但在 CPU 数量比较多的情况下，设置相对较小的数值也是合理的。
-XX:MaxGCPauseMills：设置最大垃圾收集停顿时间。它的值是一个大于 0 的整数。收集器在工作时，会调整 Java 堆大小或者其他一些参数，尽可能地把停顿时间控制在 MaxGCPauseMills 以内。
-XX:GCTimeRatio:设置吞吐量大小，它的值是一个 0-100 之间的整数。假设 GCTimeRatio 的值为 n，那么系统将花费不超过 1/(1+n) 的时间用于垃圾收集。
-XX:+UseAdaptiveSizePolicy:打开自适应 GC 策略。在这种模式下，新生代的大小，eden 和 survivor 的比例、晋升老年代的对象年龄等参数会被自动调整，以达到在堆大小、吞吐量和停顿时间之间的平衡点。
3. 与 CMS 回收器相关的参数
-XX:+UseConcMarkSweepGC: 新生代使用并行收集器，老年代使用 CMS+串行收集器。
-XX:+ParallelCMSThreads: 设定 CMS 的线程数量。
-XX:+CMSInitiatingOccupancyFraction:设置 CMS 收集器在老年代空间被使用多少后触发，默认为 68%。
-XX:+UseFullGCsBeforeCompaction:设定进行多少次 CMS 垃圾回收后，进行一次内存压缩。
-XX:+CMSClassUnloadingEnabled:允许对类元数据进行回收。
-XX:+CMSParallelRemarkEndable:启用并行重标记。
-XX:CMSInitatingPermOccupancyFraction:当永久区占用率达到这一百分比后，启动 CMS 回收 (前提是-XX:+CMSClassUnloadingEnabled 激活了)。
-XX:UseCMSInitatingOccupancyOnly:表示只在到达阈值的时候，才进行 CMS 回收。
-XX:+CMSIncrementalMode:使用增量模式，比较适合单 CPU。
4. 与 G1 回收器相关的参数
-XX:+UseG1GC：使用 G1 回收器。
-XX:+UnlockExperimentalVMOptions:允许使用实验性参数。
-XX:+MaxGCPauseMills:设置最大垃圾收集停顿时间。
-XX:+GCPauseIntervalMills:设置停顿间隔时间。
5. 其他参数
-XX:+DisableExplicitGC: 禁用显示 GC。
4.优化经验总结
如何将新对象预留在年轻代
由于 Full GC 的成本远远高于 Minor GC，因此某些情况下需要尽可能将对象分配在年轻代。
虽然在大部分情况下，JVM 会尝试在 Eden 区分配对象，但是由于空间紧张等问题，很可能不得不将部分年轻对象提前向年老代压缩。因此，在 JVM 参数调优时可以为应用程序分配一个合理的年轻代空间，以最大限度避免新对象直接进入年老代的情况发生。
a.-Xms20M-Xmx20M-Xmn10M，适当增大Xmn大小：-XX:+PrintGCDetails -Xmx20M -Xms20M-Xmn6M
b.一般来说，Survivor 区的空间不够，或者占用量达到 50%时，就会使对象进入年老代 (不管它的年龄有多大)；-XX:+PrintGCDetails -Xmx1000M -Xms500M -Xmn100M -XX:SurvivorRatio=8
c.可以尝试加上-XX:TargetSurvivorRatio=90 参数，这样可以提高 from 区的利用率，使 from 区使用到 90%时，再将对象送入年老代
如何让大对象进入年老代
尝试在年轻代分配大对象，很可能导致空间不足，为了有足够的空间容纳大对象，JVM 不得不将年轻代中的年轻对象挪到年老代。因为大对象占用空间多，所以可能需要移动大量小的年轻对象进入年老代，这对 GC 相当不利。
使用参数-XX:PetenureSizeThreshold 设置大对象直接进入年老代的阈值。当对象的大小超过这个值时，将直接在年老代分配。参数-XX:PetenureSizeThreshold 只对串行收集器和年轻代并行收集器有效，并行回收收集器不识别这个参数。
如果需要将 1MB 以上的对象直接在年老代分配，设置-XX:PetenureSizeThreshold=1000000
如何设置对象进入年老代的年龄
如果对象在 Eden 区，经过一次 GC 后依然存活，则被移动到 Survivor 区中，对象年龄加 1。以后，如果对象每经过一次 GC 依然存活，则年龄再加 1。当对象年龄达到阈值时，就移入年老代。
阈值的最大值可以通过参数-XX:MaxTenuringThreshold 来设置，默认值是 15。
实际晋升年老代年龄等于虚拟机在运行时根据内存使用情况动态计算所得的年龄与-XX:MaxTenuringThreshold 中较小的那个。
稳定的 Java 堆 VS 动荡的 Java 堆
获得一个稳定的堆大小的方法是使-Xms 和-Xmx 的大小一致，即最大堆和最小堆 (初始堆) 一样.
系统在运行时堆大小理论上是恒定的，稳定的堆空间可以减少 GC 的次数。
一个不稳定的堆并非毫无用处。稳定的堆大小虽然可以减少 GC 次数，但同时也增加了每次 GC 的时间。让堆大小在一个区间中震荡，在系统不需要使用大内存时，压缩堆空间，使 GC 应对一个较小的堆，可以加快单次 GC 的速度。
-XX:MinHeapFreeRatio 参数用来设置堆空间最小空闲比例，默认值是 40。当堆空间的空闲内存小于这个数值时，JVM 便会扩展堆空间。
-XX:MaxHeapFreeRatio 参数用来设置堆空间最大空闲比例，默认值是 70。当堆空间的空闲内存大于这个数值时，便会压缩堆空间，得到一个较小的堆。
当-Xmx 和-Xms 相等时，-XX:MinHeapFreeRatio 和-XX:MaxHeapFreeRatio 两个参数无效。
在一个稳定的堆中，堆空间大小始终不变，每次 GC 时，都要应对一个 40MB 的空间。因此，虽然 GC 次数减小了，但是单次 GC 速度不如一个震荡的堆。
增大吞吐量提升系统性能
吞吐量优先的方案将会尽可能减少系统执行垃圾回收的总时间，故可以考虑关注系统吞吐量的并行回收收集器。
–Xmx380m –Xms3800m：设置 Java 堆的最大值和初始值。一般情况下，为了避免堆内存的频繁震荡，导致系统性能下降，我们的做法是设置最大堆等于最小堆。假设这里把最小堆减少为最大堆的一半，即 1900m，那么 JVM 会尽可能在 1900MB 堆空间中运行，如果这样，发生 GC 的可能性就会比较高；
-Xss128k：减少线程栈的大小，这样可以使剩余的系统内存支持更多的线程；
-Xmn2g：设置年轻代区域大小为 2GB；
–XX:+UseParallelGC：年轻代使用并行垃圾回收收集器。这是一个关注吞吐量的收集器，可以尽可能地减少 GC 时间。
–XX:ParallelGC-Threads：设置用于垃圾回收的线程数，通常情况下，可以设置和 CPU 数量相等。但在 CPU 数量比较多的情况下，设置相对较小的数值也是合理的；
–XX:+UseParallelOldGC：设置年老代使用并行回收收集器。
使用非占有的垃圾回收器
为降低应用软件的垃圾回收时的停顿，首先考虑的是使用关注系统停顿的 CMS 回收器，其次，为了减少 Full GC 次数，应尽可能将对象预留在年轻代，因为年轻代 Minor GC 的成本远远小于年老代的 Full GC。
–XX:ParallelGCThreads=20：设置 20 个线程进行垃圾回收；
–XX:+UseParNewGC：年轻代使用并行回收器；
–XX:+UseConcMarkSweepGC：年老代使用 CMS 收集器降低停顿；
–XX:+SurvivorRatio：设置 Eden 区和 Survivor 区的比例为 8:1。稍大的 Survivor 空间可以提高在年轻代回收生命周期较短的对象的可能性，如果 Survivor 不够大，一些短命的对象可能直接进入年老代，这对系统来说是不利的。
–XX:TargetSurvivorRatio=90：设置 Survivor 区的可使用率。这里设置为 90%，则允许 90%的 Survivor 空间被使用。默认值是 50%。故该设置提高了 Survivor 区的使用率。当存放的对象超过这个百分比，则对象会向年老代压缩。因此，这个选项更有助于将对象留在年轻代。
–XX:MaxTenuringThreshold：设置年轻对象晋升到年老代的年龄。默认值是 15 次，即对象经过 15 次 Minor GC 依然存活，则进入年老代。这里设置为 31，目的是让对象尽可能地保存在年轻代区域。
4 参数解析
filterapi项目jetty启动参数
JVM_ARGS="-server -Dapp.key=com.sankuai.web.meishifilter.filterapi -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 -Djava.io.tmpdir=/tmp -Djava.net.preferIPv6Addresses=false"
JVM_HEAP="-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+ExplicitGCInvokesConcurrent -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled -XX:+TieredCompilation -XX:CICompilerCount=4"
JVM_GC="-XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps"
JVM_SIZE="-Xmx4096m -Xms4096m -Xmn1536m -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M"
序号JVM_HEAP
参数说明
1-XX:+UseConcMarkSweepGC新生代使用并行收集器，老年代使用CMS,使用CMS内存收集
最新的JVM版本，当使用-XX：+UseConcMarkSweepGC时，-XX：UseParNewGC会自动开启，即年轻代使用多线程并行执行垃圾回收。
2-XX:+CMSParallelRemarkEnabledCMS参数，降低标记停顿
3-XX:+ExplicitGCInvokesConcurrent系统大量使用NIO中的DirectByteBuffer时，需要定期清理本地内存。
DirectByteBuffer通过内存映射，使Java进程直接访问与文件相关联的虚拟地址空间，减少了文件拷贝带来的开销，提高了文件读取效率。这一块虚拟地址空间并不是分配在jvm堆上，而是分配在native堆上。yong gc不能回收这部分空间，只能通过Full gc顺带进行回收，那是因为Full gc时会触发sun.misc.Cleaner，对DirectByteBuffer对象做清理工作。
为了减少fullGC的卡顿现象，有以下几种解决办法：
当程序中出现:
使用了NIO或者NIO框架（Mina/Netty等）
使用了DirectByteBuffer分配字节缓冲区
使用了MappedByteBuffer做内存映射
最好使用ExplicitGCInvokesConcurrent参数来替代DisableExplicitGC。需要注意的是ExplicitGCInvokesConcurrent只能配合CMS收集器使用。
关于堆外内存参考堆外内存
参考http://blog.csdn.net/aesop_wubo/article/details/38406709
4-XX:CMSInitiatingOccupancyFraction=70CMS 收集器不会等待堆内存饱和时才进行垃圾回收，而是当前堆内存使用率达到某一阈值时，便开始进行回收，以确保应用程序在 CMS 工作过程中依然有足够的空间支持应用程序运行。
这个回收阈值可以使用-XX:CMSInitiatingOccupancyFraction 来指定，默认是 68。即当老年代的空间使用率达到 68%时，会执行一次 CMS 回收。如果应用程序的内存使用率增长很快，在 CMS 的执行过程中，已经出现了内存不足的情况，此时，CMS 回收将会失败，JVM 将启动老年代串行收集器进行垃圾回收。
5-XX：+UseCMSInitiatingOccupancyOnly我们用-XX+UseCMSInitiatingOccupancyOnly标志来命令JVM不基于运行时收集的数据来启动CMS垃圾收集周期。而是，当该标志被开启时，JVM通过CMSInitiatingOccupancyFraction的值进行每一次CMS收集，而不仅仅是第一次。然而，请记住大多数情况下，JVM比我们自己能作出更好的垃圾收集决策。因此，只有当我们充足的理由(比如测试)并且对应用程序产生的对象的生命周期有深刻的认知时，才应该使用该标志。
6XX:+CMSPermGenSweepingEnabled相对于并行收集器，CMS收集器默认不会对永久代进行垃圾回收。如果希望对永久代进行垃圾回收，可用设置标志-XX:+CMSClassUnloadingEnabled。在早期JVM版本中，要求设置额外的标志-XX:+CMSPermGenSweepingEnabled。注意，即使没有设置这个标志，一旦永久代耗尽空间也会尝试进行垃圾回收，但是收集不会是并行的，而再一次进行Full GC。
7-XX:+TieredCompilation打开“多层编译”（tiered compilation）
参考分层编译 。
在该模式下，代码会先被解释器执行，积累到足够热度的时候由client compiler（C1）编译，然后继续积累热度到一定程度会进一步被server compiler（C2）重新以更高的优化程度编译。
Oracle JDK从JDK 6u25以后的版本支持了多层编译（-XX:+TieredCompilation），这个的好处是之前server都是采用c2高级编译的，会比较耗时且要运行一段时间才会触发编译，而c1编译是比较轻量的也比较快触发，因此在启用了多层编译后，可以在启动后更快的让部分代码先进入编译模式。（启动使用client模式，启动后使用server模式）
关于“java启动时的速度”参考http://hellojava.info/?tag=tieredcompilation
8-XX:CICompilerCount=4编译线程数，server模式默认为2
序号方法备注
1禁用Full gc显示调用（-XX:+DisableExplicitGC）容易导致OOM：”如果启用了-XX:+DisableExplicitGC选项，在以下情况下会出现OOM：系统各方面性能良好，无Full gc且DirectByteBuffer所占用的空间大于-Xmx分配的空间。因为DirectByteBuffer会不断地在native堆分配空间，它的引用进入了old区，old区保存大量的引用，而不能被回收，最终会导致native堆空间不足。
减少Full gc次数通过sun.rmi.dgc.server.gcInterval和un.rmi.dgc.client.gcInterval选项调整Full gc的时间间隔进而减少Full gc次数，
例如可以使用-Dsun.rmi.dgc.server.gcInterval=7200000与-Dsun.rmi.dgc.client.gcInterval=7200000 选项控制Full gc时间间隔
降低每次Full gc的时间通过ExplicitGCInvokesConcurrent选项，可以使用CMS收集器来触发Full gc（相比Full gc，CMS收集器会花费更多的时间，如果对QPS比较敏感的应用应降低CMS触发的次数）
JVM_GC参数说明
1-XX:+PrintGCDetails打印收集器日志，并且在进程退出时输出当前内存各区域的分配情况。
2-XX:+PrintHeapAtGC在进行GC的前后打印出堆的信息
3-XX:+PrintTenuringDistribution-XX:MaxTenuringThreshold= 设置熬过年轻代多少次收集后移入老人区，CMS中默认为0，熬过第一次GC就转入，可以用-XX:+PrintTenuringDistribution 查看。
4-XX:+PrintGCTimeStamps输出GC的时间戳（以基准时间的形式）
5-XX:+PrintGCDateStamps输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
JVM_SIZE
JVM_SIZE
1-Xmx4096mJVM最大可用内存
2-Xms4096mJVM最小可用内存
3-Xmn1536m年轻代
4-XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256MMetaspace（元空间）
移除永久代的工作从JDK1.7就开始了。JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap。但永久代仍存在于JDK1.7中，并没完全移除，譬如符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；类的静态变量(class statics)转移到了java heap。
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。
-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。
除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：
-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集
参考http://www.cnblogs.com/paddix/p/5309550.html
参考：
CMS参数http://ifeve.com/useful-jvm-flags-part-7-cms-collector/
