Java对象分配采用指针碰撞或空闲列表机制：前者适用于规整堆内存，速度快但要求连续空间；后者适应碎片化堆，通过链表管理空闲块，速度较慢但灵活性高。

Java对象分配不是简单地“找个空地方放进去”，而是由JVM根据当前堆内存状态和GC策略，动态选择最合适的底层机制。核心就两种：指针碰撞和空闲列表——它们本质是同一问题的两种解法：如何在有限、可能杂乱的堆空间里，又快又准地划出一块给新对象。

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

它依赖一个前提：堆里已用内存和空闲内存泾渭分明，中间只隔着一个“分界指针”。比如Minor GC后刚整理过的Eden区，就是典型规整状态。

• 分配动作极简：指针直接向后移动对象所需字节数，新内存区域自动生效
• 无需查找、无需遍历，时间复杂度是O(1)，速度接近硬件级
• 但一旦内存不连续（比如有碎片），或者对象太大超出剩余空闲段，就会立刻失效
• Serial、Parallel Scavenge、G1年轻代默认走这条路；不过多线程下直接共享这个指针会冲突，所以实际常配合TLAB使用

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

当堆变得支离破碎——像CMS的老年代那样，标记-清除后留下大量小块空闲内存——指针碰撞就无从下手。这时JVM改用空闲列表，把所有可用内存块登记成链表或位图。

• 每次分配都要扫描列表，按策略（如首次适应）找一块够用的空闲块
• 找到后可能还要切割：用掉一部分，把剩余小块重新登记回列表
• 回收对象时，对应内存块又被加回列表，形成闭环管理
• CMS、ZGC老年代、G1的Humongous区都重度依赖这种机制；它容忍碎片，但代价是分配变慢、维护链表有额外开销

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

JVM不做主观选择，而是被现实条件驱动：

• 新生代Eden区多数时候规整 → 倾向指针碰撞（尤其开了TLAB后，每个线程有自己小指针，避免竞争）
• 老年代长期积累对象，碎片难避免 → 几乎只能靠空闲列表拼凑空间
• 大对象（如超大数组）可能绕过Eden直入老年代，或进G1的Humongous区 → 跳过指针碰撞逻辑，直接查空闲列表
• 哪怕用了Parallel GC，如果TLAB太小或被禁用（-XX:-UseTLAB），线程争抢全局指针失败，也会退化到空闲列表

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

指针碰撞本身不线程安全——多个线程同时推同一个指针会错乱。所以JVM不会裸用：

• TLAB是主流解法：每个线程预分一小块私有Eden空间，各自维护本地指针，完全无锁
• 没TLAB或TLAB不够时，才同步申请Eden区公共空间，此时用CAS原子操作更新全局指针
• 空闲列表操作涉及链表增删，同样需要加锁或无锁数据结构（如ZGC用并发链表）来保障一致性