如何计算java对象大小

背景

目前我们系统的业务代码中大量使用了LocalCache的方式做本地缓存，而且cache的maxSize通常设的比较大，比如10000。我们的业务系统中就使用了size为10000的15个本地缓存，所以最坏情况下将可缓存15万个对象。这会消耗掉不菲的本地堆内存，而至于实际上到底应该设多大容量的缓存、运行时这大量的本地缓存会给堆内存带来多少压力，实际占用多少内存大小，会不会有较高的缓存穿透风险，目前并不方便知悉。考虑到对缓存实际占用内存的大小能有个更直观和量化的参考，需要对运行时指定对象的内存占用进行评估和计算。

要计算Java对象占用内存的大小，首先需要了解Java对象在内存中的实际存储方式和存储格式。

另一方面，大家都了解Java对象的存储总得来说会占用JVM内存的堆内存、栈内存及方法区，但由于栈内存中存放的数据可以看做是运行时的临时数据，主要表现为本地变量、操作数、对象引用地址等。这些数据会在方法执行结束后立即回收掉，不会驻留。对存储空间空间的占用也只是执行函数指令时所必须的空间。通常不会造成内存的瓶颈。而方法区中存储的则是对象所对应的类信息、函数表、构造函数、静态常量等，这些信息在类加载时(按需)只会在方法区中存储一份，不会产生额外的存储空间。因此本文所要讨论的主要目标是Java对象对堆内存的占用。

内存占用计算方法

这里要介绍的是lucene提供的专门用于计算堆内存占用大小的工具类：RamUsageEstimator，maven坐标：

      org.apache.lucene
      lucene-core
      4.0.0

RamUsageEstimator 就是根据java对象在堆内存中的存储格式，通过计算Java对象头、实例数据、引用等的大小，相加而得，如果有引用，还能递归计算引用对象的大小。RamUsageEstimator的源码并不多，几百行，清晰可读。这里不进行一一解读了。它在初始化的时候会根据当前JVM运行环境、CPU架构、运行参数、是否开启指针压缩、JDK版本等综合计算对象头的大小，而实例数据部分则按照java基础数据类型的标准大小进行计算。思路简单，同时也在一定程度上反映出了Java对象格式的奥秘！

常用方法如下：

//计算指定对象及其引用树上的所有对象的综合大小，单位字节
long RamUsageEstimator.sizeOf(Object obj)

//计算指定对象本身在堆空间的大小，单位字节
long RamUsageEstimator.shallowSizeOf(Object obj)

//计算指定对象及其引用树上的所有对象的综合大小，返回可读的结果，如：2KB
String RamUsageEstimator.humanSizeOf(Object obj)

使用该第三方工具比较简单直接，主要依靠JVM本身环境、参数及CPU架构计算头信息，再依据数据类型的标准计算实例字段大小，计算速度很快，另外使用较方便。如果非要说这种方式有什么缺点的话，那就是这种方式计算所得的对象头大小是基于JVM声明规范的，并不是通过运行时内存地址计算而得，存在与实际大小不符的这种可能性。

Java对象格式

在HotSpot虚拟机中，Java对象的存储格式也是一个协议或者数据结构，底层是用C++代码定义的。Java对象结构大致如下图所示——

即，Java对象从整体上可以分为三个部分，对象头、实例数据和对齐填充。

对象头（Instance Header）：Java对象最复杂的一部分，采用C++定义了头的协议格式，存储了Java对象hash、GC年龄、锁标记、class指针、数组长度等信息。对象头是理解JVM中对象存储方式的最核心的部分，甚至是理解java多线程、分代GC、锁等理论的基础，也是窥探JVM底层诸多实现细节的出发点。

实例数据（Instance Data）：这部分数据才是真正具有业务意义的数据，实际上就是当前对象中的实例字段。在VM中，对象的字段是由基本数据类型和引用类型组成的。其所占用空间的大小如下所示：

说明：其中ref表示引用类型，引用类型实际上是一个地址指针，32bit机器上，占用4字节，64bit机器上，在jdk1.6之后，如果开启了指针压缩(默认开启: -XX:UseCompressedOops，仅支持64位机器)，则占用4字节。Java对象的所有字段类型都可映射为上述类型之一，因此实例数据部分的大小，实际上就是这些字段类型的大小之和。当然，实际情况可能比这个稍微复杂一点，如字段排序、内部padding以及父类字段大小的计算等。

对齐填充（Padding）：VM要求对象大小须是8的整体数，该部分是为了让整体对象在内存中的地址空间大小达到8的整数倍而额外占用的字节数。