new-Object() 到底占用几个字节，看完这篇彻底明白了！，springboot 微服务架构书籍

Java 内存模型

对象内存中可以分为三块区域：对象头(Header)，实例数据(Instance Data)和对齐填充(Padding)，以 64 位操作系统为例(未开启指针压缩的情况) Java 对象布局如下图所示：

上图中的对齐填充不是一定有的，如果对象头和实例数据加起来刚好是 8 字节的倍数，那么就不需要对齐填充。

知道了 Java 内存布局，那么我们来看一个面试问题

Object obj=new Object()占用字节

这是网上很多人都会提到的一个问题，那么结合上面的 Java 内存布局，我们来分析下，以 64 位操作系统为例，new Object()占用大小分为两种情况：

• 未开启指针压缩 占用大小为：8(Mark Word)+8(Class Pointer)=16 字节

• 开启了指针压缩(默认是开启的) 开启指针压缩后，Class Pointer 会被压缩为 4 字节，最终大小为： 8(Mark Word)+4(Class Pointer)+4(对齐填充)=16 字节

结果到底是不是这个呢？我们来验证一下。 首先引入一个 pom 依赖：

<dependency><groupId>org.openjdk.jol</groupId><artifactId>jol-core</artifactId><version>0.10</version></dependency>

然后新建一个简单的 demo：

package com.zwx.jvm;

import org.openjdk.jol.info.ClassLayout;

public class HeapMemory {public static void main(String[] args) {Object obj = new Object();System.out.println(ClassLayout.parseInstance(obj).toPrintable());}}

输出结果如下：

最后的结果是 16 字节，没有问题，这是因为默认开启了指针压缩，那我们现在把指针压缩关闭之后再去试试。

-XX:+UseCompressedOops 开启指针压缩-XX:-UseCompressedOops 关闭指针压缩

再次运行，得到如下结果：

可以看到，这时候已经没有了对齐填充部分了，但是占用大小还是 16 位。

下面我们再来演示一下如果一个对象中带有属性之后的大小。

新建一个类，内部只有一个 byte 属性：

package com.zwx.jvm;

public class MyItem {byte i = 0;}

然后分别在开启指针压缩和关闭指针压缩的场景下分别输出这个类的大小。

package com.zwx.jvm;

import org.openjdk.jol.info.ClassLayout;

public class HeapMemory {public static void main(String[] args) {MyItem myItem = new MyItem();System.out.println(ClassLayout.parseInstance(myItem).toPrintable());}}

开启指针压缩,占用 16 字节：

关闭指针压缩，占用 24 字节：

这个时候就能看出来开启了指针压缩的优势了，如果不断创建大量对象，指针压缩对性能还是有一定优化的。

对象的访问

创建好一个对象之后，当然需要去访问它，那么当我们需要访问一个对象的时候，是如何定位到对象的呢？ 目前最主流的访问对象方式有两种：句柄访问和直接指针访问。

• 句柄访问 使用句柄访问的话，Java 虚拟机会在堆内划分出一块内存来存储句柄池，那么对象当中存储的就是句柄地址，然后句柄池中才会存储对象实例数据和对象类型数据地址。

• 直接指针访问(Hot Spot 虚拟机采用的方式) 直接指针访问的话对象中就会直接存储对象类型数据。

句柄访问和直接指针访问对比

上面图形中我们很容易对比，就是如果使用句柄访问的时候，会多了一次指针定位，但是他也有一个好处就是，假如一个对象被移动(地址改变了)，那么只需要改变句柄池的指向就可以了，不需要修改 reference 对象内的指向，而如果使用直接指针访问，就还需要到局部变量表内修改 reference 指向。

堆内存

上面我们提到，在 Java 对象头当中的 Mark Word 存储了对象的分代年龄，那么什么是分代年龄呢？

一个对象的分代年龄可以理解为垃圾回收次数，当一个对象经过一次垃圾回收之后还存在，那么分代年龄就会加 1，在 64 位的虚拟机中，分代年龄占了 4 位，最大值为 15。分代年龄默认为 0000，随着垃圾回收次数，会逐渐递增。

Java 堆内存中按照分代年龄来划分，分为 Young 区和 Old 区，对象分配首先会到 Young 区，达到一定分代年龄(-XX:MaxTenuringThreshold 可以设置大小，默认为 15)就会进入 Old 区(注意：如果一个对象太大，那么就会直接进入 Old 区)。

之所以会这么划分是因为如果整个堆只有一个区的话，那么垃圾回收的时候每次都需要把堆内所有对象都扫描一遍，浪费性能。而其实大部分 Java 对象的生命周期都是很短的，一旦一个对象回收很多次都回收不掉，可以认为下一次垃圾回收的时候可能也回收不掉，所以 Young 区和 Old 区的垃圾回收可以分开进行，只有当 Young 区在进行垃圾回收之后还是没有腾出空间，那么再去触发 Old 区的垃圾回收。

Young 区

现在拆分成了 Young 区，那我们看下面一个场景，下面的 Young 是经过垃圾回收之后的一个概图：

假如说现在来了一个对象，要占用 2 个对象的大小，会发现放不下去了，这时候就会触发 GC(垃圾回收)，但是一旦触发了 GC(垃圾回收)，对用户线程是有影响的，因为 GC 过程中为了确保对象引用不会不断变化，需要停止所有用户线程，Sun 把这个事件称之为：Stop the World(STW)。这些在下一篇讲解垃圾回收的时候会详细介绍，这里先不深入。

所以说一般是越少 GC 越好，而实际上上图中可以看到至少还可以放入 3 个对象，只要按照对象都按照顺序放好，那么是可以放得下的，所以这就产生了问题了，明明有空间，但是因为空间不连续，导致对象申请内存失败，导致触发 GC 了，那么如何解决这种问题呢？

解决的思路就是把 Young 区的对象按顺序放好，所以就产生了一个方法，把 Young 区再次划分一下，分为 2 个区：Eden 区和 Survivor 区。

具体操作是：一个对象来了之后，先分配到 Eden 区，Eden 区满了之后，触发 GC，经过 GC 之后，为了防止空间不连续，把幸存下来的对象复制到 Survivor 区，然后 Eden 区就可以完整清理掉了，当然这么做是有一个前提的，就是大部分对象都是生命周期极短的，基本一次垃圾回收就可以把 Eden 区大部分对象回收掉（这个前提是经过测试总结得到的）。

触发 GC 的时候 Survivor 区也会一起回收，并不是说单独只触发 Eden 区，但是这样问题又来了，Eden 区是保证空间基本连续了，但是 Survivor 区又可能产生空间碎片，导致不连续了，所以就又把 Survivor 区给一分为二了：

这个时候工作流程又变成这样了： 首先还是在 Eden 区分配空间，Eden 区满了之后触发 GC，GC 之后把幸存对象 复制到 S0 区(S1 区是空的)，然后继续在 Eden 区分配对象，再次触发 GC 之后如果发现 S0 区放不下了(产生空间碎片，实际还有空间)，那么就把 S0 区对象复制到 S1 区，并把幸存对象也复制到 S1 区，这时候 S0 区是空的了，并依次反复操作，假如说 S0 区或者 S1 区空间对象复制移动了之后还是放不下，那就说明这时候是真的满了，那就去老年区借点空间过来（这就是担保机制，老年代需要提供这种空间分配担保），假如说老年区空间也不够了

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

，那就会触发 Full GC，如果还是不够，那就会抛出 OutOfMemeoyError 异常了。

注意：为了确保 S0 和 S1 两个区域之间每次复制都能顺利进行，S0 和 S1 两个区的大小必须要保持一致，而且同一时间有一个区域一定是空的。虽然说这种做法是会导致了一小部分空间的浪费，但是综合其他性能的提升来说，是值得的。

Old 区

当 Young 区的对象达到设置的分代年龄之后，对象会进入 Old 区，Old 区满了之后会触发 Full GC，如果还是清理不掉空间，那么就抛出 OutOfMemeoyError 异常。