Java基本数据类型内存布局取决于声明位置：局部变量存栈帧槽位并按宽度对齐；成员变量嵌入堆中对象实例区且受JVM字段重排与8字节对齐影响；数组元素在堆中连续存储，含对象头、长度字段及对齐填充。
Java 基本数据类型在内存中的字节分配不是简单“占几个字节”就能说清的，关键要看它在哪——是局部变量、对象字段，还是数组元素。不同位置，布局规则完全不同。
局部变量：按类型宽度对齐，存在栈帧槽位中
方法内定义的变量（如 int x = 10;）存于当前线程的虚拟机栈中：
- 每个变量按自身宽度对齐：byte/boolean 通常占 1 字节且地址对齐到 1 字节边界；char/short 占 2 字节且地址需偶数；int/float 占 4 字节且地址需 4 字节对齐；long/double 占 8 字节且地址需 8 字节对齐（避免跨缓存行）
- 栈帧的局部变量表以“槽（slot）”为单位组织，每槽宽 32 位；int/float/char/short/byte/boolean 占 1 个槽，long/double 占 2 个连续槽
- boolean 在栈上不按位存储，HotSpot 实际也分配 1 字节空间（即使语义是 true/false）
对象字段：受 JVM 字段重排与 8 字节对齐影响
当基本类型作为类的成员变量（如 class A { byte a; int b; }），它们嵌入对象实例数据区，位于堆中：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- JVM 会自动重排字段顺序（按宽度从大到小），再填充 padding，使每个字段起始地址满足对齐要求
- 例如
byte a; int b;表面 5 字节，实际布局为：a(1) + padding(3) + b(4) = 8 字节 - 若写成
int b; byte a;，仍是 b(4) + a(1) + padding(3) = 8 字节；但多个 byte 连续声明（如 4 个 byte + 1 个 int）可紧凑排布为 8 字节，无浪费 - 对象本身还有对象头（约 12 字节，64 位 + 压缩指针）和对齐填充（整体大小必须是 8 字节倍数）
数组元素：固定宽度 × 长度，含头开销与末尾填充
基本类型数组（如 int[] arr = new int[5];）是对象，分配在堆上：
立即学习“Java免费学习笔记（深入）”；
- 结构 = 对象头（12 字节） + 数组长度字段（4 字节） + 元素数据（length × 类型字节数）
- 最终总大小会向上对齐到 8 字节边界；例如
new int[10]：12 + 4 + 10×4 = 56 字节（已对齐） - boolean[] 是特例：底层按 byte 数组实现，每个 boolean 元素占 1 字节（不是 1 bit），所以
new boolean[10]实际占约 12 + 4 + 10 = 26 → 向上对齐为 32 字节
别混淆包装类和基本类型
Integer、Long 等是对象，不是基本类型：
- int 占 4 字节；Integer 至少占 16 字节（对象头 12 + value 字段 4，再对齐）
- 装箱/拆箱不仅耗时，还放大内存占用 4 倍以上，频繁使用会显著加重 GC 压力
- 不能用 byte 替代 boolean 来“省空间”——JVM 已优化，手动位运算反而降低可读性与性能
