TLAB是线程私有的逻辑分配缓存，依附于单个Eden Region，不构成独立物理区域、不嵌套于Region结构、不跨Region边界；其大小远小于Region，默认仅在Eden内动态划分与 refill。
TLAB（Thread Local Allocation Buffer）在 G1 中不构成独立的物理内存区域，它也不是 Region 的子结构或布局单元。理解这一点是解构的关键前提——TLAB 是一种线程私有的、逻辑上的对象分配缓存机制，运行在 Region 的上层，依附于 Eden Region 分配，但本身无固定地址范围、不改变 Region 物理排列、也不跨越 Region 边界存储。
? TLAB 与 Region 的物理关系：依附而非嵌套
- TLAB 是每个应用线程在 Eden Region 中动态划出的一小块连续空间，用于快速分配小对象；
- 它完全位于单个 Eden Region 内部，大小通常为几 KB 到几百 KB（受
-XX:TLABSize或启发式控制），远小于 Region 默认大小（如 1–4 MB）； - 一旦当前 Eden Region 空间不足或 TLAB 填满，线程会申请新的 TLAB，但新 TLAB 仍严格落在下一个可用的 Eden Region 中，不会跨 Region 拼接；
- 所以：TLAB 不打破 Region 的边界完整性，Region 仍是 G1 管理和回收的最小物理单位。
✅ 示例：堆设为 4GB，Region 大小 ≈ 2MB（4096MB ÷ 2048），一个线程的 TLAB 即使设为 512KB，也只占该 Eden Region 的约 1/4；当填满后，下一次分配直接跳转到另一个空闲 Eden Region，从头分配新 TLAB。
⚙️ TLAB 如何在 G1 的 Region 动态体系中运作
-
分配源头绑定 Eden Region：所有 TLAB 都从当前活跃的 Eden Region 中切分，G1 的
allocate_new_tlab()流程会检查目标 Region 是否为 Eden 类型且有足够空闲空间； - 不参与 Region 角色切换：TLAB 只是临时标记段，Region 本身的类型（Eden/Survivor/Old/Humongous）由 GC 周期决定，TLAB 存在与否不影响其角色；
- 无跨 Region 引用管理开销：因为 TLAB 内对象都来自同一 Region，新生对象间的引用（如局部对象图）天然不跨 Region，无需写屏障立即更新 RSet；
- 大对象绕过 TLAB：≥ ½ Region 大小的对象（即可能进入 Humongous Region）直接走慢速分配路径，不使用 TLAB，避免碎片与跨区风险。
? 跨区域分配边界的本质：由 Region 大小与对象尺寸共同定义
G1 中“跨区域”的真正边界，取决于：
- Region 固定大小（如 2MB）→ 决定 Humongous 对象阈值（≥1MB）；
- 对象大小 → 若对象 ≤ TLAB 剩余空间 → 分配成功；否则触发 TLAB refill 或直接分配到 Eden；
-
refill 策略 → refill 失败时，线程退化为共享 Eden 的“全局分配指针”（
top），但仍限于当前 Eden Region；只有该 Region 耗尽，才会切换到下一个 Eden Region； -
无“TLAB 跨 Region”行为：JVM 源码（如
G1Allocator::attempt_allocation_slow()）明确要求 TLAB 必须在单 Region 内完成，否则返回 null 并触发 slow-path。
? 实际验证建议（非理论推演）
若需观察 TLAB 与 Region 的实际映射关系，可启用以下 JVM 参数组合：
-XX:+UseG1GC \ -XX:+PrintGCDetails \ -XX:+PrintTLAB \ -Xlog:gc+tlab=debug \ -XX:TLABSize=64k
日志中将出现类似：
TLAB: gc thread: 0x00007f... size: 65536 used: 49280 -> refill Refilling TLAB for thread 0x00007f..., new region: 0x00000007c0000000 (Eden)
其中 new region: 0x00000007c0000000 即指向某 Eden Region 的起始地址，可结合 jhsdb jmap --heap 查看 Region 类型与地址分布。
不复杂但容易忽略
