高频线程创建会引发年轻代GC异常：Eden分配失败频次陡增、Survivor存活率持续超40%、老年代晋升速率突变，以及GC日志中频繁出现“to-space overflow”或“promotion failed”，表明存在逻辑分配碎片与空间错配。
原生线程本身不直接在 java 堆中分配对象，但高频创建线程（如大量 new thread() 或使用短生命周期线程池）会间接引发大量短期对象生成——比如线程局部变量、threadlocal 中的值、栈帧中的临时对象、线程启动时的 runnable 包装、threadgroup 关联结构等。这些对象绝大多数落在年轻代，其分配与回收行为会显著反映在年轻代 gc 曲线中。空间碎片不是年轻代的主要问题（因采用复制算法），但“eden 区分配失败频次”“survivor 区存活率突变”“对象晋升速率异常上升”等曲线特征，恰恰能反向揭示隐性碎片风险或配置失配。
看 Eden 分配失败频率是否呈现锯齿状陡升
高频线程创建导致 Eden 区被快速填满，Minor GC 触发变频繁。若 GC 日志中 GC pause (G1 Evacuation Pause) 或 [GC (Allocation Failure)] 出现密集、非周期性的尖峰（例如每 200ms 就触发一次），说明 Eden 空间不足以承载当前线程创建节奏。这不是传统意义的“内存碎片”，而是“逻辑分配碎片”——即每次线程创建伴随一组小而分散的对象（如 Thread 实例 + ThreadLocalMap.Entry[] + 异常栈快照等），它们虽小但分布零散、生命周期高度同步，导致 Eden 在未真正耗尽前就因“无法找到连续空闲块满足某次批量分配”而提前失败（尤其在开启 -XX:+UseAdaptiveSizePolicy 且 Survivor 空间被反复压缩时）。此时应关注 Eden size 与 avg mutator allocation rate 的匹配度。
观察 Survivor 区存活对象大小占比曲线是否持续走高
正常情况下，Survivor 区只保留极少量熬过 Minor GC 的对象。若线程创建后绑定了非空 ThreadLocal（如日志 MDC、事务上下文、监控 traceId），这些值会随线程存活而驻留 Survivor；更关键的是：JVM 为每个线程分配的栈空间（-Xss，默认1MB）虽不在堆中，但其初始化过程可能触发堆内辅助对象（如 java.lang.Thread$UncaughtExceptionHandler 实例、java.util.concurrent.locks.AbstractQueuedSynchronizer$Node 等）。当 Survivor 中 used / capacity 比值在多次 Minor GC 后稳定高于 40%，或出现阶梯式跃升，说明有大量中龄对象滞留——这会挤压后续新生对象的复制空间，间接加剧 Eden 分配压力，形成“伪碎片感”。此时需检查 ThreadLocal 是否泄漏、是否误将大缓冲区存入线程局部变量。
追踪老年代晋升速率是否在无 Full GC 时突然跳变
年轻代空间本身不产生物理碎片，但晋升行为是碎片影响的放大器。若线程创建伴随大对象（如预分配的 byte[8192] 缓冲区、自定义线程上下文容器），且尺寸超过 -XX:PretenureSizeThreshold，会直接进入老年代；更隐蔽的是动态年龄判定机制：当某次 Minor GC 后，Survivor 中所有年龄 ≥ N 的对象总和 > Survivor 总容量 50%，则所有 ≥ N 年龄对象全部晋升。高频线程创建易触发该条件，导致老年代“悄悄膨胀”。此时即使年轻代 GC 曲线平稳，老年代使用率曲线却出现斜率突增，意味着年轻代已无法有效拦截本该短命的对象——本质是分代边界被业务模式击穿，属于结构性空间错配，需比照碎片问题对待。
结合 GC 日志中的 “promotion failed” 与 “to-space overflow” 事件
这两个日志条目是年轻代空间健康度的硬指标：
• to-space overflow 表示本次 Minor GC 中，存活对象总量超出目标 Survivor 区容量，部分对象被迫直接晋升——这是年轻代内部“复制空间不足”的明确信号，常由 Survivor 区过小或对象存活率异常升高引起；
• promotion failed 更严重，指老年代剩余空间不足以接收本次晋升对象，被迫触发 Full GC。即便未达 Full GC，只要日志中频繁出现前者，就说明年轻代的复制式管理已逼近临界点，虽无传统碎片，但空间利用率已严重劣化，等效于存在功能性碎片。
