jvm内存管理

Java虚拟机拥有自动管理内存机制，所以Java 程序员不需要像C/C++一样去关注内存的分配和释放，也不容易出现内存泄露和内存溢出的问题。但是如果一旦出现此类问题，如果我们对虚拟机的内存管理机制不了解，那么解决这类问题还是比较困难的，所以我们要深入学习JVM的内存管理。

Java代码是如何执行的？

JVM 运行时数据区域

Java 虚拟机在执行Java 程序过程中会把它所管理的内存划分为几个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则是依赖用户线程的启动和结束而建立和销毁。

这几个区域如下：

• 方法区（Method Area）
• 虚拟机栈（VM Stack）
• 本地方法栈（Natvie Method Stack）
• 堆（Heap）
• 程序计数器（Program Counter Register）

JVM中Stack和Heap的关系

    我们经常会把 Java 内存分为堆内存（Heap）和栈内存（Stack），这是一种比较粗糙区分方式。我们平时所关注的也主要是这两个区域。栈指的是上图中的Java虚拟机栈。Java 虚拟机栈是线程私有的，其生命周期和线程相同。虚拟机栈描述的是Java方法执行的内存模型，每个方法被执行时都会创建一个栈帧（Stack Frame），用来存储局部变量表、操作数栈、动态链接、方法出口等信息，每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

    局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference）和 returnAddress（指向一条字节码指令的地址）。

    如果线程请求的栈深度大于虚拟机允许的深度，会抛出 StackOverflowException 异常；如果虚拟机栈可以动态扩展，扩展时无法申请到足够内存时会抛出 OutOfMemoryError 异常。递归调用时如果深度过深，很容易出现栈溢出。

    对于大多数应用程序来说，堆(Heap)是Java虚拟机管理的内存中最大的一块。 堆是所有线程共享的一块内存区域，几乎所有的对象实例都在这里分配内存。根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。

    在Java体系中，即便是最简单的对象访问，也会涉及栈、堆、方法区这三个最重要的内存区域。例如下面这行代码：

• Object obj = new Object();

    假如这段代码出现在方法体中，Object obj 这部分的语意会反映到Java虚拟机栈的本地变量表中，做为一个reference 类型数据出现。new Object()这部分语意会反映在Java堆中，形成一块存储了 Object 类型所有实例数据值（Instance Data，对象中各个实例字段的数据）的结构化内存。不同虚拟机的对象访问方式有所不同，主流的访问方式有两种：使用句柄和直接指针。

堆内存

    Java中堆是JVM 管理的最大一块内存空间，主要用于存放各种类的实例对象。堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old )。新生代 ( Young ) 又被划分为三个区域：Eden、From Survivor、To Survivor。这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象，包括内存的分配以及回收。堆的内存模型大致为：

• 堆大小 = 新生代 + 老年代

常用的内存区域调节参数

• -Xms：初始堆大小，默认为物理内存的1/64(<1GB)；默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制

• -Xmx：最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制

• -Xmn：新生代的内存空间大小，注意：此处的大小是（eden+ 2 survivor space)。与jmap -heap中显示的New gen是不同的。整个堆大小=新生代大小 + 老生代大小 + 永久代大小。 在保证堆大小不变的情况下，增大新生代后,将会减小老生代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

• -XX:SurvivorRatio：新生代中Eden区域与Survivor区域的容量比值，默认值为8。两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。

• -Xss：每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。应根据应用的线程所需内存大小进行适当调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。一般小的应用， 如果栈不是很深， 应该是128k够用的，大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:”-Xss is translated in a VM flag named ThreadStackSize”一般设置这个值就可以了。

• -XX:PermSize：设置永久代(perm gen)初始值。默认值为物理内存的1/64。

• -XX:MaxPermSize：设置持久代最大值。物理内存的1/4。

GC 堆

  Java 中的堆也是 GC 收集垃圾的主要区域。GC 分为两种：Minor GC、Full GC ( 或称为 Major GC )。
Minor GC 是发生在新生代中的垃圾收集动作，所采用的是复制算法。
新生代几乎是所有 Java 对象出生的地方，即 Java 对象申请的内存以及存放都是在这个地方。Java 中的大部分对象通常不需长久存活，具有朝生夕灭的性质。
当一个对象被判定为 “死亡” 的时候，GC 就有责任来回收掉这部分对象的内存空间。新生代是 GC 收集垃圾的频繁区域。
当对象在 Eden ( 包括一个 Survivor 区域，这里假设是 from 区域 ) 出生后，在经过一次 Minor GC 后，如果对象还存活，并且能够被另外一块 Survivor 区域所容纳
( 上面已经假设为 from 区域，这里应为 to 区域，即 to 区域有足够的内存空间来存储 Eden 和 from 区域中存活的对象 )，则使用复制算法将这些仍然还存活的对象复制到另外一块 Survivor 区域 ( 即 to 区域 ) 中，然后清理所使用过的 Eden 以及 Survivor 区域 ( 即 from 区域 )，并且将这些对象的年龄设置为1，以后对象在 Survivor 区每熬过一次 Minor GC，就将对象的年龄 + 1，当对象的年龄达到某个值时 ( 默认是 15 岁，可以通过参数 -XX:MaxTenuringThreshold 来设定 )，这些对象就会成为老年代。
但这也不是一定的，对于一些较大的对象 ( 即需要分配一块较大的连续内存空间 ) 则是直接进入到老年代。
Full GC 是发生在老年代的垃圾收集动作，所采用的是标记-清除算法。
现实的生活中，老年代的人通常会比新生代的人 “早死”。堆内存中的老年代(Old)不同于这个，老年代里面的对象几乎个个都是在 Survivor 区域中熬过来的，它们是不会那么容易就 “死掉” 了的。因此，Full GC 发生的次数不会有 Minor GC 那么频繁，并且做一次 Full GC 要比进行一次 Minor GC 的时间更长。
另外，标记-清除算法收集垃圾的时候会产生许多的内存碎片 ( 即不连续的内存空间 )，此后需要为较大的对象分配内存空间时，若无法找到足够的连续的内存空间，就会提前触发一次 GC 的收集动作。

GC 日志

public static void main(String[] args) {
    Object obj = new Object();
    System.gc();
    System.out.println();
    obj = new Object();
    obj = new Object();
    System.gc();
    System.out.println();
}

设置 JVM 参数为 -XX:+PrintGCDetails，使得控制台能够显示 GC 相关的日志信息，执行上面代码，下面是其中一次执行的结果。

  从 Full GC 信息可知，新生代可用的内存大小约为 18M，则新生代实际分配得到的内存空间约为 20M(为什么是 20M? 请继续看下面…)。老年代分得的内存大小约为 42M，堆的可用内存的大小约为 60M。可以计算出： 18432K ( 新生代可用空间 ) + 42112K ( 老年代空间 ) = 60544K ( 堆的可用空间 )
新生代约占堆大小的 1/3，老年代约占堆大小的 2/3。也可以看出，GC 对新生代的回收比较乐观，而对老年代以及方法区的回收并不明显或者说不及新生代。
并且在这里 Full GC 耗时是 Minor GC 的 22.89 倍。

JVM 参数选项

jvm 可配置的参数选项可以参考 Oracle 官方网站给出的相关信息：http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

参数	作用
-Xms	初始堆大小。如：-Xms256m
-Xmx	最大堆大小。如：-Xmx512m
-Xmn	新生代大小。通常为 Xmx 的 1/3 或 1/4。新生代 = Eden + 2 个 Survivor 空间。实际可用空间为 = Eden + 1 个 Survivor，即 90%
-Xss	JDK1.5+ 每个线程堆栈大小为 1M，一般来说如果栈不是很深的话， 1M 是绝对够用了的。
-XX:NewRatio	新生代与老年代的比例，如 –XX:NewRatio=2，则新生代占整个堆空间的1/3，老年代占2/3
-XX:SurvivorRatio	新生代中 Eden 与 Survivor 的比值。默认值为 8。即 Eden 占新生代空间的 8/10，另外两个 Survivor 各占 1/10
-XX:PermSize	永久代(方法区)的初始大小
-XX:MaxPermSize	永久代(方法区)的最大值
-XX:+PrintGCDetails	打印 GC 信息
-XX:+HeapDumpOnOutOfMemoryError	让虚拟机在发生内存溢出时 Dump 出当前的内存堆转储快照，以便分析用

/**
    -Xms60m
    -Xmx60m
    -Xmn20m
    -XX:NewRatio=2 ( 若 Xms = Xmx, 并且设定了 Xmn, 那么该项配置就不需要配置了 )
    -XX:SurvivorRatio=8
    -XX:PermSize=30m
    -XX:MaxPermSize=30m
    -XX:+PrintGCDetails
*/ public static void main(String[] args) { new Test().doTest();
} public void doTest(){
    Integer M = new Integer(1024 * 1024 * 1); //单位, 兆(M) byte[] bytes = new byte[1 * M]; //申请 1M 大小的内存空间 bytes = null; //断开引用链 System.gc(); //通知 GC 收集垃圾 System.out.println();
    bytes = new byte[1 * M]; //重新申请 1M 大小的内存空间 bytes = new byte[1 * M]; //再次申请 1M 大小的内存空间 System.gc();
    System.out.println();
}

按上面代码中注释的信息设定 jvm 相关的参数项，并执行程序，下面是一次执行完成控制台打印的结果：

[ GC [ PSYoungGen: 1351K -> 288K (18432K) ] 1351K -> 288K (59392K), 0.0012389 secs ]  [ Times: user=0.00 sys=0.00, real=0.00 secs ] 
[ Full GC (System)  [ PSYoungGen: 288K -> 0K (18432K) ]  [ PSOldGen: 0K -> 160K (40960K) ] 288K -> 160K (59392K)  [ PSPermGen: 2942K -> 2942K (30720K) ], 0.0057649 secs ] [ Times:  user=0.00 sys=0.00,  real=0.01 secs ] 

[ GC [ PSYoungGen: 2703K -> 1056K (18432K) ] 2863K -> 1216K(59392K), 0.0008206 secs ]  [ Times: user=0.00 sys=0.00, real=0.00 secs ] 
[ Full GC (System)  [ PSYoungGen: 1056K -> 0K (18432K) ]  [ PSOldGen: 160K -> 1184K (40960K) ] 1216K -> 1184K (59392K)  [ PSPermGen: 2951K -> 2951K (30720K) ], 0.0052445 secs ]  [ Times: user=0.02 sys=0.00, real=0.01 secs ] 

Heap
PSYoungGen      total 18432K, used 327K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
eden space 16384K, 2% used [0x00000000fec00000,0x00000000fec51f58,0x00000000ffc00000)
from space 2048K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x0000000100000000)
to   space 2048K, 0% used [0x00000000ffc00000,0x00000000ffc00000,0x00000000ffe00000)
PSOldGen        total 40960K, used 1184K [0x00000000fc400000, 0x00000000fec00000, 0x00000000fec00000)
object space 40960K, 2% used [0x00000000fc400000,0x00000000fc5281f8,0x00000000fec00000)
PSPermGen       total 30720K, used 2959K [0x00000000fa600000, 0x00000000fc400000, 0x00000000fc400000)
object space 30720K, 9% used [0x00000000fa600000,0x00000000fa8e3ce0,0x00000000fc400000)

从打印结果可以看出，堆中新生代的内存空间为 18432K ( 约 18M )，eden 的内存空间为 16384K ( 约 16M)，from / to survivor 的内存空间为 2048K ( 约 2M)。
这里所配置的 Xmn 为 20M，也就是指定了新生代的内存空间为 20M，可是从打印的堆信息来看，新生代怎么就只有 18M 呢? 另外的 2M 哪里去了?
别急，是这样的。新生代 = eden + from + to = 16 + 2 + 2 = 20M，可见新生代的内存空间确实是按 Xmn 参数分配得到的。
而且这里指定了 SurvivorRatio = 8，因此，eden = 8/10 的新生代空间 = 8/10 20 = 16M。from = to = 1/10 的新生代空间 = 1/10 20 = 2M。
堆信息中新生代的 total 18432K 是这样来的： eden + 1 个 survivor = 16384K + 2048K = 18432K，即约为 18M。
因为 jvm 每次只是用新生代中的 eden 和 一个 survivor，因此新生代实际的可用内存空间大小为所指定的 90%。
因此可以知道，这里新生代的内存空间指的是新生代可用的总的内存空间，而不是指整个新生代的空间大小。
另外，可以看出老年代的内存空间为 40960K ( 约 40M )，堆大小 = 新生代 + 老年代。因此在这里，老年代 = 堆大小 – 新生代 = 60 – 20 = 40M。
最后，这里还指定了 PermSize = 30m，PermGen 即永久代 ( 方法区 )，它还有一个名字，叫非堆，主要用来存储由 jvm 加载的类文件信息、常量、静态变量等。

打个盹，回到 doTest() 方法中，可以看到代码在第 17、21、22 这三行中分别申请了一块 1M 大小的内存空间，并在 19 和 23 这两行中分别显式的调用了 System.gc()。从控制台打印的信息来看，每次调 System.gc()，是先进行 Minor GC，然后再进行 Full GC。
第 19 行触发的 Minor GC 收集分析：
从信息 PSYoungGen : 1351K -> 288K，可以知道，在第 17 行为 bytes 分配的内存空间已经被回收完成。
引起 GC 回收这 1M 内存空间的因素是第 18 行的 bytes = null; bytes 为 null 表明之前申请的那 1M 大小的内存空间现在已经没有任何引用变量在使用它了，
并且在内存中它处于一种不可到达状态 ( 即没有任何引用链与 GC Roots 相连 )。那么，当 Minor GC 发生的时候，GC 就会来回收掉这部分的内存空间。
第 19 行触发的 Full GC 收集分析：
在 Minor GC 的时候，信息显示 PSYoungGen : 1351K -> 288K，再看看 Full GC 中显示的 PSYoungGen : 288K -> 0K，可以看出，Full GC 后，新生代的内存使用变成
0K 了 ( 0K，零 K，有没有人看成是英文的 OK 的 ? 好吧。我承认我第一次看的时候以为是英文的 OK，当时还特意在控制台打印 0K 和 OK 来确认。最后发现英文的 O 长得比阿拉伯数字的 0 要丰满和胖一些。现在印象还是比较深刻的。好像。。我跑题了 ~~ )
刚刚说到 Full GC 后，新生代的内存使用从 288K 变成 0K 了，那么这 288K 到底哪去了 ? 难道都被 GC 当成垃圾回收掉了 ? 当然不是了。我还特意在 main 方法中 new 了一个 Test 类的实例，这里的 Test 类的实例属于小对象，它应该被分配到新生代内存当中，现在还在调用这个实例的 doTest 方法呢，GC 不可能在这个时候来回收它的。
接着往下看 Full GC 的信息，会发现一个很有趣的现象，PSOldGen: 0K -> 160K，可以看到，Full GC 后，老年代的内存使用从 0K 变成了 160K，想必你已经猜到大概是怎么回事了。当 Full GC 进行的时候，默认的方式是尽量清空新生代 ( YoungGen )，因此在调 System.gc() 时，新生代 ( YoungGen ) 中存活的对象会提前进入老年代。
第 23 行触发的 Minor GC 收集分析：
从信息 PSYoungGen : 2703K -> 1056K，可以知道，在第 21 行创建的，大小为 1M 的数组被 GC 回收了。在第 22 行创建的，大小也为 1M 的数组由于 bytes 引用变量还在引用它，因此，它暂时未被 GC 回收。
第 23 行触发的 Full GC 收集分析：
在 Minor GC 的时候，信息显示 PSYoungGen : 2703K -> 1056K，Full GC 中显示的 PSYoungGen : 1056K -> 0K，以及 PSOldGen: 160K -> 1184K，可以知道，新生代 ( YoungGen ) 中存活的对象又提前进入老年代了。

GC算法

新生代可用GC

1）串行GC(Serial Copying)：

client模式下默认GC方式，也可通过-XX:+UseSerialGC来强制指定；默认情况下 eden、s0、s1的大小通过-XX:SurvivorRatio来控制，默认为8，含义
为eden:s0的比例，启动后可通过jmap –heap [pid]来查看。

默认情况下，仅在TLAB或eden上分配，只有两种情况下会在老生代分配：

1、需要分配的内存大小超过eden space大小；
2、在配置了PretenureSizeThreshold的情况下，对象大小大于此值。

默认情况下，触发Minor GC时：
之前Minor GC晋级到old的平均大小 < 老生代的剩余空间 < eden+from Survivor的使用空间。当HandlePromotionFailure为true，则仅触发minor gc；如为false，则触发full GC。

默认情况下，新生代对象晋升到老生代的规则：

1、经历多次minor gc仍存活的对象，可通过以下参数来控制：以MaxTenuringThreshold值为准，默认为15。
2、to space放不下的，直接放入老生代；

**2）并行GC（ParNew）：

GC时默认采用，也可采用-XX:+UseParNewGC强制指定；垃圾回收的时候采用多线程的方式。

3）并行回收GC(Parallel Scavenge)：

server模式下默认的GC方式，也可采用-XX:+UseParallelGC强制指定；eden、s0、s1的大小可通过-XX:SurvivorRatio来控制，但默认情况下
以-XX:InitialSurivivorRatio为准，此值默认为8，代表的为新生代大小 : s0，这点要特别注意。

默认情况下，当TLAB、eden上分配都失败时，判断需要分配的内存大小是否 >= eden space的一半大小，如是就直接在老生代上分配；

默认情况下的垃圾回收规则：

1. 在回收前PS GC会先检测之前每次PS GC时，晋升到老生代的平均大小是否大于老生代的剩余空间，如大于则直接触发full GC；
2. 在回收后，也会按照上面的规则进行检测。

默认情况下的新生代对象晋升到老生代的规则：

1. 经历多次minor gc仍存活的对象，可通过以下参数来控制：AlwaysTenure，默认false，表示只要minor GC时存活，就晋升到老生代；NeverTenure，默认false，表示永不晋升到老生代；上面两个都没设置的情冴下，如UseAdaptiveSizePolicy，启动时以InitialTenuringThreshold值作为存活次数的阈值，在每次ps gc后会动态调整，如不使用UseAdaptiveSizePolicy，则以MaxTenuringThreshold为准。

2. to space放不下的，直接放入老生代。在回收后，如UseAdaptiveSizePolicy，PS GC会根据运行状态动态调整eden、to以及TenuringThreshold的大小。如果不希望动态调整可设置-XX:-UseAdaptiveSizePolicy。如希望跟踪每次的变化情况，可在启劢参数上增加： PrintAdaptiveSizePolicy。

二、老生代可用GC

1、串行GC(Serial Copying)：
client方式下默认GC方式，可通过-XX:+UseSerialGC强制指定。

触发机制：

1. old gen空间不足；
2. perm gen空间不足；
3. minor gc时的悲观策略；
4. minor GC后在eden上分配内存仍然失败；
5. 执行heap dump时；
6. 外部调用System.gc，可通过-XX:+DisableExplicitGC来禁止。

2、并行回收GC(Parallel Scavenge)： server模式下默认GC方式，可通过-XX:+UseParallelGC强制指定； 并行的线程数为当cpu core<=8 ? cpu core : 3+(cpu core*5)/8或通过-XX:ParallelGCThreads=x来强制指定。如ScavengeBeforeFullGC为true（默认值），则先执行minor GC。

3、并行Compacting：
可通过-XX:+UseParallelOldGC强制指定。

4、并发CMS：
可通过-XX:+UseConcMarkSweepGC来强制指定。并发的线程数默认为:( 并行GC线程数+3)/4，也可通过ParallelCMSThreads指定。

触发机制：

1. 当老生代空间的使用到达一定比率时触发；
   Hotspot V 1.6中默认为65%，可通过PrintCMSInitiationStatistics（此参数在V 1.5中不能用）来查看这个值到底是多少；可通过CMSInitiatingOccupancyFraction来强制指定，默认值并不是赋值在了这个值上，是根据如下公式计算出来的： ((100 - MinHeapFreeRatio) +(double)(CMSTriggerRatio * MinHeapFreeRatio) / 100.0)/ 100.0; 其中,MinHeapFreeRatio默认值： 40 CMSTriggerRatio默认值： 80。

2. 当perm gen采用CMS收集且空间使用到一定比率时触发；
   perm gen采用CMS收集需设置：-XX:+CMSClassUnloadingEnabled Hotspot V 1.6中默认为65%；可通过CMSInitiatingPermOccupancyFraction来强制指定，同样，它是根据如下公式计算出来的：((100 - MinHeapFreeRatio) +(double)(CMSTriggerPermRatio* MinHeapFreeRatio) / 100.0)/ 100.0; 其中，MinHeapFreeRatio默认值： 40 CMSTriggerPermRatio默认值： 80。

3. Hotspot根据成本计算决定是否需要执行CMS GC；可通过-XX:+UseCMSInitiatingOccupancyOnly来去掉这个动态执行的策略。

4. 外部调用了System.gc，且设置了ExplicitGCInvokesConcurrent；需要注意，在hotspot 6中，在这种情况下如应用同时使用了NIO，可能会出现bug。

WEB SERVER 选择并行GC + CMS即可

默认GC组合

可选的GC组合

GC监测

命令行工具

jstat –gcutil [pid] [intervel] [count]
-verbose:gc // 可以辅助输出一些详细的GC信息； -XX:+PrintGCDetails // 输出GC详细信息； -XX:+PrintGCApplicationStoppedTime // 输出GC造成应用暂停的时间 -XX:+PrintGCDateStamps // GC发生的时间信息； -XX:+PrintHeapAtGC // 在GC前后输出堆中各个区域的大小； -Xloggc:[file] // 将GC信息输出到单独的文件中，建议都加上，这个消耗不大，而且对查问题和调优有很大的帮助。gc的日志拿下来后可使用GCLogViewer或gchisto进行分析。

也可以用图形化工具jvisualvm进行分析

系统调优方法

调优步骤：

1. 评估现状
2. 设定目标
3. 尝试调优
4. 衡量调优
5. 细微调整

设定目标：

1. 降低Full GC的执行频率？
2. 降低Full GC的消耗时间？
3. 降低Full GC所造成的应用停顿时间？
4. 降低Minor GC执行频率？
5. 降低Minor GC消耗时间？
   例如某系统的GC调优目标：降低Full GC执行频率的同时，尽可能降低minor GC的执行频率、消耗时间以及GC对应用造成的停顿时间。

衡量调优：

1、衡量工具
1）打印GC日志信息：-XX:+PrintGCDetails –XX:+PrintGCApplicationStoppedTime -Xloggc: {文件名} -XX:+PrintGCTimeStamps

2）jmap：（由于每个版本jvm的默认值可能会有改变，建议还是用jmap首先观察下目前每个代的内存大小、GC方式）  3）运行状况监测工具：jstat、jvisualvm、sar 、gclogviewer

2、应收集的信息
1）minor gc的执行频率；full gc的执行频率，每次GC耗时多少？

2）高峰期什么状况？ 3）minor gc回收的效果如何？survivor的消耗状况如何，每次有多少对象会进入老生代？ 4）full gc回收的效果如何？（简单的memory leak判断方法） 5）系统的load、cpu消耗、qps or tps、响应时间

QPS每秒查询率：是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。在因特网上，作为域名服务器的机器性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
TPS(Transaction Per Second)：每秒钟系统能够处理的交易或事务的数量。

尝试调优：

注意Java RMI的定时GC触发机制，可通过：-XX:+DisableExplicitGC来禁止或通过 -Dsun.rmi.dgc.server.gcInterval=3600000来控制触发的时间。

1）降低Full GC执行频率 – 通常瓶颈
老生代本身占用的内存空间就一直偏高，所以只要稍微放点对象到老生代，就full GC了；
通常原因：系统缓存的东西太多；
例如：使用oracle 10g驱动时preparedstatement cache太大；
查找办法：现执行Dump然后再进行MAT分析；

（1）Minor GC后总是有对象不断的进入老生代，导致老生代不断的满
通常原因：Survivor太小了
系统表现：系统响应太慢、请求量太大、每次请求分配的内存太多、分配的对象太大…
查找办法：分析两次minor GC之间到底哪些地方分配了内存；
利用jstat观察Survivor的消耗状况，-XX:PrintHeapAtGC，输出GC前后的详细信息；
对于系统响应慢可以采用系统优化，不是GC优化的内容；

（2）老生代的内存占用一直偏高
调优方法：① 扩大老生代的大小（减少新生代的大小或调大heap的 大小）；
减少new注意对minor gc的影响并且同时有可能造成full gc还是严重；
调大heap注意full gc的时间的延长，cpu够强悍嘛，os是32 bit的吗？
② 程序优化（去掉一些不必要的缓存）

（3）Minor GC后总是有对象不断的进入老生代
前提：这些进入老生代的对象在full GC时大部分都会被回收
调优方法：
① 降低Minor GC的执行频率；
② 让对象尽量在Minor GC中就被回收掉：增大Eden区、增大survivor、增大TenuringThreshold；注意这些可能会造成minor gc执行频繁；
③ 切换成CMS GC：老生代还没有满就回收掉，从而降低Full GC触发的可能性；
④ 程序优化：提升响应速度、降低每次请求分配的内存、

（4）降低单次Full GC的执行时间
通常原因：老生代太大了…
调优方法：1）是并行GC吗？ 2）升级CPU 3）减小Heap或老生代

（5）降低Minor GC执行频率
通常原因：每次请求分配的内存多、请求量大
通常办法：1）扩大heap、扩大新生代、扩大eden。注意点：降低每次请求分配的内存；横向增加机器的数量分担请求的数量。

（6）降低Minor GC执行时间
通常原因：新生代太大了，响应速度太慢了，导致每次Minor GC时存活的对象多
通常办法：1）减小点新生代吧；2）增加CPU的数量、升级CPU的配置；加快系统的响应速度

细微调整：

首先需要了解以下情况：

① 当响应速度下降到多少或请求量上涨到多少时，系统会宕掉？

② 参数调整后系统多久会执行一次Minor GC，多久会执行一次Full GC，高峰期会如何？

需要计算的量：

①每次请求平均需要分配多少内存？系统的平均响应时间是多少呢？请求量是多少、多常时间执行一次Minor GC、Full GC？

②现有参数下，应该是多久一次Minor GC、Full GC，对比真实状况，做一定的调整；

必杀技：提升响应速度、降低每次请求分配的内存？

垃圾回收的实现原理

内存回收的实现方法：1）引用计数：不适合复杂对象的引用关系，尤其是循环依赖的场景。2）有向图Tracing：适合于复杂对象的引用关系场景，Hotspot采用这种。常用算法：Copying、Mark-Sweep、Mark-Compact。

Hotspot从root set开始扫描有引用的对象并对Reference类型的对象进行特殊处理。以下是Root Set的列表：
1）当前正在执行的线程；
2）全局/静态变量；
3）JVM Handles；
4）JNI 【 Java Native Interface 】Handles；

另外：minor GC只扫描新生代，当老生代的对象引用了新生代的对象时，会采用如下的处理方式：在给对象赋引用时，会经过一个write barrier的过程，以便检查是否有老生代引用新生代对象的情况，如有则记录到remember set中。并在minor gc时，remember set指向的新生代对象也作为root set。

新生代串行GC(Serial Copying)：

新生代串行GC(Serial Copying)完整内存的分配策略：

1）首先在TLAB（本地线程分配缓冲区）上尝试分配；

2）检查是否需要在新生代上分配，如需要分配的大小小于PretenureSizeThreshold，则在eden区上进行分配，分配成功则返回；分配失败则继续；

3）检查是否需要尝试在老生代上分配，如需要，则遍历所有代并检查是否可在该代上分配，如可以则进行分配；如不需要在老生代上尝试分配，则继续；

4）根据策略决定执行新生代GC或Full GC，执行full gc时不清除soft Ref；

5）如需要分配的大小大于PretenureSizeThreshold，尝试在老生代上分配，否则尝试在新生代上分配；

6）尝试扩大堆并分配；

7）执行full gc，并清除所有soft Ref，按步骤5继续尝试分配。

新生代串行GC(Serial Copying)完整内存回收策略
1）检查to是否为空，不为空返回false；

2）检查老生代剩余空间是否大于当前eden+from已用的大小，如大于则返回true，如小于且HandlePromotionFailure为true，则检查剩余空间是否大于之前每次minor gc晋级到老生代的平均大小，如大于返回true，如小于返回false。

3）如上面的结果为false，则执行full gc；如上面的结果为true，执行下面的步骤；

4）扫描引用关系，将活的对象copy到to space，如对象在minor gc中的存活次数超过tenuring_threshold或分配失败，则往老生代复制，如仍然复制失败，则取决于HandlePromotionFailure，如不需要处理，直接抛出OOM，并退出vm，如需处理，则保持这些新生代对象不动；

新生代可用GC-PS

完整内存分配策略
1）先在TLAB上分配，分配失败则直接在eden上分配；

2）当eden上分配失败时，检查需要分配的大小是否 >= eden space的一半，如是，则直接在老生代分配；

3）如分配仍然失败，且gc已超过频率，则抛出OOM；

4）进入基本分配策略失败的模式；

5）执行PS GC，在eden上分配；

6）执行非最大压缩的full gc，在eden上分配；

7）在旧生代上分配；

8）执行最大压缩full gc，在eden上分配；

9）在旧生代上分配；

10）如还失败，回到2。

最悲惨的情况，分配触发多次PS GC和多次Full GC，直到OOM。

完整内存回收策略
1）如gc所执行的时间超过，直接结束；

2）先调用invoke_nopolicy
2.1 先检查是不是要尝试scavenge；
2.1.1 to space必须为空，如不为空，则返回false；
2.1.2 获取之前所有minor gc晋级到old的平均大小，并对比目前eden+from已使用的大小，取更小的一个值，如老生代剩余空间小于此值，则返回false，如大于则返回true；
2.2 如不需要尝试scavenge，则返回false，否则继续；
2.3 多线程扫描活的对象，并基亍copying算法回收，回收时相应的晋升对象到旧生代；
2.4 如UseAdaptiveSizePolicy，那么重新计算to space和tenuringThreshold的值，并调整。

3）如invoke_nopolicy返回的是false，或之前所有minor gc晋级到老生代的平均大小 > 旧生代的剩余空间，那么继续下面的步骤，否则结束；

4）如UseParallelOldGC，则执行PSParallelCompact，如不是UseParallelOldGC，则执行PSMarkSweep。

老生代并行CMS GC：

优缺点：

1. 大部分时候和应用并发进行，因此只会造成很短的暂停时间；
2. 浮动垃圾，没办法，所以内存空间要稍微大一点；
3. 内存碎片，-XX:+UseCMSCompactAtFullCollection 来解决；
4. 争抢CPU，这GC方式就这样；
5. 多次remark，所以总的gc时间会比并行的长；
6. 内存分配，free list方式，so性能稍差，对minor GC会有一点影响；
7. 和应用并发，有可能分配和回收同时，产生竞争，引入了锁，JVM分配优先。