Java对象的内存分配远非简单的“寻找空闲位置”操作，其背后是JVM根据堆内存的实时状态与垃圾收集器策略，动态执行的一套精密算法。核心分配机制主要分为两种：指针碰撞与空闲列表。本质上，它们共同解决了同一个核心问题：如何在有限且可能碎片化的堆内存空间中，高效且准确地为新对象划拨出所需的内存区域。
指针碰撞：高效分配，依赖规整内存布局
指针碰撞机制得以高效运行，依赖于一个关键前提：堆内存必须保持“规整”。想象一下，已使用内存与空闲内存界限分明，仅由一个“分界指针”分隔。例如，经过Minor GC整理后的Eden区，通常就处于这种理想状态。
- 分配操作极其高效：仅需将分界指针向后移动对象所需大小的距离，新内存区域即被分配，过程简单直接。
- 性能接近硬件级别：无需遍历或查找，时间复杂度为O(1)，分配速度极快。
- 存在明显局限性：一旦内存出现碎片化，或对象大小超出指针后方的连续空间，该机制便无法生效。
- 典型应用场景：Serial、Parallel Scavenge等收集器的年轻代，以及G1收集器的年轻代，默认均采用此方式。但在多线程环境下，为避免共享全局指针引发的竞争，实际常与TLAB（线程本地分配缓冲区）结合使用。
空闲列表：灵活管理，应对内存碎片化
当堆内存因长期运行而变得碎片化时——例如CMS收集器标记-清除后留下的老年代——指针碰撞便不再适用。此时，JVM会切换到“空闲列表”管理模式。该机制将所有可用的内存碎片记录在一个链表或位图结构中统一管理。
- 分配过程涉及查找：每次分配都需要扫描空闲列表，依据特定策略（如首次适应算法）寻找足够容纳对象的空闲内存块。
- 可能触发内存块分割：若找到的空闲块大于所需，分配后剩余的部分需作为新空闲块重新登记入列表。
- 实现内存回收闭环：对象被垃圾回收后，其占用的内存块会被重新添加至空闲列表，等待后续分配。
- 权衡取舍：CMS的老年代、ZGC的老年代，以及G1中处理巨型对象的Humongous区域，都依赖此机制。其优势在于能有效利用碎片化内存，但代价是分配速度较慢，且维护列表本身会产生额外开销。
机制选择：由堆内存的实际状态决定
JVM在两种分配机制间的切换，并非主观偏好，而是由堆内存的客观条件所驱动：
- 新生代偏好指针碰撞：Eden区在多数情况下内存较为规整，自然倾向于使用更快的指针碰撞（尤其结合TLAB后，每个线程拥有独立指针，彻底避免了竞争）。
- 老年代依赖空闲列表：老年代长期承载对象，内存碎片化问题普遍，几乎必须依靠空闲列表来“拼凑”可用空间。
- 大对象的特殊分配路径：对于超大数组等大对象，JVM可能直接将其分配至老年代（或G1的Humongous区），从而绕过指针碰撞，直接查询空闲列表。
- 分配机制的退化：即使使用Parallel GC这类收集器，若TLAB设置过小或被禁用（-XX:-UseTLAB），线程争抢全局指针失败后，分配过程也会退化为使用空闲列表。
线程安全：由配套机制保障，而非分配算法固有
需要明确的是，指针碰撞算法本身并不具备线程安全性——多个线程并发移动同一指针必然导致数据错乱。因此，JVM通过配套机制来保障并发安全：
- TLAB是主流解决方案：为每个线程预先在Eden区分配一小块私有内存，线程各自维护本地指针，实现完全无锁的快速分配。
- 同步申请作为后备方案：当TLAB耗尽或未启用时，线程需同步申请Eden区的公共空间，此时会采用CAS（比较并交换）等原子操作来安全更新全局指针。
- 空闲列表同样需要并发保护：对空闲列表的增删操作涉及共享数据结构，需要通过锁机制或无锁数据结构（如ZGC使用的并发链表）来保证数据一致性。
