Java对象分配：指针碰撞与空闲列表解析

Java对象内存分配并非简单地“扔进堆里”，而是一套高度动态、条件驱动的智能决策机制：小对象优先通过线程私有的TLAB实现无锁的指针碰撞（Bump the Pointer），追求极致性能；但一旦遇到内存碎片、大对象、TLAB耗尽或GC算法限制（如CMS、ZGC），JVM会自动回退到更灵活却更耗时的空闲列表（Free List）进行碎片化空间查找。分配路径的选择取决于GC类型、对象大小、TLAB开关、内存连续性等多重实时因素，甚至同一条new指令在不同运行时刻都可能走完全不同路径——理解这一点，才能真正诊断OutOfMemoryError、优化分配延迟，并摆脱“调了参数就万事大吉”的误区。

对象分配在堆上哪块区域？看 GC 算法和内存布局

Java 对象不是随便扔进堆里就完事的。新生代通常用 Parallel Scavenge 或 G1，它们默认启用 TLAB（Thread Local Allocation Buffer）；而老年代基本不走指针碰撞——因为碎片多，得靠空闲列表。所以“分配在哪”，取决于你用的是什么 GC、对象大小、是否开启 -XX:+UseTLAB，以及当前 Eden 区有没有连续空间。

常见错误现象：OutOfMemoryError: Java heap space 不一定是因为堆小，也可能是 TLAB 太小导致频繁同步申请，或者大对象直接绕过 TLAB 进入 Eden 但没空间了。

• 小对象（默认 ≤ 256KB）优先走 TLAB，线程私有，无锁
• 大对象（如大数组）可能直接分配到老年代（-XX:PretenureSizeThreshold 控制），跳过新生代
• G1 下还可能分配到 humongous region，这类区域单独管理，不参与常规指针碰撞

指针碰撞（Bump the Pointer）怎么触发？哪些条件不满足就 fallback 到空闲列表

指针碰撞只在内存规整、没有碎片时才高效。它本质是把一个全局指针（比如 top）往前一推，中间那段就归新对象了。但这个前提很苛刻：

• 必须使用 Serial 或 Parallel 这类“标记-整理”型 GC，且堆内存刚经过一次 Minor GC 清理，Eden 区是连续空闲的
• 对象不能太大，否则推完指针发现超了 end，就得 fallback
• 如果开了 -XX:-UseTLAB，线程共享 Eden 的 top 指针，竞争下容易失败，也会退到空闲列表

一旦触发 fallback，JVM 就查空闲列表（Free List），遍历链表找足够大的空闲块——这比指针碰撞慢，且需要加锁维护链表结构。

空闲列表怎么管理？为什么 CMS 和 ZGC 都依赖它

空闲列表本质是个按大小组织的链表或位图，记录着堆里所有“能用但不连续”的空闲块。CMS 是“标记-清除”算法，不清除碎片，只能靠空闲列表拼凑空间；ZGC 虽然用颜色指针，但元数据里仍要维护空闲页链表（ZPage list）。

使用场景：老年代分配、G1 的混合回收阶段、CMS 并发清理后、或者 TLAB 分配失败又没足够连续空间时。

• 每个空闲块头里存着大小和 next 指针，JVM 按首次适配（first-fit）或最佳适配（best-fit）策略查找
• 分配后若剩余空间太小（MinChunkSize，通常 200 字节左右），会被直接丢弃，避免产生大量不可用碎片
• 空闲列表本身也要占内存，CMS 在老年代维护它，会略微增加 GC 元数据开销

怎么验证当前分配策略？别只看参数，得看实际行为

光看 -XX:+UseParallelGC 不能确定就在用指针碰撞——得结合 GC 日志和运行时状态。很多同学调了参数却没效果，是因为忽略了实际触发条件。

• 加 -Xlog:gc+alloc=debug（JDK 11+）能看到每次分配是走 TLAB、Eden bump 还是 fallback 到空闲列表
• jstat -gc 中的 EC（Eden 容量）、EU（Eden 已用）差值接近对象大小，说明大概率是 bump；如果 EU 跳变不规律，可能是空闲列表拼出来的
• 禁用 TLAB（-XX:-UseTLAB）后观察分配延迟突增，基本能反向印证原来靠的是 TLAB + bump

真正难的不是理解两种机制，而是意识到：JVM 从不保证某次分配一定走哪种路径，它只在当下选代价最小的那条。TLAB 填满、GC 刚结束、对象大小变化、甚至线程调度顺序，都可能让同一条 new 指令走完全不同的内存路径。

本篇关于《Java对象分配：指针碰撞与空闲列表解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！