Java对象分配位置取决于GC算法、对象大小、TLAB开关及内存连续性：小对象优先TLAB，大对象可能直入老年代或G1的Humongous区；指针碰撞需内存规整且无碎片，否则回退空闲列表。
对象分配在堆上哪块区域？看 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），遍历链表找足够大的空闲块——这比指针碰撞慢，且需要加锁维护链表结构。
立即学习“Java免费学习笔记（深入）”；
空闲列表怎么管理？为什么 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 <pid>中的EC（Eden 容量）、EU（Eden 已用）差值接近对象大小，说明大概率是 bump；如果EU跳变不规律，可能是空闲列表拼出来的 - 禁用 TLAB（
-XX:-UseTLAB）后观察分配延迟突增，基本能反向印证原来靠的是 TLAB + bump
真正难的不是理解两种机制，而是意识到：JVM 从不保证某次分配一定走哪种路径，它只在当下选代价最小的那条。TLAB 填满、GC 刚结束、对象大小变化、甚至线程调度顺序，都可能让同一条 new 指令走完全不同的内存路径。
