JVM内存分析与垃圾回收相关

堆内存


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






从图中可以看出： 堆大小 = 新生代 + 老年代。其中，堆的大小可以通过参数 –Xms、-Xmx 来指定。
本人使用的是 JDK1.6，以下涉及的 JVM 默认值均以该版本为准。
默认的，新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 )，即：新生代 ( Young ) = 1/3 的堆空间大小。
老年代 ( Old ) = 2/3 的堆空间大小。其中，新生代 ( Young ) 被细分为 Eden 和 两个 Survivor 区域，这两个 Survivor 区域分别被命名为 from 和 to，以示区分。
默认的，Edem : from : to = 8 : 1 : 1 ( 可以通过参数 –XX:SurvivorRatio 来设定 )，即： Eden = 8/10 的新生代空间大小，from = to = 1/10 的新生代空间大小。
JVM 每次只会使用 Eden 和其中的一块 Survivor 区域来为对象服务，所以无论什么时候，总是有一块 Survivor 区域是空闲着的。
因此，新生代实际可用的内存空间为 9/10 ( 即90% )的新生代空间。


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 日志


1
2
3
4
5
6
7
8
9
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 信息与 Minor 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 出当前的内存堆转储快照，以便分析用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
1 /**
 2  -Xms60m
 3  -Xmx60m
 4  -Xmn20m
 5  -XX:NewRatio=2 ( 若 Xms = Xmx, 并且设定了 Xmn, 那么该项配置就不需要配置了 )
 6  -XX:SurvivorRatio=8
 7  -XX:PermSize=30m
 8  -XX:MaxPermSize=30m
 9  -XX:+PrintGCDetails
10  */
11 public static void main(String[] args) {
12     new Test().doTest();
13 }
14
15 public void doTest(){
16     Integer M = new Integer(1024 * 1024 * 1);  //单位, 兆(M)
17     byte[] bytes = new byte[1 * M]; //申请 1M 大小的内存空间
18     bytes = null;  //断开引用链
19     System.gc();   //通知 GC 收集垃圾
20     System.out.println();
21     bytes = new byte[1 * M];  //重新申请 1M 大小的内存空间
22     bytes = new byte[1 * M];  //再次申请 1M 大小的内存空间
23     System.gc();
24     System.out.println();
25 }
按上面代码中注释的信息设定 jvm 相关的参数项，并执行程序，下面是一次执行完成控制台打印的结果：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[ 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 ) 中存活的对象又提前进入老年代了
=============================================================================================
可视化Java垃圾回收的原理和实现基础


当谈到释放不再使用的内存，垃圾回收已经在很大程度上取代了早期技术，比如手动内存管理和引用计数。


这是件好事，因为内存管理令人厌烦，学究式地簿记是计算机擅长的，而不是人擅长的。在这方面，语言的运行时环境比人强。


现代的垃圾回收非常高效，远远超过早期语言中典型的手工分配。通常，具有其它语言背景的人只盯着垃圾回收造成的中断，却没有完全理解自动内存管理发生作用的上下文环境。


标记&清除是Java（及其它运行时环境）用于垃圾回收的基本算法。


在标记&清除算法中，引用会从每个线程栈的桢指向程序的堆。所以，从栈开始，循着指针找到所有可能的引用，然后再循着这些引用递归下去。


当递归完成，就找到了所有的活对象，其它的都是垃圾。


请注意，人们经常漏掉的一点是，运行时环境本身也有一个“分配清单（allocation list）”，上面列出了指向每个对象的指针，该列表由垃圾回收器负责维护，并帮助垃圾回收器进行垃圾清理。因此，运行时环境总是可以找出由它创建但尚未回收的对象。






图一


上面插图中所示的栈只是一个与单个应用程序线程相关的栈；每个应用程序线程都有一个类似的栈，每个栈本身都有一组指向堆的指针。


如果垃圾回收器试图在应用程序运行过程中获取活对象的快照，那么它就要追踪运动着的目标，那样很容易漏掉一些严重超时的对象分配，因而无法获得一个准确的快照。因此，“Stop the World”是有必要的；也就是，停止应用程序线程足够长的时间，以便捕获活对象的快照。


下面是垃圾回收器必须遵循的两条黄金法则：


垃圾回收器必须回收所有的垃圾。
垃圾回收器必须从不回收任何活对象。
但这两条规则并不是对等的；如果违反了第二条规则，结果会使数据遭到破坏。


另一方面，如果违反了第一条规则，则会是另一种情况，系统并不总是能够回收所有的垃圾，但最终会回收所有的垃圾，那么这是可以接受的，而实际上，这是垃圾回收器的基本原理。


HotSpot


现在，我们来说下HotSpot，它实际上是一个C、C++以及许多特定于平台的汇编程序组成的混合体。


当人们想到解释器，就会想到一个很大的while循环，其中包含一个很长的switch语句。但HotSpot解释器比那个要复杂的多（由于性能原因）。在开始阅读JDK源代码的时候，就会发现HotSpot中实在是有许多汇编程序代码。


对象创建


Java会预先分配大量的连续空间，就是我们所说的“堆”。之后，HotSpot完全在用户空间里管理这块内存。


如果一个Java进程占用了大量的系统（或内核）时间，那么毫无疑问，它不是在进行垃圾回收——因为所有的垃圾回收内存“簿记（bookkeeping）”都是在用户空间进行的。


内存池






图二


“永久代（PermGen）”是一个存储区域，用于保存那些需要在程序生存期内一直存活的东西，如类的元数据。不过，随着应用程序服务器的出现，它们有自己的类加载器，并且需要重新加载类的元数据，永久代作为一个优化决策开始显得糟糕，所幸，它在Java 8中消失了。


Java 8将会使用一个名为“元空间（Metaspace）”的新概念。元空间与永久代并不完全相同。它在堆的外面，由操作系统管理。这意味着，它不会在Java堆中，而是在本地内存里。目前，这还不是一个非常好的消息，因为没有多少工具能够让用户轻松地查看本地内存。所以，永久代消失是件好事，但工具赶上这个变化还需要一些时间。


Java堆布局


现在，我们来看下Java堆。注意堆空间之间的虚拟空间。它们提供了一点浮动量，以允许对内存池进行一定量的尺寸调整，又不用为任何对象移动付出代价。






图三


“弱代假设（Weak Generational Hypothesis）”


就现状而言，究竟为什么要将堆分成所有这些内存池？






图四


有的运行时事实无法通过静态分析推导出来。上面的插图说明有两组对象：一组存活时间短，一组存活时间长——所以，做额外的簿记以便利用这一事实是有意义的。在Java平台中，有许多类似的作为优化写入平台的事实。


演示


Ben Evans进行了一系列的动画演示。第一个演示是个Flash，说明了对象在Eden区和一个新生代Survivor空间之间移动，并最终进入老年代的过程。


图五是用JavaFX再现了同样的过程。






图五


运行时开关


‘强制性’参数


-verbose：gc——为用户输出一些GC信息
-Xloggc:<文件路径>——指定日志输出路径，要确保磁盘有空间
-XX：+PringGCDetails——为辅助工具提供“最低限度信息（Minimum information）”——用这个参数代替-verbose：gc
–XX：PrintTenuringDistribution——“过早提升（Premature promotion）”信息
基本堆大小参数


-Xms<size> —— 设置预留给堆的最小内存值
-Xmx<size> —— 设置预留给堆的最大内存值
-XX:MaxPermSize=<size>——设置永久代的最大内存值——有利于Spring应用程序和应用服务器
以前，我们被教导要把-Xms和-Xmx的值设的一样大。不过这已经变了。因此，现在可以为-Xms设置一个合理范围内较小的值，或者根本就不设置，因为堆的适应能力现在已经非常好了。


其它参数


-XX:NewRatio=N
-XX:NewSize=N
-XX:MaxNewSize=N
-XX:MaxHeapFreeRatio
-XX:MinHeapFreeRatio
-XX:SurvivorRatio=N
-XX:MaxTenuringThreshold=N




图六


为什么要有日志文件


日志文件的好处是能够用于取证分析，可以使用户免于为了再现问题而不得不再执行一次代码（如果是一个罕见的生产环境错误，那么重现并不容易）。


另外，它们包含的信息比针对内存的JMX MXBeans所能提供的信息更多，且不说轮询JMX本身会引入一系列GC问题。


工具


HP JMeter（用Google查询一下）——免费，非常可靠，但不再提供支持/功能增强
GCViewer——免费，开源，但界面有点丑
GarbageCat——名字最好听
IBM GCMV——支持J9
jClarity Censum——界面最美观，而且最有用——不过，这是我们的偏见！
小结


需要了解一些GC基础理论
要让新生代的大部分对象在年轻时死亡
打开GC日志！——原始日志文件难以阅读——使用工具
使用工具来帮助自己调优——测量，而不是猜测
============================================================================================
Java堆外内存
堆外内存其实并无特别之处。线程栈，应用程序代码，NIO缓存用的都是堆外内存。事实上在C或者C++中，你只能使用未托管内存，因为它们默认是没有托管堆（managed heap）的。在Java中使用托管内存或者“堆”内存是这门语言的一个特性。注意：Java并非唯一这么做的语言。


new Object() vs 对象池 vs 堆外内存


new Object()
在Java 5.0以前，对象池一度非常流行。那个时候创建对象的开销是非常昂贵的。然而，从Java 5.0以后，对象创建及垃圾回收已经变得非常廉价了，开发人员发现性能得到了提升后，便简化了代码，废弃了对象池，需要的时候就去创建新的对象就好了。在Java 5.0以前，几乎所有对象，包括对象池本身，都通过对象池来提升性能，而在5.0以后，只有那些特别昂贵的对象才有必要池化了，比方说线程，Socket，以及数据库连接。


对象池
在低时延领域它仍是有一定的用武之处的，由于可变对象的循环使用减轻了CPU缓存的压力，进而使得性能得到了提升。这些对象的生命周期和结构都必须尽可能简单，但这么做之后你会发现系统性能及抖动都会得到大幅度的改善。


还有一个领域也比较适合使用对象池，譬如需要加载海量数据且其中包含许多冗余对象时。使用对象池能显著减少内存的使用量以及需要GC的对象数，进而换来更短的GC时间以及更高的吞吐量。


这类对象池通常都会设计得比较轻量级，而非简单地使用一个同步的HashMap，因此它们仍是有存在的价值的。


拿StringInterner类来作一个例子。你可以将一个包含你想要的文本的可重复使用的可变StringBuilder作为参数传给它，它会返回你一个匹配的字符串。直接传递String对象的效率会很低，因为你已经把这个对象创建出来了。StringBuilder则是可以重复使用的。


注意：这个结构有一个很有意思的特性就是它不需要额外的线程安全的机制，比方说volatile或者synchronized，仅需Java所保障的最低限度的线程安全就足够了。你能正确地访问到String内部的final字段，顶多就是读到了不一致的引用而已。


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public class StringInterner {
    private final String[] interner;
    private final int mask;
    public StringInterner(int capacity) {
        int n = Maths.nextPower2(capacity, 128);
        interner = new String[n];
        mask = n - 1;
    }
 
    private static boolean isEqual(@Nullable CharSequence s, @NotNull CharSequence cs) {
        if (s == null) return false;
        if (s.length() != cs.length()) return false;
        for (int i = 0; i < cs.length(); i++)
            if (s.charAt(i) != cs.charAt(i))
                return false;
        return true;
    }
 
    @NotNull
    public String intern(@NotNull CharSequence cs) {
        long hash = 0;
        for (int i = 0; i < cs.length(); i++)
            hash = 57 * hash + cs.charAt(i);
        int h = (int) Maths.hash(hash) & mask;
        String s = interner[h];
        if (isEqual(s, cs))
            return s;
        String s2 = cs.toString();
        return interner[h] = s2;
    }
}
堆外内存的使用


使用堆外内存与对象池都能减少GC的暂停时间，这是它们唯一的共同点。生命周期短的可变对象，创建开销大，或者生命周期虽长但存在冗余的可变对象都比较适合使用对象池。生命周期适中，或者复杂的对象则比较适合由GC来进行处理。然而，中长生命周期的可变对象就比较棘手了，堆外内存则正是它们的菜。


堆外内存的好处是：


可以扩展至更大的内存空间。比如超过1TB甚至比主存还大的空间。
理论上能减少GC暂停时间。
可以在进程间共享，减少JVM间的对象复制，使得JVM的分割部署更容易实现。
它的持久化存储可以支持快速重启，同时还能够在测试环境中重现生产数据。
站在系统设计的角度来看，使用堆外内存可以为你的设计提供更多可能。最重要的提升并不在于性能，而是决定性的。


堆外内存及测试
高性能计算领域最大的一个难点在于重现那些隐蔽的BUG，并证实问题已经得到修复。通过将输入事件及数据以持久化的形式存储到堆外内存中，你可以将你的关键系统变成一系列的复杂状态机。（简单的情况下只有一个状态机）。这样的话在测试环境便能够复现出生产环境出现的行为及性能问题了。


许多投行都通过这项技术来可靠地重现当天系统对某个事件的响应，并分析出该事件之所以这么处理的原因。更为重要的是，你能够立即证明线上的故障已经得到了解决，而不是发现一个问题后，寄希望于它就是引发线上故障的根源。确定性的行为还伴随着确定性的性能。


你可以在测试环境中按照真实的时间来回放事件，由此得到的时延分布也必定是生产环境中所出现的。由于硬件的不同，一些系统的抖动可能难以复现，不过这在数据分析的角度而言已经相当接近真实的情况了。为了避免出现花一整天的时间来回话前一天的数据的情况，你还可以增加一个阈值，比方说，如果两个事件的间隔超过10ms的话你可以就只等待10ms。这样你能够在一个小时内根据实际的时间来回放出一天的事件，来检查下你的改动是否对时延分布有所改善。


这样做是否就损失了“一次编译，处处执行”的好处了?
一定程度上来讲是这样的，但其实的影响比你想像的要小得多。越接近处理器，你就更依赖于处理器或者操作系统的行为。所幸的是，绝大多数系统使用的都是AMD/Intel的CPU，甚至是ARM处理器在底层上也越来越与这两家兼容了。操作系统之间也存在差别，因此相对于Windows而言，这项技术更适合在Linux系统上使用。如果你是在Mac OS X或者Windows上开发，然后生产环境是部署在Linux上的话，就一点问题都没有了。我们在Higher Frequency Trading中也是这么做的。


使用堆外内存会引入什么新的问题
天下没有免费的午餐，堆外内存也不例外。最大的问题在于你的数据结构变得有些别扭。要么就是需要一个简单的数据结构以便于直接映射到堆外内存，要么就使用复杂的数据结构并序列化及反序列化到内存中。很明显使用序列化的话会比较头疼且存在性能瓶颈。使用序列化比使用堆对象的性能还差。


在金融领域，许多高频率的数据都是扁平的简单结构，全部由基础类型组成，非常适合映射到堆外内存。然而，并非所有的应用程序都是这样的，可能会有一些嵌套得很深的数据结构，比如说图，你还不得不将这些对象缓存在堆上。


另外一个问题就是JVM会制约到你对操作系统的使用。你不用再担心JVM会给系统造成过重的负载。使用堆外内存后，某些限制已经不复存在了，你可以使用比主存还大的数据结构，不过如果你这么做的话又得考虑一下使用的是什么磁盘子系统了。比如说，你肯定不会希望分页到一块只有80 IOPS（Input/Ouput Operations per Second，每秒的IO操作）的HDD硬盘上，最好是IOPS能到80，000的SSD硬盘，当然了，1000x的话更好。


OpenHFT能做些什么？


OpenHFT包含许多类库，它们向你屏蔽了使用本地内存来存储数据的细节。这些数据结构都是持久化的，使用它们不会产生垃圾或者只有很少。使用了它的应用程序可以运行一整天也没有一次Minor GC.


Chronicle Queue——持久化的事件队列。支持同一台机器上多个JVM的并发写，以及多台机器间的并发读。微秒级的延迟，并能持续保持每秒上百万消息的吞吐量。


Chronicle Map——kv表的本地或持久化存储。它能在同一台机器的不同JVM间共享，数据是通过UDP或者TCP来复制的，并通过TCP来进行远程访问。微秒级的延迟，单台机器能保持每秒百万级的读写操作。


Thread Affinity ——将关键线程绑定到独立的CPU核或者逻辑CPU上，以减少系统抖动。抖动可以减小到原来的千分之一。


使用哪个API？


如果你需要记录每个事件的话 ——> Chronicle Queue


如果你只需要某个唯一主键最近的一条结果 ——> Chronicle Map


如果你更关心那20微秒的抖动的话 ——> Thread Affinity


总结


堆外内存是把双刃剑。它的价值你已经看到了，可以和别的实现可伸缩性的方案进行下比较。与在堆缓存或者消息队列，甚至是进程外的数据库中进行分区/分片相比，使用堆外内存要更为简单高效。不仅如此，以前用来提升性能的某些技巧也已经不再需要了。比如说，堆外内存可以支持操作系统的同步写，就不再需要异步去执行了，那样还会面临数据丢失的风险。不过最大的好处应该就是启动时间了，生产环境下的系统的重启速度会大大缩短，映射1 TB的数据只需要10毫秒，同时你还能在测试环境按生产环境的顺序复现每一个事件，以还原线上现场。通过它你可以建立起一个可靠的质量体系。