指针碰撞（Bump the Pointer）与空闲列表：分析堆内存在分配对象变量时的内存布局策略

Ja va对象分配，远不是“找个空地方放进去”那么简单。这背后，是JVM根据堆内存的实时“健康状况”和垃圾收集器的策略，动态选择的一套精密机制。核心玩法就两种：指针碰撞和空闲列表。说白了，它们解决的是同一个问题：如何在有限且可能杂乱无章的堆空间里，又快又准地划出一块地皮给新对象安家。

指针碰撞：快，但只认“整齐”的内存

这套机制能跑起来，有个大前提：堆内存必须“规整”。想象一下，已用的内存和空闲的内存泾渭分明，中间只隔着一个“分界指针”。比如，刚经历过Minor GC整理过的Eden区，就是这种理想状态。

• 分配动作极简：指针直接向后移动对象所需的大小，新内存区域就生效了，简单粗暴。
• 性能接近硬件级：无需查找、无需遍历，时间复杂度是O(1)，速度飞快。
• 致命的弱点：一旦内存不连续（出现碎片），或者对象太大，超出了指针后面那一段连续空间，这套机制立刻失效。
• 典型应用场景：Serial、Parallel Sca venge等收集器的年轻代，以及G1的年轻代，默认都走这条路。不过，多线程环境下直接共享一个全局指针会引发冲突，所以实际中常配合TLAB（线程本地分配缓冲区）来使用。

空闲列表：慢，但能“见缝插针”

当堆内存变得支离破碎时——比如CMS收集器处理过的老年代，标记-清除后留下了大量零散的空闲内存块——指针碰撞就无从下手了。这时候，JVM就会切换到“空闲列表”模式。它把所有可用的内存块登记在一个链表（或位图）里进行管理。

• 分配需要“寻址”：每次分配，都需要扫描这个空闲列表，按照某种策略（比如首次适应）找到一块足够大的空闲块。
• 可能涉及“切割”：找到的块如果比需要的更大，用掉一部分后，剩余的小块还得重新登记回列表里。
• 形成管理闭环：对象被回收时，它占用的内存块又会被加回到空闲列表中，等待下次被利用。
• 代价与灵活性：CMS的老年代、ZGC的老年代，以及G1中处理巨型对象的Humongous区域，都重度依赖这种机制。它的优势是能容忍内存碎片，但代价是分配速度变慢，并且维护链表本身也有额外开销。

选谁，不看意愿，看堆的“身体状况”

JVM在这两种机制间的切换，并非主观选择，而是被客观条件驱动的：

• 新生代倾向指针碰撞：Eden区在多数时候比较规整，自然倾向使用更快的指针碰撞（尤其是开启TLAB后，每个线程有自己的小指针，避免了竞争）。
• 老年代依赖空闲列表：老年代长期积累对象，碎片化难以避免，几乎只能依靠空闲列表来“拼凑”可用空间。
• 大对象的特殊路径：像超大数组这样的大对象，可能会直接进入老年代（或G1的Humongous区），从而跳过指针碰撞的逻辑，直接查询空闲列表。
• 机制退化：即使用了Parallel GC这类收集器，如果TLAB设置得太小或被禁用（-XX:-UseTLAB），线程争抢全局指针失败，分配过程也会退化到使用空闲列表。

线程安全不是“自带属性”，而是靠配套机制兜底

需要明确的是，指针碰撞本身并不具备线程安全性——多个线程同时去移动同一个指针，结果必然是混乱的。因此，JVM不会裸用这套机制：

• TLAB是主流解法：为每个线程预先分配一小块私有的Eden空间，各自维护本地指针，实现完全无锁的快速分配。
• 同步申请作为后备：当TLAB用完或未启用时，线程需要同步申请Eden区的公共空间，此时会采用CAS（比较并交换）这样的原子操作来更新全局指针。
• 空闲列表同样需要保护：对空闲列表的增删操作同样涉及共享数据，需要通过加锁或无锁数据结构（例如ZGC使用的并发链表）来保证一致性。