对象对齐本身不可配置，jdk 10+ 已移除-xx:objectalignmentinbytes；默认8字节对齐，配合-xx:+usecompressedoops使64位jvm对象头从16b减至12b，显著降低小对象内存开销。
对象对齐（Object Alignment）本身不是 JVM 可配置的「参数」，-XX:ObjectAlignmentInBytes 早已在 JDK 10+ 中被移除；真正影响小对象内存占用的是底层对齐策略（默认 8 字节）和压缩指针（-XX:+UseCompressedOops）的组合效果。
为什么 -XX:ObjectAlignmentInBytes 不再可用
该选项在 JDK 10 中被彻底删除，HotSpot 源码中已无对应逻辑。试图在 JDK 11+ 上使用会直接报错：
Unrecognized VM option 'ObjectAlignmentInBytes=16'
它曾用于调试或特殊硬件场景，但实际生产中从未被推荐启用。现在所有对象都强制按 8 字节对齐（64 位 JVM），无法更改。
-XX:+UseCompressedOops 如何决定小对象「真实开销」
开启压缩指针后，类型指针从 8 字节缩为 4 字节，对象头总大小从 16 字节 → 12 字节（64 位系统）。这对小对象影响极大：
- 未开启时：对象头 16B + 实例数据 + 填充 → 即使只有 1 个
byte字段，也至少占 24B（16B 头 + 1B 数据 + 7B 填充） - 开启后：对象头 12B + 实例数据 + 填充 → 同样 1 个
byte，最小为 16B（12B 头 + 1B + 3B 填充） - 字段顺序敏感：声明
byte a; int b;占 24B；而int b; byte a;因填充更少，可能仍为 24B —— 但若加一个long c;，顺序就直接影响是否多出一整块 8B 填充
用 jdk.jfr + JOL 验证真实布局
别靠猜，用工具看实测值：
先加 JVM 参数启动应用：-XX:+UseCompressedOops -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（仅调试用）；再用 JOL（Java Object Layout）库验证：
new ClassLayout.parseClass(MySmallObj.class).toPrintable()
关键观察点：
- 输出中
instance size:行显示实际字节数，比如16或24 - 注意
gap行：表示插入的填充字节，如gap: 3就是为对齐补了 3 字节 - 对比开启/关闭
-XX:+UseCompressedOops下同一类的instance size差值，就是压缩指针对小对象的真实收益
海量小对象场景下最易忽略的点
对齐填充不是孤立存在的——它和 GC 分区（尤其是 G1 的 Region 大小）共同作用：
- G1 默认 Region 大小为 1MB～4MB，但每个 Region 内部仍按 8B 对齐分配对象；大量 16B 对象挤满一个 Region，比 24B 对象多出约 50% 的数量，间接影响 GC 扫描压力
- 数组对象额外带 4B 长度字段，且数组元素本身也要对齐；
byte[1]实际占 24B（12B 头 + 4B 长度 + 1B 元素 + 7B 填充），不是直觉上的 17B - 子类继承父类字段时，JVM 会把父类字段排在前面，子类字段排在后面，这种固定顺序削弱了手动重排字段的优化空间
真正要压内存，优先调字段顺序、关掉不必要的对象包装（比如用 int[] 替 ArrayList<integer></integer>），而不是幻想改对齐粒度。
