0、引言
在规划ES部署的时候，会涉及到data node的分配堆内存大小，而Elasticsearch默认安装后设置的内存是1GB，对于任何一个业务部署来说，这个都太小了。
设置Heap Size的方式有两种，现将参考文献[1]摘录如下：
1) 指定ES_HEAP_SIZE环境变量。服务进程在启动时候会读取这个变量，并相应的设置堆的大小。
export ES_HEAP_SIZE=10g
2) 命令行参数的形式，在程序启动的时候把内存大小传递给它
./bin/elasticsearch -Xmx10g -Xms10g
这里的xmx和xms以前常用，但是究竟为什么要事先分配？参考文献[2]中的几个点我觉得讲的吼啊，我整理下：
a) -Xms和-Xmx设置相同时可避免Java堆自动扩展
b) 大部分 GC 算法依赖于被分配为连续的内存块的堆，因此不能在堆需要扩大时再分配更多本机内存。所有堆内存必须预先保留
c) Xmx指定内存并不是真正的分配，而是一种保留，内存保留 != 内存分配。即预先跑马圈地，并没有实际都用到。例如Xmx=512M是直接预留出512M的内存空间，但启动时的Java进程并不一定全部使用，但512M是它的“领地”。
1、那么将Java Heap Size设置的大于32G会对性能有什么影响？
开门见山的说，结果有几点（这几点其实也是内部关联）：
- 触发JVM的临界值，优化策略Compressed OOPS失效（之前Heap Size在[4G~32G]区间内采用此优化）
- 由于优化策略失效，同时堆内存>32G，所以JVM被迫使用8字节（64位）来对Java对象寻址（之前4字节（32位）就够了）
- 通常64位JVM消耗的内存会比32位的大1.5倍，这是因为对象指针在64位架构下，长度会翻倍（事实上当内存到达40-50GB的时候，有效内存才相当于使用Compressed OOPS技术时候的32G内存）
- 更大的指针在主内存和缓存器（例如LLC, L1等）之间移动数据的时候，会占用更多的带宽（参考文献[1]中表示很糟糕）
- 让JVM的GC面临更大压力的指针对象（在实际应用中构建大于12-16G的堆时，若无很好的性能调优与测评，你很容易就会引起一个耗时数分钟的完全GC）
1.1 JVM的OOPS
OOP = “ordinary object pointer” 普通对象指针
启用CompressOops后，会压缩的对象：
- 每个class的属性指针（静态成员变量）
- 每个对象的属性指针
- 普通对象数组的每个元素指针
1.2 JVM的优化策略Compressed OOPS
从JDK 1.6 update14开始，64 bit JVM正式支持了 -XX:+UseCompressedOops ，这个可以压缩指针，起到节约内存占用的新参数。
Compressed OOPS，即大雾的对象压缩技术，压缩引用到32位，以降低堆的占用空间。其伪代码原理就不贴了，在参考文献[3]中，大家自取。
在堆大小在[4G~32G]的时候，这项技术会被触发，在JVM执行时加入编/解码指令，即
JVM在将对象存入堆时编码,在堆中读取对象时解码
内存地址确定公式类似于
<narrow-oop-base(64bits)> +(<narrow-oop(32bits)><< 3) +<field-offset>
Zero Based Compressed OOPS（零基压缩优化）则进一步将基地址置为0(并不一定是内存空间地址为0,只是JVM相对的逻辑地址为0,如可用CPU的寄存器相对寻址) 这样转换公式变为：
(<narrow-oop << 3) +<field-offset>
从而进一步提高了压解压效率。
参考文献[1]中举一个简单的例子，有点像BitMap的思想，即
使用Zero Based Compressed OOPS后，它的指针不再表示对象在内存中的精确位置，而是表示偏移量。这意味着32位的指针可以引用40亿个对象，而不是40亿个字节。
1.3 Zero Based Compressed OOPS的多种策略
它可以针对不同的堆大小使用多种策略，具体可以 ps + grep查看：
- 堆小于4G，无需编/解码操作，JVM会使用低虚拟地址空间（low virutal address space，64位下模拟32位）
- 小于32G而大于4G，使用Zero Based Compressed OOPS
- 大于32G，不使用Compressed OOPS
2、结论
- Compressed OOPS，可以让跑在64位平台下的JVM，不需要因为更宽的寻址，而付出Heap容量损失的代价
- 它的实现方式是在机器码中植入压缩与解压指令，可能会给JVM增加额外的开销
- 如果希望更大的堆内存。可以考虑一台机器上创建两个或者更多ES节点（封顶32G堆内存），而不要部署一个使用32+GB内存的节点（仍然要坚持50%原则）
999、参考文献
[1] Elasticsearch 合理内存分配
[2]【原创】深入理解Java堆内存分配策略（Xmx和Xms）
[3] 主题：JVM优化之压缩普通对象指针（CompressedOops）
