【转】Java new一个Object对象占用多少内存？

心已赠人 2022-12-20 11:11 131阅读 0赞

Java的自动内存管理机制（[automatic storage management system known as a garbage collector][]）省却了很多编码工作，大大地提高了Java的生产力，而且JVM的性能也越来越好，特别是[G1][]的出现，改善了垃圾回收中stop the world的状况。

也许很多人都没有考虑过这个问题，new一个Object对象到底占用多少内存呢( Object obj = new Object() )？

这里很明确的是obj是一个指向对象的引用（[reference - there are three kinds of reference types: class types,array types, and interface types][automatic storage management system known as a garbage collector]），引用的长度决定了Java的寻址能力，32位的JDK是4字节，64位的JDK是8字节（[指针未被压缩的情况下][Link 1]）。

因为obj对象没有任何数据（field），会在堆上为它分配空间吗？如果分配空间，里面存储了什么内容？

以面向对象的思维来分析，对象封装了数据和行为，是一个统一的整体，虽然obj对象没有数据，但是有行为（Object类定义了12个方法）。当我们执行完new操作后，obj的值为堆内存的地址，既然obj都指向一块内存了，说明是会在堆上为其分配空间的。

那么分配的空间有多大，存储了什么内容呢？在[The Java Virtual Machine Specification Java SE 7 Edition][automatic storage management system known as a garbage collector]和[The Java Language Specification Java SE 7 Edition][automatic storage management system known as a garbage collector]里面没有找到相关的描述，这很可能是属于JVM实现自由控制的范畴了。我们可以利用JDK自带的工具jvisualvm.exe来查看分配的空间有多大。为了方便在jvisualvm中查看对象占多少内存，这里使用一个私有的静态内部类EmptyObject来替代Object，因为类定义为空，所以可以等同对待EmptyObject和Object。

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 </td> 
 <td> <code>/**</code> <code>&nbsp;</code><code>*&nbsp;构造一个无任何字段的空对象占多少内存</code> <code>&nbsp;</code><code>*&nbsp;@author&nbsp;杨尚川</code> <code>&nbsp;</code><code>*/</code> <code>public</code>&nbsp;<code>class</code>&nbsp;<code>EmptyTest&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code>&nbsp; <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>public</code>&nbsp;<code>static</code>&nbsp;<code>void</code>&nbsp;<code>main(String[]&nbsp;args)&nbsp;</code><code>throws</code>&nbsp;<code>InterruptedException{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>//加到集合中，使垃圾无法回收</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>List&lt;EmptyObject&gt;&nbsp;emptys&nbsp;=&nbsp;</code><code>new</code>&nbsp;<code>ArrayList&lt;&gt;();</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>for</code><code>(</code><code>int</code>&nbsp;<code>i=</code><code>0</code><code>;i&lt;</code><code>100</code><code>;i++){ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>emptys.add(</code><code>new</code>&nbsp;<code>EmptyObject());</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>}</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>//打开jvisualvm,查看EmptyObject的大小为16字节</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>Thread.sleep(</code><code>60</code><code>*</code><code>1000</code><code>);</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>}</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>private</code>&nbsp;<code>static</code>&nbsp;<code>class</code>&nbsp;<code>EmptyObject{}</code> <code>}</code> </td> 
 </tr> 
 </tbody> 
</table>

我们在这里面通过new不同的对象数（for循环次数），来分析内存占用，new 1个对象是16字节，new 2个对象是32字节，new 100个对象是1600字节，通过很多次的尝试，我们从jvisualvm里面可以看到 字节数=对象数\*16 ，我们有理由相信对象数跟字节数的线性关系。从这里可以看出，jvisualvm显示的内存占用跟引用的4字节或8字节是没有关系的，也就是说，jvisualvm显示的是堆内存占用，这也很好理解，毕竟所有引用的字节占用是固定的。8字节是引用，16字节是堆内存，总共是8+16=24字节，所以new一个Object对象占用8+16=24字节（64位JDK）。

如果JDK是32位，按如上分析方法可知new一个Object对象占用4+8=12字节（32位JDK），如下图所示：

**64位JDK:**  
![fdd42b45cf94289f8b3a88d52598fe21.png][]  
**32位JDK:**  
**![6657d14a09772d4618c16283a2850103.png][]**

那么分配的16字节（8字节）的堆内存中存储了什么内容呢？当我们Object obj = new Object()；的时候，在栈内存中有一个引用obj，他可能是32位也可能是64位，obj实质只是一个内存地址，那么当我们调用obj.xxx()的时候，JVM怎么知道obj是哪个类的实例呢？所以，可以大胆地推测，obj对象的16字节（8字节）的堆内存中记录了对象属于哪个类的信息，问题是这16字节（8字节）的结构是什么样的？不清楚！

不过我们仍然可以大胆地猜测一下，通过上面的64位和32位的堆内存大小对比分析发现，堆内存分配的大小是引用的两倍，上面我们已经猜测堆内存中会记录对象是哪个类的实例，如何记录呢？因为类对象是放置在方法区的，类对象本身也是一个对象，因此可以通过一个引用指向它，所以堆内存有可能就是放置了两个引用，指向两个对象。分析到这里，事情就比较明朗了，堆内存中可能就放置了两个内存地址，一个指向EmptyObject.class（在实验代码中用EmptyObject来代替Object），一个指向什么呢？不清楚！

在[Inside the Java 2 Virtual Machine][automatic storage management system known as a garbage collector] 2nd by Bill Venners的5.3.5中有这么一段描述：

The Java virtual machine specification is silent on how objects should be represented on the heap. Object representation--an integral aspect of the overall design of the heap and garbage collector--is a decision of implementation designers.

好了，事情最终清楚了，JVM规范并没有规定Java对象在堆中是如何表示的，对象的表示是堆和垃圾收集器的整体设计的一个组成部分，这是由JVM实现的设计师来决定的。 因此，如果我们真的想搞清楚对象是如何表示的，那么需要查询HotSpot VM或是其他JVM实现的相关资料。

在淘宝工程师[莫枢（撒迦）][Link 2]的《[JVM分享][JVM]》PPT的第112页介绍了“HotSpot中的Java对象布局”，这真是现在关心的内容，通过PPT的介绍说明前面的猜测是对的，如下图所示：

![5a8c64cb81b54c736ae50f482c2edc1b.png][]  
   
![80670286f181f2b12e5c8d8c168e9863.png][]  
   
![dccc75230c97cbe84f45268be521830b.png][]  
   
![19b6557d49c80d74eaad09c80444504c.png][]  
   
![4eb59b39c338191a3f9849892081604f.png][]  
   
![a5f21189148db9d1c0003c51bb0d7107.png][]

我们研究new一个Object对象占多少内存可能没什么实际意义，因为我们在编程的时候就可以确定对象树，基本可以确定对象大小，除了变长字段，当然，变长字段我们一般也会有长度限制。所以我们真正关心的是所有数据最终的大小，也就是数据库的大小。

面向对象的分析、设计和编程都把“封装”奉为圭臬，“分层”更是架构设计中至关重要的设计准则。因为只有这样，才能实现基本的解耦、让协作分工成为可能，满足工业要求的最大化生产力的最终目标。

那么这种没有什么实际意义的问题为什么要研究呢？我觉得只能用三个字来形容：好奇心。**好奇心是驱使我们研究技术的强大推力，当我们工作了很多年，尤其是在不重视技术的公司，我们对技术还有激情吗？保持一颗敏感好奇的心，也许技术之路可以走的更长更远。**

**这篇文章的重点是展示一种分析问题的思路，要大胆猜测，小心求证，追本溯源，引经据典。求证方式：查找标准规范、查找经典权威书籍、自己做实验、查找源代码等。**

**参考资料：**

**1、[Java™ Virtual Machine Technology][Java_ Virtual Machine Technology]**

**2、[The Java Virtual Machine Specification Java SE 7 Edition][automatic storage management system known as a garbage collector]**

**3、[The Java Language Specification Java SE 7 Edition][automatic storage management system known as a garbage collector]**

**4、[Inside the Java 2 Virtual Machine 2nd by Bill Venners][automatic storage management system known as a garbage collector]**

**5、[JVM分享][JVM]**

**6、**[**http://www.javamex.com/classmexer/**][http_www.javamex.com_classmexer]

[automatic storage management system known as a garbage collector]: http://pan.baidu.com/share/link?shareid=2673525279&uk=3157595467#dir/path=%2F%E3%80%90%E5%A4%A7%E6%95%B0%E6%8D%AE%E3%80%91%E7%9B%B8%E5%85%B3%E6%8A%80%E6%9C%AF%E8%8B%B1%E6%96%87%E5%8E%9F%E7%89%88%E7%94%B5%E5%AD%90%E4%B9%A6%2Fjava
[G1]: http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html
[Link 1]: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop
[fdd42b45cf94289f8b3a88d52598fe21.png]: /images/20221120/5953624627504adeb1bb4ec7128cb1be.png
[6657d14a09772d4618c16283a2850103.png]: https://img-blog.csdnimg.cn/img_convert/6657d14a09772d4618c16283a2850103.png
[Link 2]: http://rednaxelafx.iteye.com/
[JVM]: http://pan.baidu.com/s/1mglvMVu
[5a8c64cb81b54c736ae50f482c2edc1b.png]: https://img-blog.csdnimg.cn/img_convert/5a8c64cb81b54c736ae50f482c2edc1b.png
[80670286f181f2b12e5c8d8c168e9863.png]: https://img-blog.csdnimg.cn/img_convert/80670286f181f2b12e5c8d8c168e9863.png
[dccc75230c97cbe84f45268be521830b.png]: https://img-blog.csdnimg.cn/img_convert/dccc75230c97cbe84f45268be521830b.png
[19b6557d49c80d74eaad09c80444504c.png]: https://img-blog.csdnimg.cn/img_convert/19b6557d49c80d74eaad09c80444504c.png
[4eb59b39c338191a3f9849892081604f.png]: https://img-blog.csdnimg.cn/img_convert/4eb59b39c338191a3f9849892081604f.png
[a5f21189148db9d1c0003c51bb0d7107.png]: https://img-blog.csdnimg.cn/img_convert/a5f21189148db9d1c0003c51bb0d7107.png
[Java_ Virtual Machine Technology]: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/
[http_www.javamex.com_classmexer]: http://www.javamex.com/classmexer/