从off-heap到Azul's Zing(JVM)
参阅下面文章：
《Difference between “on-heap” and “off-heap”》
《JVM性能优化,Java的伸缩性》
《Azul Offers Free Zing JVM to Open Source Community Projects》
《The Azul Garbage Collector》
《Java Garbage Collection Basics》
Java语言是一种自动内存管理算法，JVM负责内存的分配与释放。当前在HotSpot下，不管采用哪种垃圾收集器，都总会存在一个Stop-the-word的停顿期。而且随着JVM实例需要管理的Heap越大，这种pasue time会越长，就目前来看当分配给应用系统的内存超过4G时，JVM在管理上显得有些乏力，pause time显得有些难于接受。显然通过各种jvm调优，在某种特殊的情况下能得到改善，但此法总显得捉襟见肘。并且JVM里边各参数调谐，像打太极，没有通用的调谐原则，Oracle提供了一个极富弹性的虚拟机我们，可我们会挣扎在JVM中各类参数的泥沼中。
面对这个问题，分布式系统一个普遍采取的部署架构就是：多服务实例部署。在一个物理服务器上，部署多个应用实例，每个应用实例分配一小块内存。这种部署架构带来的问题是运维成本的增加，另一个问题就是，面对有大量内存需求的分布式系统（比如HBase），依然不治本。
另一种则是off-heap技术。处于Java Heap上的对象实例都要受GC管理，反之如果我们对象实例置于Java Heap之外，则可避开GC的管理，从而减少GC需要扫描与回收的整个Heap空间，减少pasue time。置于Java Heap之外的对象，虽然在分配与访问上没有比在Java Heap内的对象快，但由于都是驻留在内存上，所以也只是慢一点点。这种技术可带来可观的性能收益。随着大数据分布式技术盛行，对获得持续稳定的性能吞吐的要求，在采用HotSpot的系统中，此技术会越来越重视。
可以说off-heap也是一种治标不治本的技术，它仅仅绕开了JVM的自动内存管理机制而已，尽管采用的实现技术不同，一个没法回避的问题时增加了额外的对off-heap部分内存空间的管理负担，并且这种管理是否健壮也存在一定的风险。并且这也破坏的Java一直提倡的自动内存管理的美感哲学。仔细分析，pause time的引入还是JVM自身实现的问题，我们应该从JVM内部挖解决此问题的方法，而不应该把问题抛到界外。
Azul Systems公司推出的JVM(取名Zing)，据说能很好的解决这个问题。Zing引入了一系列优秀的垃圾收集机制，使得应用系统能尽情使用需要的内存容量，而不会让pasue time太长。唯一的不足貌似Zing是非开源，但作为开源项目可以免费使用。