Java对象默认分配在堆上，但逃逸分析可使未逃逸对象栈上分配或标量替换；对象头含Mark Word和Klass Pointer，字段按类型重排并8字节对齐；TLAB优化内存分配，new慢主因是初始化与GC压力。
对象实例分配在堆上，但有例外
Java对象默认分配在堆内存中，这是JVM规范明确要求的。不过实际运行时存在几种绕过堆的场景：逃逸分析开启后，JIT编译器可能将未逃逸的对象栈上分配（Stack Allocation）；标量替换还能进一步拆解对象为局部变量，连“对象”结构都不保留。
这些优化完全由JIT控制，开发者无法强制指定。想确认是否发生，可加JVM参数：-XX:+PrintEscapeAnalysis 和 -XX:+PrintEliminateAllocations，观察日志里是否有allocates to stack或eliminated字样。
- 逃逸分析默认开启（HotSpot 8u60+），但仅作用于C2编译器，且方法需被足够频繁调用才能触发编译
- 对象含
final字段、无同步块、不传递引用给其他线程/方法，更易被判定为未逃逸 -
String、Integer等小对象在短生命周期场景下，栈上分配概率明显更高
对象头包含Mark Word和Klass Pointer
每个Java对象在堆中都有一个固定结构的对象头（Object Header），它不是Java语言层可见的字段，而是JVM内部管理所需。64位JVM默认开启UseCompressedOops时，对象头占12字节：前8字节是Mark Word（存储哈希码、锁状态、GC分代年龄等），后4字节是Klass Pointer（指向类元数据的指针）。
注意：Mark Word是复用结构——同一内存区域在不同状态下含义不同。比如轻量级锁膨胀后，这里存的就是指向Monitor对象的指针；GC标记阶段，可能临时存mark bit。
立即学习“Java免费学习笔记（深入）”；
- 关闭压缩指针（
-XX:-UseCompressedOops）会让Klass Pointer变成8字节，对象头变为16字节 - 数组对象额外多4字节
length字段，所以数组对象头是16字节（压缩指针下） - 使用
Unsafe.objectFieldOffset()无法获取对象头字段偏移，它们不属于Java字段范畴
字段内存布局受JVM重排序和对齐约束
Java字段在对象内的排列顺序不等于源码声明顺序。JVM会按字段类型大小重新排序：long/double → int/float → short/char → byte/boolean → reference，目的是减少填充字节（padding）并提升缓存行利用率。
但这个重排只发生在同一访问权限内（如所有private字段一起重排，public字段另排）。而且最终起始地址必须满足8字节对齐（即对象整体大小 % 8 == 0），不够就补padding。
-
@Contended注解可让字段单独成组，避免伪共享，但需启用-XX:-RestrictContended才生效 - 用
Unsafe.arrayBaseOffset()查数组首元素偏移，和对象字段偏移逻辑不同，别混用 - 字段重排不影响
serialVersionUID计算，序列化仍按声明顺序写入字节流
对象创建慢的关键不在new，而在内存分配与初始化协同
new指令本身很快，真正耗时的是三件事：堆内存空间分配（尤其是并发场景下的CAS竞争）、init方法执行（包括父类构造、字段赋值、实例初始化块）、以及可能触发的类加载与链接。
现代JVM通过TLS（Thread Local Storage）机制为每个线程预分配一块Eden区内存（叫TLAB），避免多线程争抢全局堆指针。可通过-XX:+UseTLAB（默认开启）和-XX:TLABSize调优。
- 大对象（超过
-XX:PretenureSizeThreshold）直接进老年代，跳过TLAB，此时分配成本显著上升 - 频繁创建短生命周期对象，容易导致
Minor GC频繁，比单次分配慢得多 - 构造函数里做IO、反射、锁操作，会掩盖内存分配本身的开销，排查时要区分瓶颈层级
OutOfMemoryError: Compressed class space和对象头无关，但java.lang.InternalError: Malformed class name可能源于Klass Pointer错乱。理解这些，才能看懂GC日志里的oop地址，也才明白为什么有些“简单对象”在JFR里显示分配延迟异常高。 
