eden区是tlab的母体而非后备，tlab从eden中划分，其稳定性依赖eden足够大、结构健康；eden过小会限制tlab伸缩空间，导致频繁refill或fallback至共享区竞争分配。
Eden 区不是 TLAB 的“后备”，而是 TLAB 的“母体”——TLAB 本身是从 Eden 中划分出来的私有缓冲区。所谓“为 TLAB 提供深厚后备底座”，本质是让 Eden 足够大、结构足够健康，使得每个线程的 TLAB 能稳定 refill、低碎片、少 fallback，从而扛住突发小对象洪峰。
Eden 大小决定 TLAB 可伸缩空间上限
TLAB 初始大小默认约为 Eden 的 1%，且 HotSpot 会动态调整（启用 -XX:+ResizeTLAB 时）。如果 Eden 本身太小，比如仅 64MB，那即使 ResizeTLAB 开启，单个 TLAB 最多也就 640KB 左右，面对每秒数百次小对象分配，极易触发频繁 refill 或退化到共享 Eden 区竞争分配。
- 年轻代总大小建议设为堆的 1/3～1/2（如 -Xms4g -Xmx4g -Xmn2g），避免老年代挤压导致晋升压力提前传导
- 在 -Xmn 固定前提下，增大 Eden 比例（即调小 -XX:SurvivorRatio）可直接扩大 TLAB 可用池。例如 SurvivorRatio=4（Eden 占 66.7%）比默认值 8（Eden 占 80%）更优？不，8 才是 Eden 更大的配置：SurvivorRatio=8 → Eden : S0 : S1 = 8:1:1 → Eden 占年轻代 80%
- 真正要扩 Eden，应保持 SurvivorRatio=8，并把 -Xmn 往上调；盲目调小 SurvivorRatio（如设成 2）反而压缩 Eden、撑大 Survivor，浪费本可用于 TLAB 的空间
避免 Eden 内部碎片反噬 TLAB 稳定性
TLAB 分配依赖 Eden 的连续空闲内存。若 Eden 频繁 GC 后留下大量细碎空洞（尤其在 Survivor 区过小、对象快速晋升或幸存对象尺寸离散时），即使 Eden 总使用率才 40%，也可能因缺乏足够连续空间而无法为线程分配新 TLAB，迫使对象走慢路径（CAS 分配）——这就是竞价引擎“假死”的物理根源。
- 监控 GC 日志中 Eden 的实际占用曲线（-XX:+PrintGCDetails），关注每次 Minor GC 后 Eden 是否能近乎清零；若长期残留 15%+，说明对象存活率异常，需检查是否 Survivor 空间不足或对象生命周期模型突变
- 确保两个 Survivor 区大小合理（-XX:SurvivorRatio=8 是起点），避免因 S0/S1 过小导致对象“被迫早熟”晋升至老年代，间接加剧 Eden 碎片化
- 突发流量下若观察到大量 “slow path allocation” 日志（需 -XX:+PrintTLAB + -XX:+UnlockDiagnosticVMOptions），优先排查是否 Eden 连续空闲页被破坏，而非立刻调大 TLABSize
用真实流量驱动 TLAB 与 Eden 的协同调优
静态参数无法应对动态业务。TLAB 不是越大越好，Eden 也不是越宽越稳——关键在两者节奏匹配。
- 开启 -XX:+PrintTLAB 运行 3–5 分钟典型突发流量（如大促压测），重点看每秒各线程的 refill 次数和 waste 值：refill > 10/s/线程 或 waste > 5% 都说明当前 Eden+TLAB 组合失配
- 若 refill 高但 waste 低 → Eden 足够，但 TLAB 初始太小或 Resize 策略滞后 → 启用 -XX:+ResizeTLAB（默认已开），并确认未禁用 -XX:+UseTLAB
- 若 waste 高且 refill 也高 → 对象尺寸离散（如 64B/256B/1024B 混杂），TLAB 难以填满又不敢留太多余量 → 此时加大会加剧内存浪费，应优化对象池复用或统一小对象规格，而非硬调参数
不碰红线：TLAB 与 Eden 的安全边界
TLAB 是 Eden 的子集，所有 TLAB 总和不能超过 Eden 可用空间。盲目放大单个 TLAB（如 -XX:TLABSize=2m）可能在高并发线程数下瞬间吃光 Eden，导致大量线程同时 fallback 到共享区，引发 CAS 竞争风暴。
- TLAB 总占用理论峰值 ≈ 线程数 × 平均 TLAB 大小。若应用常驻 200 线程，设 TLABSize=1m，则仅 TLAB 就占掉 200MB Eden 空间，必须确保 Eden ≥ 256MB 以上才留有余地
- 永远不要关闭 -XX:+ResizeTLAB；固定 TLABSize 是懒办法，在低峰期浪费内存，高峰时仍 refill
- 当出现 “TLAB too small for allocation” 或大量 “slow path” 时，第一反应不是加内存，而是查 -XX:+PrintTLAB 日志定位是 refill 频率问题，还是 Eden 连续空间枯竭问题
