JVM中对象内存布局由对象头、实例数据和对齐填充三部分组成，对象头存储Mark Word和类型指针，实例数据按字段大小排序存放以优化对齐，对齐填充保证对象大小为8字节倍数以提升访问效率。
在Java虚拟机（JVM）中，一个对象在内存中的布局通常可以划分为三个主要部分：对象头（Object Header）、实例数据（Instance Data）和对齐填充（Padding）。这三者共同构成了我们平时所说的“对象”。简单来说，对象头记录了对象自身的运行时信息，实例数据存放了对象实际的字段值，而对齐填充则是一个为了内存访问效率而存在的“空白”区域。
解决方案
谈到对象的内存布局，这可不仅仅是JVM实现者才需要关心的事情，作为开发者，了解这些细节能帮助我们更好地理解内存消耗、优化性能，甚至在一些极端场景下排查问题。
对象头（Object Header）这部分是每个对象都自带的“元数据”，它并不存储我们定义的任何业务数据，却承载着对象生命周期中的关键信息。通常，对象头又可以细分为两部分：
Mark Word (标记字段)：这是对象头中最核心的部分，它是一个非固定大小的数据结构（在32位JVM中是32位，在64位JVM中是64位，开启指针压缩时可能会有不同）。Mark Word 存储了对象的哈希码（HashCode）、GC分代年龄、锁状态标志、偏向线程ID、偏向时间戳等信息。它就像是对象的“身份证”和“状态机”，随着对象在JVM中的运行状态变化而动态更新。比如，当我们对一个对象进行
synchronized
操作时，锁信息就会记录在这里；垃圾回收器判断对象存活时，也会用到这里的年龄信息。Klass Pointer (类型指针)：这个指针指向了对象所属类的元数据。JVM通过这个指针，可以知道这个对象是哪个类的实例，从而找到类的方法、字段定义等信息。在64位JVM中，如果开启了指针压缩（CompressedOops），这个指针的大小会从8字节压缩到4字节，这能显著减少内存占用。
实例数据（Instance Data）这部分就是我们最熟悉的了，它存储了对象中定义的各种字段值，包括从父类继承下来的字段和自身定义的字段。这些字段的存储顺序并非完全随意，JVM会遵循一定的规则来排列它们，通常是为了内存访问效率和节省空间。例如，在HotSpot JVM中，字段的存储顺序大致是：父类变量 -> 当前类变量；在各自内部，通常会按照大小进行排序，例如 long/double -> int/float -> short/char -> byte/boolean -> reference，这样可以减少填充。
对齐填充（Padding）这个部分的存在，纯粹是为了保证对象在内存中的地址是某个字节数的倍数，通常是8字节的倍数。JVM要求对象的大小必须是8字节的整数倍。如果对象头和实例数据加起来的总大小不是8字节的倍数，那么就会在末尾自动填充一些字节，直到满足这个条件。为什么要这么做呢？主要是为了CPU访问内存的效率。CPU在读取数据时，通常会以字长（例如4字节或8字节）为单位进行寻址和读取。如果对象不对齐，一个字段可能会跨越两个内存缓存行，导致CPU需要进行两次内存访问才能读取完整数据，这会大大降低性能。对齐填充虽然浪费了一点点内存，但换来了更高效的内存访问。
为什么我们需要关心对象的内存布局？
作为一名 Java 开发者，深入了解对象的内存布局，并非是钻牛角尖，它实际上能为我们打开一扇理解 JVM 内部运作的窗户，进而指导我们写出更高效、更节省内存的代码。
首先，内存占用。当我们创建大量对象时，如果对每个对象头和对齐填充的开销一无所知，就可能在不知不觉中消耗了比预期多得多的内存。尤其是在移动端或者内存受限的服务器环境中，一个微小的内存优化都可能带来显著的效益。比如，了解指针压缩的原理，可以帮助我们评估是否开启它（通常是默认开启的），以及它对内存的影响。
其次，性能优化。内存布局直接影响 CPU 缓存的命中率。CPU 读取数据是按缓存行（通常是64字节）为单位的。如果对象字段的排列能让相关联的数据尽可能地位于同一个缓存行内，那么当 CPU 访问其中一个字段时，其他字段也能很快被读取，这就是所谓的“缓存友好”。相反，如果字段散乱分布，或者因为不恰当的对齐导致一个字段跨越多个缓存行，就会频繁地导致缓存未命中，从而拖慢程序执行速度。这就是为什么有时候调整类中字段的声明顺序，可能会在微观层面影响性能。
再者，问题排查与理解。当遇到一些内存溢出（OOM）或者性能瓶颈时，如果能通过
JOL (Java Object Layout)
这样的工具去分析对象的实际内存布局，就能更直观地看到每个对象到底占用了多少内存，哪些部分是有效数据，哪些是开销。这对于定位内存泄漏、理解 GC 行为等都非常有帮助。它让我们从“黑箱”操作中走出来，对底层有了更清晰的认知。
实例数据是如何存放的？字段顺序有讲究吗？
是的，实例数据的存放顺序确实有讲究，而且这门“讲究”直接关系到内存的利用率和CPU的访问效率。JVM在存储实例数据时，并非简单地按照你在代码中声明的顺序来存放。HotSpot JVM通常会遵循一套既定的规则来优化存储：
标书对比王
标书对比王是一款标书查重工具，支持多份投标文件两两相互比对，重复内容高亮标记，可快速定位重复内容原文所在位置，并可导出比对报告。
58 查看详情 
继承关系优先：父类中定义的字段会先于子类中定义的字段存储。这很合理，因为子类是基于父类的扩展。数据类型大小排序：在同一层级（父类或子类）中，字段会按照其数据类型的大小进行排序。通常的顺序是：
long/double
(8字节) ->
int/float
(4字节) ->
short/char
(2字节) ->
byte/boolean
(1字节) ->
reference
(引用类型，4或8字节，取决于是否开启指针压缩)。这种排序的目的是为了更好地进行内存对齐，减少填充。想象一下，如果一个8字节的
long
字段后面紧跟着一个1字节的
byte
字段，那么为了保证
long
字段的8字节对齐，
byte
字段前面可能就需要填充7个字节。而如果将所有8字节字段放在一起，所有4字节字段放在一起，等等，就能最大程度地减少这种内部填充，使得内存更加紧凑。JVM 优化：JVM 可能会根据编译时的信息，对字段的顺序进行微调，以达到更好的对齐效果或缓存局部性。例如，它可能会将一些经常一起访问的字段放在一起，即使它们类型大小不同，但这种优化通常是建立在前面两条规则的基础之上的。
所以，虽然我们作为开发者在编写代码时可以随意声明字段顺序，但JVM在底层会进行重新排列。了解这个机制，有助于我们在设计数据结构时，有意识地将相关联或大小相近的字段声明在一起，尽管JVM会优化，但这种“人为干预”在某些情况下仍能起到积极作用，尤其是在追求极致性能的场景下。
内存布局优化在实际开发中有哪些应用？
理解内存布局不仅仅是理论知识，它在实际开发中有着非常具体的应用场景，能够帮助我们写出更高效、更健壮的代码。
减少内存占用：这是最直接的应用。
字段重排：虽然JVM会进行优化，但我们也可以在代码层面进行干预。比如，将类中大小相近的字段声明在一起，尤其是将
long
和
double
这种大字段放在一起，可以减少因对齐而产生的内部填充。例如，一个
long
后面跟着一个
byte
可能会导致7字节的填充，而如果
byte
后面跟着
int
，再后面跟着
long
，填充可能就会更少。合理使用数据类型：能用
int
就不用
long
，能用
byte
就不用
int
。虽然这看起来是常识，但在设计时考虑到内存布局，会让我们更审慎地选择数据类型。例如，对于只需要表示0-255的数值，使用
byte
而非
int
，可以节省3个字节的实例数据空间。避免过度包装：原始类型比其包装类（如
int
vs
Integer
）占用内存更少，因为包装类本身就是一个对象，会带有对象头和额外的字段。在集合中存储大量数值时，如果业务允许，使用原始类型数组或专门的原始类型集合库（如 FastUtil、Trove）能显著减少内存开销。
提升缓存命中率：这是性能优化的核心。
缓存行填充（Cache Line Padding）：在多线程并发场景下，如果两个线程频繁修改同一个对象中位于不同缓存行但又很近的字段，可能会导致“伪共享”（False Sharing）问题。当一个线程修改了某个字段，会导致包含该字段的整个缓存行失效，其他线程即使访问的是同一个缓存行中的不同字段，也需要重新从主内存加载，从而降低性能。通过在字段之间插入一些无意义的填充字段（通常是
long
类型，以填满一个缓存行），可以确保不同线程修改的字段位于不同的缓存行，从而避免伪共享。当然，Java 8 引入了
@Contended
注解，JVM会尝试自动处理这个问题，但理解其原理依然重要。数据局部性：设计数据结构时，尽量将经常一起访问的字段放在一起。这有助于CPU在一次内存读取中获取到更多所需数据，减少内存访问次数。
理解和使用 JVM 参数：
指针压缩（CompressedOops）：理解其原理能帮助我们判断是否需要在特定场景下调整相关JVM参数。在64位JVM中，指针压缩默认是开启的，它能将对象引用从8字节压缩到4字节，大幅减少内存占用。但它也有其局限性，比如堆内存超过一定大小时可能会失效。
总之，对对象内存布局的深入理解，就像拥有了一双“透视眼”，让我们能更清晰地看到代码在运行时是如何消耗和组织资源的。这对于编写高性能、高并发、低内存占用的应用程序至关重要。
以上就是对象的内存布局是怎样的？（对象头、实例数据、对齐填充）的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/214383.html
微信扫一扫 
支付宝扫一扫 
