高频字符串拼接导致Eden区迅速填满并触发频繁Young GC，因每次“+”操作均创建StringBuilder和新String对象，对象生成速度远超GC回收能力。
因为每次用+拼接字符串，JVM都会隐式创建新对象，导致Eden区在极短时间内被大量短命对象填满，触发高频Young GC。
加号拼接的底层行为是高频对象创建
Java中String不可变，所以result += s不是原地修改，而是编译成类似以下逻辑：
- 新建一个
StringBuilder实例（分配在Eden区） - 调用
append(result)和append(s) - 调用
toString()生成全新String对象（JDK9+是byte[]，仍占堆） - 旧
result失去引用，但还留在堆里等回收
一次拼接至少产生2个新堆对象。死循环中每轮都如此，对象生成速度远超GC回收能力。
年轻代结构决定Eden区最先撑爆
新生对象默认进入Eden区，只有Eden满时才触发Minor GC。而+拼接产生的对象几乎全部“朝生夕死”：
立即学习“Java免费学习笔记（深入）”；
- 新
StringBuilder用完即弃，生命周期仅一轮循环 - 旧
String因被新结果替代而立即不可达 - 这些对象根本活不到Survivor区，更不会晋升老年代
结果就是Eden区几毫秒内就100%占用，jstat -gc会看到YGC次数飙升、Eden使用率长期卡在99%+。
GC跟不上分配节奏，本质是吞吐失衡
Young GC本身要耗时（哪怕几十毫秒），而现代CPU执行一次循环可能只要纳秒级。这意味着：
- 1秒内可能执行百万次拼接 → 生成200万个对象
- 一次Minor GC只能清理当前Eden中的存活对象，但几乎没存活者，只是“清空+复制Survivor中少量对象”
- 但GC线程跑不过应用线程分配速度，Eden反复填满→频繁暂停→CPU时间大量花在GC上
这不是内存总量不够，而是对象诞生太快、存活太短、GC来不及打扫，形成“扫地速度追不上扔垃圾速度”的局面。
如何快速确认是它引发的问题
不用猜，看三类证据：
- jstat观察：Eden使用率持续≥98%，YGC频率超过10次/秒，且每次GC后Eden仍接近打满
-
堆转储分析（MAT）：Top Consumers里
java.lang.String和java.lang.StringBuilder占比超60%，且retained heap集中于小对象 -
字节码反编译（
javap -c）：循环体内明确出现new StringBuilder和toString指令
