eden区对象创建速率接近阈值是minor gc频繁触发的直接信号；观察jstat中eu每秒增长超ec的10%且young gc间隔几百毫秒，可判定字符串拼接为主因。
看 Eden 区对象创建速率是否接近阈值
Minor GC 频繁触发的直接信号，是 Eden 区在短时间内被填满。字符串拼接产生的临时 String 对象几乎全落在 Eden 区——它们生命周期极短，创建后立刻不可达。用 jstat -gc <pid></pid> 观察 EC（Eden 容量）和 EU（Eden 已用）变化：若每秒 EU 增长超过 EC 的 10%，且 Young GC 间隔稳定在几百毫秒级，基本可判定拼接是主因。
别只盯着 GC 次数，重点查每次 GC 后的 Survivor 区存活率
频繁拼接本身不一定会让对象“活过”一次 Minor GC，但若拼接逻辑中混入了隐式缓存（如 String.intern()、静态 Map<string object></string> 存储中间结果），或拼接后立即塞进长生命周期容器（如类字段、静态集合），就会导致大量本该回收的对象晋升到 Survivor 或老年代。此时 jstat 中 S0U/S1U 在 GC 后不归零，或 YGC 次数未增但 FGC 开始出现，就是危险信号。
用 -XX:+PrintGCDetails 日志定位具体哪段代码在“产对象”
开启 GC 日志后，重点关注每条 GC pause (G1 Evacuation Pause) 或 PSYoungGen 记录前后的线程堆栈（需配合 -XX:+PrintGCTimeStamps 和应用日志时间戳对齐）。常见高产场景包括：
- 循环内用
+拼接多个String，例如result = result + "a" + i + "b" - 高频调用含
String.format()或 f-string 的日志方法，且日志级别未关闭 - JSON 序列化/反序列化中反复构建临时 key/value 字符串，尤其在
Map.entrySet()遍历时
这些操作在字节码层面会生成大量 StringBuilder 实例（即使你没显式写），而每个 StringBuilder 又带一个 char[] 数组——这才是 Eden 区真正的“内存大户”。
Java 里 StringBuilder 复用不当反而加重 GC 压力
很多人以为用 ThreadLocal<stringbuilder></stringbuilder> 就万事大吉，但若复用后没清空内容（sb.setLength(0)），而是反复 new StringBuilder() 再丢弃，或者在异步线程中误用同一个实例，会导致 StringBuilder 缓冲区持续膨胀，最终触发更大块的数组分配。更隐蔽的问题是：如果复用的 StringBuilder 初始容量设得过大（比如固定 64KB），而实际每次只拼 200 字节，等于长期占用无用内存，既浪费 Eden 空间，又拖慢 GC 扫描速度。
toString() 调用背后可能触发三次 new char[]，而这种细节只有结合 JFR（Java Flight Recorder）的内存分配事件才能准确定位。单纯看 GC 频次或堆大小，容易把问题归给配置，而不是代码。
