new 一个对象的全过程：在自己的 TLAB 里挪一下指针，再按规则把字段排进 48 字节

还有一种更老的办法：像 C 的 malloc 一样维护一张空闲块列表，每次找一块够大的。它不要求空闲内存连续，但每次分配都要查表，比挪指针慢得多（③）。

选择规则：年轻代对象多、死得快，用复制算法，所以空闲内存天然连续，指针碰撞就成立；再给每个线程一块 TLAB，连 CAS 都省了。本页学这一条，“根本不分配”留给 JIT 那一页。

④-1new 的五步（HotSpot 的实现，规范只规定结果）

第 3、4 步和第 5 步之间，对象已经存在、字段全是 0。如果引用在第 5 步跑完之前就被别的线程看到，它会读到“半初始化”的对象。这就是双重检查锁要加 volatile 的原因（⑥ 坑 3，JMM 页的双重检查锁）。

④-2TLAB：快速路径和三条慢速路径

TLAB 多大？不固定（ResizeTLAB 默认开）。JVM 的目标是：一个线程在两次 GC 之间大约领 50 次 TLAB（100 ÷ (2 × TLABWasteTargetPercent)，后者默认 1），所以分配越多的线程，TLAB 越大。本机用 -Xmx64m 启动、加 -Xlog:gc+tlab=trace，main 线程第一块 TLAB 的 desired_size 是 122 KB。

决定胜负的约束：分配是 Java 程序里最频繁的操作，而且一定是多线程的。所以要把共享的那一步摊薄到几十 KB 才发生一次，用一点尾巴浪费换掉每一次的 CAS。

④-3对象头：8 字节 mark word + 4 字节类指针

锁状态怎么在 mark word 里切换，见 synchronized 页 ④-1。偏向锁 JDK 15 默认关（JEP 374），JDK 18 把代码删了。

④-4字段怎么排：先大后小，见缝插针，最后补齐到 8

JDK 15 起 HotSpot 用这套规则（JDK-8237767）：

• 1对象头占前 12 字节。字段从第 12 字节往后放，但每个字段的起点必须是它自己大小的倍数：long 只能从 8 的倍数开始，int 和压缩后的引用从 4 的倍数开始。
• 2先放基本类型，按大小从大到小（long/double → int/float → short/char → byte/boolean），再放引用。不按声明顺序；大小相同的几个字段谁先谁后，Linux 上没有保证。
• 3每个字段放进最小的、能放下的空位（best fit），找不到才接到末尾。所以 12～16 这 4 字节的空隙，会被第一个 4 字节字段填上。
• 4整个对象补齐到 8 的倍数（ObjectAlignmentInBytes，默认 8）。父类的字段排在前面，子类的字段可以填父类留下的空隙。

左边是“按声明顺序硬排”的结果：第一个 long 只能从 16 开始，对象头后面空出 4 字节；status 放完停在 52，还要再补 4 字节，一共 56。右边是 HotSpot 的排法，也是 ⑤ 里 JOL 实测的结果：skuId 塞进对象头后面的空隙，正好 48 字节，一个字节都不浪费。

④-5为什么对齐到 8，又为什么卡在 32 GB

决定胜负的约束：Java 堆里大部分是小对象，引用占了很大一块，而绝大多数服务的堆不到 32 GB。“对齐到 8”本来就有（CPU 读未对齐的 long 更慢），顺手把它变成 3 位免费的地址空间。真要更大，可以把 -XX:ObjectAlignmentInBytes 设成 16，上限变成 64 GB，代价是每个对象补齐更多。

// 依赖 org.openjdk.jol:jol-core:0.17
System.out.println(ClassLayout.parseInstance(order).toPrintable());   // 一个对象：每个字段在第几字节
System.out.println(GraphLayout.parseInstance(order).toFootprint());   // 连同它引用的对象一共多大

# 和这页有关的 JVM 参数（都是默认值，一般不用动）
-XX:+UseTLAB  -XX:+ResizeTLAB  -XX:+UseCompressedOops  -XX:ObjectAlignmentInBytes=8
-Xlog:gc+tlab=trace                  # 看每个线程的 TLAB 大小、领了几次、浪费多少
jcmd <pid> GC.class_histogram        # 每个类有多少个实例、一共多少字节

TLAB 外的分配怎么在线上发现、紧凑对象头（JDK 25 可开，27 默认）、JDK 8 和 17 的差别，放到第⑥步。

public class Order {
    long id;  long userId;  int skuId;  int qty;  long amountCents;  String status;
}
Order o = new Order(1001L, 1024L, 88, 2, 17600L, "PAID");
System.out.println(ClassLayout.parseInstance(o).toPrintable());

实验 1：Order 的布局，算过哈希以后，再把压缩指针关掉

$ java -cp … Layout                                  # 默认参数
OFF  SZ   TYPE             DESCRIPTION             VALUE
  0   8                    (object header: mark)   0x0000000000000001 (non-biasable; age: 0)
  8   4                    (object header: class)  0x01085040
 12   4   int              Order.skuId             88
 16   8   long             Order.id                1001
 24   8   long             Order.userId            1024
 32   8   long             Order.amountCents       17600
 40   4   int              Order.qty               2
 44   4   java.lang.String Order.status            (object)
Instance size: 48 bytes

identityHashCode = 3b0143d3
  0   8                    (object header: mark)   0x0000003b0143d301 (hash: 0x3b0143d3; age: 0)

java.lang.Long   Instance size: 24 bytes     # 12 头 + 4 空隙 + 8 的 long
int[3]           Instance size: 32 bytes     # 16 头（含长度）+ 12 + 4 补齐
Order@… footprint:  [B 24 + String 24 + Order 48 = 96

$ java -XX:-UseCompressedOops -cp … Layout
  8   4                    (object header: class)  0x010c5868      # 类指针还是 4 字节
 40   4   int              Order.qty               2
 44   4                    (alignment/padding gap)
 48   8   java.lang.String Order.status            (object)
Instance size: 56 bytes
Order@… footprint:  [B 24 + String 32 + Order 56 = 112

• 1skuId 跑到了第 12 字节：声明在两个 long 后面，却被排到最前，填掉对象头后面的空隙（④-4 规则 3）。
• 2哈希是写进去的：调了 identityHashCode 以后，mark word 从 …01 变成 …3b0143d301，中间那段就是哈希值（④-3）。
• 3关掉压缩指针：status 变成 8 字节，44 那个 4 字节的空隙放不下它，只能接到 48，对象变成 56。对象头仍是 12 字节：JDK 15 起压缩类指针不再跟着压缩指针一起关（JDK-8241825）。
• 496 字节是一个订单真正的成本，前提是每个订单的 status 都是不同的 String 对象。这里的 "PAID" 是字面量，100 万个订单共用一个；从 JSON 解析出来的就不是了（⑥ 坑 1）。

实验 2：new 100 万个，线程分配了多少；关掉 TLAB 计时

$ java -Xms1g -Xmx1g -cp target/classes …AllocCost 1
new 1,000,000 个 Order：线程分配了 48,000,048 字节，平均每个 48.0 字节
第 1 轮：1 个线程各 new 50,000,000 个 Order，用时 706 ms   # 还没被 JIT 编译完
第 3 轮：1 个线程各 new 50,000,000 个 Order，用时 290 ms

$ java -Xms1g -Xmx1g -XX:-UseTLAB -cp target/classes …AllocCost 1
第 3 轮：1 个线程各 new 50,000,000 个 Order，用时 5,628 ms

• 1每个 48.0 字节：和 JOL 算的一样，getThreadAllocatedBytes 统计的就是 TLAB 里挪过的字节数。
• 2单线程也慢 19 倍：没有竞争也慢，说明主要花在“每次都从机器码调进 JVM 的 C++ 慢速路径”上（④-2）。
• 3两个线程等于一个线程：开着 TLAB，两个线程的耗时几乎不变，吞吐接近翻倍；关掉以后，两个线程的总耗时正好翻倍，它们在共享的分配指针上排成了一队。

紧凑对象头把类指针压到 22 位，塞进 mark word 的高位，对象头从 12 字节变成 8 字节。它省不省得下来，要看补齐：Order 的 4 字节空隙原本就被 skuId 填上了，省下的 4 字节又被补齐吃掉，还是 48；Long 从 24 变 16。这两个数是按 ④-4 的规则推算的，本机没有 JDK 25，没有实测。下面的实验台可以自己试。

布局实验台先猜，再排

排法就是 ④-4 那四条：基本类型从大到小，再放引用，每个字段放进最小的能放下的空位，最后补齐到 8；大小相同的字段这里按声明顺序，真实 JVM 不保证。同一个函数也能排数组（对象头 + 4 字节长度，再放元素）。在 node 里核对过：Order 48 / 56、OrderLite 40、Long 24、Object 16、int[3] 32，和 JOL 实测一致；8 字节对象头那一档是推算。

• 读 HotSpot 的 MemAllocator 和 ThreadLocalAllocBuffer：TLAB 的大小怎么随 GC 调整，refill_waste_limit 怎么涨
• JIT 的分配快速路径：C2 怎么把 new 内联成几条指令，再加上逃逸分析（地图上的待做页）
• 在 JDK 25 上开紧凑对象头重跑 ⑤ 实验 1，核对本页推算的 Order 48、Long 16
• 线上分配画像：JFR 的 jdk.ObjectAllocationSample、async-profiler 的 -e alloc，找出谁分配最多（J03 的 GC 调优页）
• 把交易靶场的订单缓存从 HashMap<Long, Order> 换成原生 long 键的集合，量一下省了多少