JVM内存不要超过32G

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等)之间移动数据的时候,会占用更多的带宽

  • 让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位,以降低堆的占用空间。其伪代码原理就不贴了,

在堆大小在[4G~32G]的时候,这项技术会被触发,在JVM执行时加入编/解码指令,即

JVM在将对象存入堆时编码,在堆中读取对象时解码

内存地址确定公式类似于

1
<narrow-oop-base(64bits)> +(<narrow-oop(32bits)><< 3) +<field-offset>

Zero Based Compressed OOPS(零基压缩优化)则进一步将基地址置为0(并不一定是内存空间地址为0,只是JVM相对的逻辑地址为0,如可用CPU的寄存器相对寻址) 这样转换公式变为:

1
(<narrow-oop << 3) +<field-offset>

从而进一步提高了压解压效率。


使用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增加额外的开销

 

阅读更多
文章标签: jvm
个人分类: jvm
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

不良信息举报

JVM内存不要超过32G

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭