StringBuilder的核心是char[] value+int count，默认容量16，扩容公式为oldCapacity*2+2，toString()才创建新String；局部使用线程安全，共享实例需谨慎；性能优于String拼接和StringBuffer，但字面量拼接最快。
Java StringBuilder 面试深度复习，重点不在背定义，而在讲清“为什么”和“怎么用对”。面试官真正想听的，是你是否理解它在JVM内存、线程模型和性能权衡中的真实位置——不是复述API文档，而是能结合场景说清取舍逻辑。
底层实现：不是“数组+扩容”，而是“可变容器的设计契约”
StringBuilder 的核心是 char[] value + int count，但关键细节常被忽略：
- 默认容量是16，不是“随便定的”——它平衡了初始开销与常见小字符串操作（如拼接URL路径、日志前缀）的效率
- 扩容公式是 newCapacity = oldCapacity * 2 + 2，不是简单翻倍；当 oldCapacity 接近 Integer.MAX_VALUE/2 时，可能直接溢出抛 OOM
- value 数组长度 ≥ count，count 才是当前有效字符数；toString() 时才 new String(value, 0, count)，避免复制冗余空间
线程安全：不加锁 ≠ 不能用，而要看“谁持有它”
StringBuilder 方法没 synchronized，但面试容易陷入“多线程就错”的误区：
- 局部变量场景（如方法内 new StringBuilder().append(...)）——完全安全，无需任何同步
- 共享实例场景（如作为类字段被多个线程并发调用 append）——确实会丢数据，比如两个线程同时写入，count 更新不同步导致覆盖
- 替代方案不是盲目换 StringBuffer，而是优先考虑：能否改用局部变量？能否用不可变对象+函数式拼接？
性能对比：别只说“StringBuilder更快”，要说清快在哪、快多少
对比对象要分层：
立即学习“Java免费学习笔记（深入）”；
- vs String 拼接（+）：循环中 s += "x" 每次都 new String，触发 GC；StringBuilder 复用数组，实测 10 万次拼接，耗时差 5–10 倍
- vs StringBuffer：单线程下 StringBuilder 快约 10%–15%，因为省掉 monitor enter/exit 开销；热点代码中这个差距会被放大
- vs 字面量拼接（"a"+"b"+"c"）：编译期优化为常量，比 StringBuilder 还快——所以不是所有拼接都要改，先看是否含变量
实战选型：三句话判断该用谁
遇到字符串拼接，快速决策链：
- 纯字面量、无变量 → 直接用 "a"+"b"（编译优化，最简最稳）
- 单线程、需多次修改（如构建SQL、JSON、日志内容）→ 用 StringBuilder，记得预估容量避免频繁扩容
- 多线程共享同一实例且必须并发修改 → 用 StringBuffer；但更推荐重构：拆成局部 StringBuilder + 最终合并，或用 ThreadLocal
