java数组的length是对象头中固定偏移的final字段而非方法，因jvm创建时写死、读取直接内存寻址，比方法调用快且无虚分派开销；反射无法访问，其偏移量依jvm位数及指针压缩而定，且与元素类型无关。
Java数组的长度为什么是final字段而不是方法调用
因为 length 不是运行时计算出来的，而是数组对象头里固定偏移处的一个整型字段。JVM在创建数组时就写死了这个值，读取时直接内存寻址——比调用 length() 方法快一个数量级，也没有虚方法分派开销。
常见错误现象：有人试图通过反射修改 array.length，结果抛出 IllegalAccessException 或静默失败，因为 length 字段在HotSpot里根本不可见（不是Java层声明的字段，不进Class文件常量池）。
- 所有数组类型（
int[]、String[]、Object[]）都共享同一套头部布局，length始终位于对象头后第4字节（32位JVM）或第8字节（64位JVM，开启指针压缩时） - 不能用
array.getClass().getDeclaredField("length")获取，会抛NoSuchFieldException - 某些低版本JDK的
Unsafe可绕过限制读写，但行为未定义，且JDK 9+默认禁用相关权限
数组对象头里除了length还存了什么
HotSpot中，数组对象头 = 普通对象头 + 长度字段。普通对象头包含mark word（锁状态、GC分代年龄等）和klass pointer（指向类元数据），数组额外多一个4/8字节的 length 字段。
使用场景：做高性能序列化或内存分析时，需要跳过对象头直接访问元素起始地址，就必须知道这个固定偏移量。
立即学习“Java免费学习笔记（深入）”；
- 32位JVM：对象头8字节 +
length4字节 → 元素起始地址 = 对象地址 + 12 - 64位JVM（指针压缩开启，默认）：对象头12字节 +
length4字节 → 元素起始地址 = 对象地址 + 16 - 64位JVM（指针压缩关闭）：对象头16字节 +
length8字节 → 元素起始地址 = 对象地址 + 24 - 这个布局与数组元素类型无关——
byte[100]和Object[100]的头部结构完全一致
为什么new int[0]和new Integer[0]占用内存不同
因为基本类型数组和引用类型数组的元素存储方式不同，但头部结构一样。差异全在元素区：前者元素区占0字节，后者每个元素是指针（4或8字节），哪怕长度为0也要预留元素区起始位置。
性能影响：空数组不是“零开销”，new Object[0] 在堆上仍分配了对象头+length字段+对齐填充，典型大小是16字节（64位+指针压缩）。
-
new byte[0]：对象头12字节 +length4字节 + 0字节元素 → 实际分配16字节（按8字节对齐） -
new String[0]：同样16字节头部，但JVM可能额外保留元素区起始标记，实际观察到分配24字节 - 频繁创建空数组会增加GC压力，建议复用
EMPTY_ARRAY静态常量（如Collections.EMPTY_LIST内部做法）
用Unsafe验证数组头部结构会遇到什么坑
想用 Unsafe.arrayBaseOffset() 和 Unsafe.arrayIndexScale() 推算真实内存布局？小心JIT优化和不同JDK版本的实现漂移。
常见错误现象：代码在JDK 8下能正确读出 length 字段值，升级到JDK 17后返回随机数或崩溃——因为ZGC/Shenandoah等新GC要求对象头格式变更，而 Unsafe 访问未受保护的内存区域被严格限制。
-
Unsafe.arrayBaseOffset(int[].class)返回的是元素起始偏移，不是length字段偏移；length字段偏移需用Unsafe.objectFieldOffset()查找（但找不到） - JDK 9+ 默认拒绝
Unsafe.getUnsafe()调用，必须加启动参数--add-opens java.base/jdk.internal.misc=ALL-UNNAMED - 即使成功读取，不同GC算法（G1/ZGC）可能动态调整对象头大小，硬编码偏移值极易失效
真正稳定的方案只有两种：用 java.lang.reflect.Array.getLength()（安全但稍慢），或者接受JVM规范不保证内部布局——毕竟这是实现细节，不是API契约。
