答案是：string+=拼接在循环中会因频繁创建stringbuilder和string对象导致eden区迅速填满，触发高频young gc，最终oom。每次+=生成2个新对象，旧字符串立即不可达但暂未回收，jvm默认编译为完整对象创建流程，配合-xmx256m等参数可在3~10秒内复现崩溃。
直接用一段极简但具备破坏力的原生 Java 代码，就能复现“加号高频拼接 → Eden 区瞬间填满 → Young GC 频繁 → 最终 OOM”的全过程。关键不在于写得多复杂，而在于让 JVM 的内存行为暴露得足够快、足够清晰。
构造一个确定会崩溃的死循环拼接
下面这段代码在默认 JVM 参数（如 -Xmx256m）下，通常 3~10 秒内就会抛出 OutOfMemoryError: Java heap space：
public class StringPlusCrash {
public static void main(String[] args) {
String result = "";
int i = 0;
while (true) {
result += "x"; // 每轮都触发 new StringBuilder + toString()
i++;
if (i % 10000 == 0) {
System.out.println("loop " + i + ", result.length() = " + result.length());
}
}
}
}
说明：
• 每次 result += "x" 都等价于 new StringBuilder().append(result).append("x").toString()
• 每轮至少生成 2 个新对象：1 个 StringBuilder（短命）、1 个新 String（取代旧 result）
• 旧 result 立即不可达，但还堆里占着位置；新对象又立刻进来 → Eden 区飞速饱和
配合 JVM 参数观察崩溃过程
运行时加上诊断参数，不用工具也能看到底层行为：
-
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps：输出每次 GC 的时间、Eden 使用量、回收对象数 -
-Xmx256m -Xms256m：固定堆大小，加速暴露问题（避免扩容掩盖） -
-XX:+UseSerialGC（可选）：强制使用最简单的 GC，让现象更“干净”
你会看到日志中快速出现：[GC (Allocation Failure) [DefNew: 64960K->7104K(73728K), 0.0123456 secs]
且 DefNew（即年轻代）的 “before→after” 差值越来越小，Eden 几乎每次都是 99%+ 占用后才触发 GC。
反编译验证底层机制
编译后执行 javap -c StringPlusCrash，在 main 方法字节码里一定能找到：
new java/lang/StringBuilderinvokespecial java/lang/StringBuilder.<init></init>-
invokevirtual java/lang/StringBuilder.append（调两次） invokevirtual java/lang/StringBuilder.toString
这说明 JVM 确实把 += 编译成了完整对象创建流程，不是语法糖优化——每轮都在堆上申请新空间。
用 jstat 实时监控佐证
启动程序后另开终端，执行：jstat -gc <pid> 1000</pid>（每秒刷新一次）
你会看到：
• S0C/S1C 基本为 0（Survivor 区几乎没对象存活）
• EC（Eden 容量）稳定，但 EU（Eden 使用量）在几毫秒内从 0 冲到接近 EC
• YGC（Young GC 次数）每秒飙升至 10+ 次，YGCT（总耗时）持续增长
• 最终 OC/OU（老年代）也快速上升——因频繁 GC 导致部分对象被“误晋升”
