深入了解JVM---压缩指针

什么是压缩指针

通常64位JVM消耗的内存会比32位的最多会多用1.5倍，这是因为对象指针在64位架构下，对象指针长度会翻倍。对于那些将要从32位平台移植到64位的应用来说，平白无辜多了1/2的内存占用，这是开发者不愿意看到的。幸运的是，从JDK 1.6 update14开始，
　　64 bit JVM正式支持了 -XX:+UseCompressedOops (需要jdk1.6.0_14) 这个可以压缩指针，起到节约内存占用的新参数。

什么是OOP?

OOP = “ordinary object pointer” 普通对象指针。启用CompressOops后，会压缩的对象：

※每个Class的属性指针（静态成员变量）
※每个对象的属性指针
※普通对象数组的每个元素指针

当然，压缩也不是万能的，针对一些特殊类型的指针，JVM是不会优化的。比如指向PermGen（永久代）的Class对象指针，本地变量，堆栈元素，入参，返回值，NULL指针不会被压缩。

CompressedOops的原理：

32位内最多可以表示4GB，64位地址分为堆的基地址+偏移量，当堆内存<32GB时候，在压缩过程中，把偏移量/8后保存到32位地址。在解压再把32位地址放大8倍，所以启用CompressedOops的条件是堆内存要在4GB*8=32GB以内。

所以压缩指针之所以能改善性能，是因为它通过对齐（Alignment），还有偏移量（Offset）将64位指针压缩成32位。换言之，性能提高是因为使用了更小更节省空间的压缩指针而不是完整长度的64位指针，CPU缓存使用率得到改善，应用程序也能执行得更快。

零基压缩优化(Zero Based Compressd Oops)：

零基压缩是针对压解压动作的进一步优化。它通过改变正常指针的随机地址分配特性，强制堆地址从零开始分配（需要OS支持），进一步提高了压解压效率。要启用零基压缩，你分配给JVM的内存大小必须控制在4G以上，32G以下。如果GC堆大小在4G以下，直接砍掉高32位，

避免了编码解码过程如果GC堆大小在4G以上32G以下，则启用UseCompressedOop 如果GC堆大小大于32G，压指失效，使用原来的64位（所以说服务器内存太大不好…）。

适用场景：

CompressedOops，可以让跑在64位平台下的JVM，不需要因为更宽的寻址，而付出Heap容量损失的代价。不过，它的实现方式是在机器码中植入压缩与解压指令，可能会给JVM增加额外的开销。

参考：
　　【1】https://github.com/13428282016/elasticsearch-CN/wiki/%E4%BB%80%E4%B9%88%E6%98%AFjava%E5%8E%8B%E7%BC%A9%E5%AF%B9%E8%B1%A1%E6%8C%87%E9%92%88

【2】《Java性能优化权威指南》，柳飞、陆明刚翻译

转自：https://www.cnblogs.com/happyflyingpig/p/8918675.html