Java对象占用堆内存大小计算

深碍√TFBOYSˉ_ 2023-06-17 05:51 3阅读 0赞

# 欢迎关注本人公众号 #

![在这里插入图片描述][20200515113638671.jpg_pic_center]

# 概述 #

最近在看hbase源码，里面有对象占用内存大小的计算。正好笔记记录一下。

一般来说，int占4个字节，long占8个字节，等等。但是对象在堆中的存储不止其包含的字段所占用的空间，还包括对象头，对齐填充等信息。接下来就结合hbase源码分析一下对象在堆中的存储情况。

# 原生类型(primitive type)的内存占用 #

<table> 
 <thead> 
  <tr> 
   <th>类型</th> 
   <th>占用空间</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>boolean</td> 
   <td>在数组中占1个字节，单独使用时占4个字节</td> 
  </tr> 
  <tr> 
   <td>byte</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>short</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>char</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>int</td> 
   <td>4</td> 
  </tr> 
  <tr> 
   <td>float</td> 
   <td>4</td> 
  </tr> 
  <tr> 
   <td>long</td> 
   <td>8</td> 
  </tr> 
  <tr> 
   <td>double</td> 
   <td>8</td> 
  </tr> 
 </tbody> 
</table>

## boolean占用内存空间说明 ##

《Java虚拟机规范》一书中的描述：“`虽然定义了boolean这种数据类型，但是只对它提供了非常有限的支持。在Java虚拟机中没有任何供boolean值专用的字节码指令，Java语言表达式所操作的boolean值，在编译之后都使用Java虚拟机中的int数据类型来代替，而boolean数组将会被编码成Java虚拟机的byte数组，每个元素boolean元素占8位`”。这样我们可以得出boolean类型占了单独使用是4个字节，在数组中又是1个字节。

**那虚拟机为什么要用int来代替boolean呢？为什么不用byte或short，这样不是更节省内存空间吗**。大多数人都会很自然的这样去想，我同样也有这个疑问，经过查阅资料发现，使用int的原因是，对于当下32位的处理器（CPU）来说，一次处理数据是32位（这里不是指的是32/64位系统，而是指CPU硬件层面），具有高效存取的特点。

另外也解决了伪共享问题，boolean类型的数据不会因为占用空间小而与其他数据类型的数据一起使用，注意这一点是我个人的一个猜测。欢迎来辩。

# 对象分布基本概念 #

如图，java对象在内存中占用的空间分为3类，

1.  对象头（Header）；
2.  实例数据（Instance Data）;
3.  对齐填充（Padding）。

而我们常说的基础数据类型大小主要是指第二类实例数据。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9pdDAwNy5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70]

## 对象头 ##

上图中可以看到，对象头分为三个部分：

1.  Mark Word
2.  指向类的指针
3.  数组长度（只有数组对象才有）

### Mark Word ###

Mark Word记录了对象和锁有关的信息，当这个对象被synchronized关键字当成同步锁时，围绕这个锁的一系列操作都和Mark Word有关。

Mark Word在32位JVM中的长度是32bit，在64位JVM中长度是64bit。

Mark Word在不同的锁状态下存储的内容不同，在32位JVM中是这么存的：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9pdDAwNy5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 1][]  
其中无锁和偏向锁的锁标志位都是01，只是在前面的1bit区分了这是无锁状态还是偏向锁状态。

JDK1.6以后的版本在处理同步锁时存在锁升级的概念，JVM对于同步锁的处理是从偏向锁开始的，随着竞争越来越激烈，处理方式从偏向锁升级到轻量级锁，最终升级到重量级锁。

**JVM一般是这样使用锁和Mark Word的：**

1，当没有被当成锁时，这就是一个普通的对象，Mark Word记录对象的HashCode，锁标志位是01，是否偏向锁那一位是0。

2，当对象被当做同步锁并有一个线程A抢到了锁时，锁标志位还是01，但是否偏向锁那一位改成1，前23bit记录抢到锁的线程id，表示进入偏向锁状态。

3，当线程A再次试图来获得锁时，JVM发现同步锁对象的标志位是01，是否偏向锁是1，也就是偏向状态，Mark Word中记录的线程id就是线程A自己的id，表示线程A已经获得了这个偏向锁，可以执行同步锁的代码。

4，当线程B试图获得这个锁时，JVM发现同步锁处于偏向状态，但是Mark Word中的线程id记录的不是B，那么线程B会先用CAS操作试图获得锁，这里的获得锁操作是有可能成功的，因为线程A一般不会自动释放偏向锁。如果抢锁成功，就把Mark Word里的线程id改为线程B的id，代表线程B获得了这个偏向锁，可以执行同步锁代码。如果抢锁失败，则继续执行步骤5。

5，偏向锁状态抢锁失败，代表当前锁有一定的竞争，偏向锁将升级为轻量级锁。JVM会在当前线程的线程栈中开辟一块单独的空间，里面保存指向对象锁Mark Word的指针，同时在对象锁Mark Word中保存指向这片空间的指针。上述两个保存操作都是CAS操作，如果保存成功，代表线程抢到了同步锁，就把Mark Word中的锁标志位改成00，可以执行同步锁代码。如果保存失败，表示抢锁失败，竞争太激烈，继续执行步骤6。

6，轻量级锁抢锁失败，JVM会使用自旋锁，自旋锁不是一个锁状态，只是代表不断的重试，尝试抢锁。从JDK1.7开始，自旋锁默认启用，自旋次数由JVM决定。如果抢锁成功则执行同步锁代码，如果失败则继续执行步骤7。

7，自旋锁重试之后如果抢锁依然失败，同步锁会升级至重量级锁，锁标志位改为10。在这个状态下，未抢到锁的线程都会被阻塞。

### 指向类的指针 ###

该指针在32位JVM中的长度是32bit，在64位JVM中长度是64bit。

Java对象的类数据保存在方法区（java8以后在元数据区）。

### 数组长度 ###

只有数组对象保存了这部分数据。

该数据在32位和64位JVM中长度都是32bit。

## 实例数据 ##

我们在java类中定义的属性。

## 对齐填充 ##

HotSpot的对齐方式为8字节对齐。  
8字节填充的含义也就是不足8字节（或8字节的倍数）则将其填充至8字节（或8字节的倍数，这里指的是大于当前值的最小一个8的倍数）。如：

<table> 
 <thead> 
  <tr> 
   <th>原始长度</th> 
   <th>8字节对齐后长度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>6</td> 
   <td>8</td> 
  </tr> 
  <tr> 
   <td>7</td> 
   <td>8</td> 
  </tr> 
  <tr> 
   <td>8</td> 
   <td>8</td> 
  </tr> 
  <tr> 
   <td>9</td> 
   <td>16</td> 
  </tr> 
  <tr> 
   <td>10</td> 
   <td>16</td> 
  </tr> 
 </tbody> 
</table>

我们来看一下hbase的计算对齐填充后长度的算法：

/** * Aligns a number to 8. * @param num number to align to 8 * @return smallest number >= input that is a multiple of 8 */
    public long align(long num) { 
      //The 7 comes from that the alignSize is 8 which is the number of bytes
      //stored and sent together
      return  ((num + 7) >> 3) << 3;//将数字加7后抹0（后3位0）
    }

这里采用的是二进制位运算算法，位运算在计算机内是性能最高的算法，所以在阅读开源软件时，会大量看到二进制位运算。

8字节填充的长度计算其实很简单，将数值先转为2进制，然后将倒数第四位置为1，如果本来是1则不变。然后将后三位置为0即可。

以26为例，26的二进制表述为`11010`，那么如何才能将倒数第四位置为1呢？上面算法中加上7，即可以完成进位操作，7是比8小的最大的一个数，二进制是`111`。然后进位操作以后，如何清除后面的三位置为0呢？简单，右移3位在左移3位即可完成。这也就是上述算法的实现原理。

## 指针压缩 ##

不压缩时指针占8字节。在64位开启指针压缩的情况下 -XX:+UseCompressedOops，存放Class指针的空间大小是4字节。

## 对象头占用空间总结 ##

1.  在32位系统下，存放Class指针的空间大小是4字节，MarkWord是4字节，对象头为8字节。
2.  在64位系统下，存放Class指针的空间大小是8字节，MarkWord是8字节，对象头为16字节。
3.  在64位开启指针压缩的情况下 -XX:+UseCompressedOops，存放Class指针的空间大小是4字节，MarkWord是8字节，对象头为12字节。
4.  如果对象是数组，那么额外增加4个字节。

# hbase源码分析–对象占用空间计算 #

这里先简单介绍一下下面示例的背景。  
以hbase 读取wal日志文件输出为例，里面计算了对象占用堆内存大小情况(里面的total\_size\_sum和edit heap size就是指对象占用空间的就算结果)：

{ 
    	"sequence": 15,
    	"region": "c06475acdfec83fd5a6bf6d06c796bd1",
    	"actions": [
    		{ 
    			"qualifier": "HBASE::FLUSH",
    			"vlen": 103,
    			"row": "\\x00",
    			"family": "METAFAMILY",
    			"value": "\\x08\\x00\\x12\\x02t2\\x1A c06475acdfec83fd5a6bf6d06c796bd1 \\x0E*\\x06\\x0A\\x010\\x12\\x01023t2,,1574775527767.c06475acdfec83fd5a6bf6d06c796bd1.",
    			"timestamp": 1574840582064,
    			"total_size_sum": 200
    		}
    	],
    	"table": { 
    		"name": "dDI=",
    		"nameAsString": "t2",
    		"namespace": "ZGVmYXVsdA==",
    		"namespaceAsString": "default",
    		"qualifier": "dDI=",
    		"qualifierAsString": "t2",
    		"systemTable": false,
    		"nameWithNamespaceInclAsString": "default:t2"
    	}
    }
    edit heap size: 240
    position: 283

给出对象的java代码：

public class KeyValue implements ExtendedCell, Cloneable { 
    	protected byte [] bytes = null;  // an immutable byte array that contains the KV
    	protected int offset = 0;  // offset into bytes buffer KV starts at
    	protected int length = 0;  // length of the KV starting from offset.
    	private long seqId = 0;
    //省略其他代码
    }

背景：byte数组内存储的实际字节大小为146。

那么根据上面第一节的描述，KeyValue对象占用，情况为：

> **对象头**：8（Mark Word）+4（指向类的指针，启用了压缩，所以指针占4字节，下同）=12  
> **byte\[\] 数组对象头**：8（Mark Word）+4（指向类的指针） + 4（数组长度，占4字节）=16  
> **keyvalue大小** = 12（KeyValue对象头） + 4（bytes属性对byte\[\]数组引用） + 4（int类型 offset） + 4（int类型 length ） + 8（long类型 seqId ）=32  
> **byte数组字节实际长度**：146+16=162. byte数组是一个独立的对象，所以需要对齐填充。162需要对齐填充，填充结果为 168  
> **total\_size\_sum** =  
> keyvalue大小 + bytes数组大小 = 32 + 168(byte\[\] 数组对象实际占用存储空间) = 200

edit heap size = 240 是统计的WALEdit ，源码在下面。cells 是一个ArrayList，所以在计算的时候，除了上面的200字节，还要加上ArrayList占用的空间。计算方式跟上面一样。

public class WALEdit implements HeapSize { 
    	  private ArrayList<Cell> cells = null; // KeyValue是Cell的实现类
    }

由于不同的JVM实现，或者不同的机器，不同的启动参数，都可能造成实际占用空间不同，所以需要再实际运行过程中统计真实的占用情况，而不是简单的使用上面的公式计算。

在hbase中有专门统计对象大小的工具类`ClassSize`:

REFERENCE = memoryLayout.oopSize();
    
        OBJECT = memoryLayout.headerSize();
    
        ARRAY = memoryLayout.arrayHeaderSize();
    
        ARRAYLIST = align(OBJECT + REFERENCE + (2 * Bytes.SIZEOF_INT)) + align(ARRAY);
    
    //headerSize源码：
    private static class UnsafeLayout extends MemoryLayout { 
        @SuppressWarnings("unused")
        private static final class HeaderSize { 
          private byte a;
        }
    
        public UnsafeLayout() { 
        }
    
        @Override
        int headerSize() { 
          try { //这里使用Unsafe本地方法，来获取对象中第一个元素的偏移量。
            return (int) UnsafeAccess.theUnsafe.objectFieldOffset(
              HeaderSize.class.getDeclaredField("a"));
          } catch (NoSuchFieldException | SecurityException e) { 
            LOG.error(e.toString(), e);
          }
          return super.headerSize();
        }
        //省略其他代码
    }

## ObjectFieldOffSet ##

JAVA中对象的字段的定位可能通过staticFieldOffset方法实现，该方法返回给定field的内存地址偏移量，这个值对于给定的filed是唯一的且是固定不变的。

第一个属性之前的空间也就是对象头占用的空间。以此来判断对象的大小情况更加准确一些。  
其他的也是采用类似运行时动态获取占用空间的方式，具体可以阅读hbase源码查看。

end.

[20200515113638671.jpg_pic_center]: https://img-blog.csdnimg.cn/20200515113638671.jpg#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9pdDAwNy5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191127164631332.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9pdDAwNy5ibG9nLmNzZG4ubmV0,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9pdDAwNy5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191127170207146.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9pdDAwNy5ibG9nLmNzZG4ubmV0,size_16,color_FFFFFF,t_70