JVM的DirectMemory设置
几台服务器的JVM占用内存总是持续增长，大大超过-Xmx设定的值，服务器物理内存几乎被耗尽。
使用jmap查看JVM的内存使用，发现jvm的堆大小完全在-Xmx参数设定的范围之内，那问题只能处在别的地方了。
JVM除了堆内存之外，就只有栈内存和DirectMemory了。栈空间每个线程是固定的，线程数也没可能多到可以占用这么多内存的程序，所以怀疑的目标就在DirectMemory上了。
DirectMemory是java nio引入的，直接以native的方式分配内存，不受jvm管理。这种方式是为了提高网络和文件IO的效率，避免多余的内存拷贝而出现的。DirectMemory占用的大小没有直接的工具或者API可以查看，不过这个在Bits类中是有两个字段存储了最大大小和已分配大小的，使用反射可以拿到这个数据：
Class<?> c = Class.forName("java.nio.Bits");
Field maxMemory = c.getDeclaredField("maxMemory");
maxMemory.setAccessible(true);
Field reservedMemory = c.getDeclaredField("reservedMemory");
reservedMemory.setAccessible(true);
Long maxMemoryValue = (Long)maxMemory.get(null);
Long reservedMemoryValue = (Long)reservedMemory.get(null);
结果证实了猜测，DirectMemory增长失控了。
原来，DirectMemory 的默认大小是64M，而JDK6之前和JDK6的某些版本的SUN JVM，存在一个BUG，在用-Xmx设定堆空间大小的时候，也设置了DirectMemory的大小。加入设置了-Xmx2048m，那么jvm最终可分配的内存大小为4G多一些，是预期的两倍。
解决方式是设置jvm参数-XX:MaxDirectMemorySize=128m，指定DirectMemory的大小。
UseCompressedOops
通常64位JVM消耗的内存会比32位的大1.5倍，这是因为对象指针在64位架构下，长度会翻倍（更宽的寻址）。
对于那些将要从32位平台移植到64位的应用来说，平白无辜多了1/2的内存占用，这是开发者不愿意看到的。
幸运的是，从JDK 1.6 update14开始，64 bit JVM正式支持了 -XX:+UseCompressedOops 这个可以压缩指针，起到节约内存占用的新参数。
什么是 OOP ?
OOP = “ordinary object pointer” 普通对象指针。
启用CompressOops后，会压缩的对象：
• 每个Class的属性指针（静态成员变量）
• 每个对象的属性指针
• 普通对象数组的每个元素指针
当然，压缩也不是万能的，针对一些特殊类型的指针，JVM是不会优化的。
比如指向PermGen的Class对象指针，本地变量，堆栈元素，入参，返回值，NULL指针不会被压缩。
怎么启用？
在启动java时，加 -XX:+UseCompressedOops (需要jdk1.6.0_14)
CompressedOops的原理
原理，解释器在解释字节码时，植入压缩指令（不影响正常和JVM优化后的指令顺序）。
具体逻辑是，当对象被读取时，解压，存入heap时，压缩。
压缩指令伪码
! int R8; oop[] R9; // R9 is 64 bits
! oop R10 = R9[R8]; // R10 is 32 bits
! load compressed ptr from wide base ptr:
movl R10, [R9 + R8<<3 + 16]
! klassOop R11 = R10._klass; // R11 is 32 bits
! void* const R12 = GetHeapBase();
! load compressed klass ptr from compressed base ptr:
movl R11, [R12 + R10<<3 + 8]
零基压缩优化(Zero Based Compressd Oops)
零基压缩是针对压解压动作的进一步优化。
它通过改变正常指针的随机地址分配特性，强制从零开始做分配（需要OS支持），进一步提高了压解压效率。
要启用零基压缩，你分配给JVM的内存大小必须控制在4G以上，32G以下。
如果小于4G，那么JVM会使用低虚拟地址空间（low virutal address space，64位下模拟32位），这样就不需要做压解压动作了。
而对于大于32G，将采用默认的随机地址分配特性，进行压解压。
适用场景
CompressedOops，可以让跑在64位平台下的JVM，不需要因为更宽的寻址，而付出Heap容量损失的代价。
不过，它的实现方式是在机器码中植入压缩与解压指令，可能会给JVM增加额外的开销。
-XX:+UseParallelGC与 -XX:+UseParNewGC相关介绍
首先看一个图（所有的垃圾回收器，以及工作的堆空间）
对于我们默认（jdk1.7）使用parallel 垃圾回收器，old区就是使用的是parallel old, yong区使用的是parallel Scavenge
使用-XX:+UseParallelGC与 -XX:+UseParNewGC设置的区别在于：
---------------------------------------------------------------------------------------------------------------------------------------
-XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。可以同时并行多个垃圾收集线程，但此时用户线程必须停止。
-XX:+UseParNewGC:设置年轻代为多线程收集。可与CMS收集同时使用。在serial基础上实现的多线程收集器。
-----------------------------------------------------------------------------------------------------------------
-XX:+UseParallelGC
指 定在 New Generation 使用 parallel collector, 并行收集 , 暂停 app threads, 同时启动多个垃圾回收 thread, 不能和 CMS gc 一起使用 . 系统吨吐量优先 , 但是会有较长长时间的 app pause, 后台系统任务可以使用此 gc。UseParallelGC是jdk1.7选择parallel 回收器默认开启的。
-XX:+UseParNewGC
指定在 New Generation 使用 parallel collector, 是 UseParallelGC 的 gc 的升级版本 , 有更好的性能或者优点 , 可以和 CMS gc 一起使用。UseParNewGC需要用户自己手动开启。
---------------------