seata at模式下undo_log表是分布式事务回滚的核心组件，用于存储前后数据镜像，其正确配置（如xid+branch_id唯一索引、utf8mb4字符集、longblob字段）直接决定回滚成败。

这个问题存在概念混淆，需要先厘清几个关键点：

TLAB（Thread Local Allocation Buffer）是 JVM 的堆内存分配机制，属于 Java 应用层运行时概念；而分布式事务回滚块（如 Seata 的 undo_log、OceanBase 的事务上下文、MySQL 的 XA 分支回滚逻辑）属于数据库中间件或存储引擎层的事务控制结构。二者不在同一技术栈，不存在“在分布式事务回滚块内创建描述符”从而直接穿透 TLAB 的因果路径。

换句话说：

• 数据库事务回滚本身不创建 Java 对象，不分配 TLAB 内存；
• 若你在应用代码中（例如 Seata AT 模式下的 undo_log 构造、或自定义回滚逻辑里）手动 new 了超大对象（如兆级 byte[]、嵌套极深的 DTO、未限制长度的 StringBuilder.append() 累积），且该操作发生在全局事务注解（如 @GlobalTransactional）包裹的方法内——那真正导致 TLAB 瞬间耗尽的，是这段应用层代码的内存行为，而非“回滚块”本身。

所以，真实可排查的方向是：

1. 定位异常内存分配点

检查是否在事务方法中执行了以下高危操作：

• 使用 new byte[1024 * 1024 * 100] 类似方式构造超大缓冲区；
• 将整张表导出为 JSON 字符串并保存到局部变量；
• 在循环中不断 list.add(largeObject) 且未做分批控制；
• 调用第三方 SDK 时传入未校验长度的原始数据（如 Base64 解码超长字符串）。

2. 观察 JVM 运行时表现

出现 TLAB 穿透典型现象包括：

• GC 日志中频繁出现 Allocation Failure，且 Eden 区每次回收后存活对象激增；
• jstat -gc <pid></pid> 显示 EU（Eden 使用量）持续接近 EC（Eden 容量），YGC 频次陡升；
• jstack 中看到线程卡在 java.nio.HeapByteBuffer.<init></init>、java.util.Arrays.copyOf 或 JSON 序列化入口（如 com.fasterxml.jackson.databind.ObjectMapper.writeValueAsString）。

3. 关联分布式事务上下文缩小范围

若问题只在开启全局事务时复现：

• 检查 @GlobalTransactional 方法内是否有非必要大对象构造；
• 确认 Seata 的 undo_log 表字段 rollback_info 是否被写入超长二进制（需检查 io.seata.rm.datasource.undo.parser.JacksonUndoLogParser 序列化逻辑及原始业务对象大小）；
• 查看 OCP 或日志中对应 trace_id 的 branch_register 和 branch_report 时间差——若 Phase1 执行耗时异常长，往往伴随大对象序列化阻塞。

4. 快速验证与规避

• 加 -XX:+PrintTLAB 启动参数，观察日志中是否出现 TLAB too small 或 slow allocation 提示；
• 临时在可疑方法开头加 System.gc()（仅用于验证，勿上生产），若之后不再崩溃，说明是短生命周期大对象冲击；
• 用 async-profiler 采集内存分配热点：./profiler.sh -e alloc -d 30 -f alloc.svg <pid></pid>，聚焦 top 函数中的 new 调用栈。

本质上，这不是分布式事务机制的问题，而是应用代码在事务边界内做了不合理的内存使用。修复重点在于：控制单次事务处理的数据规模、避免在事务方法中构造非必要大对象、对输入做长度/体积校验。