stringbuilder比string拼接快，因其基于可变字符数组复用内存、避免重复创建对象，时间复杂度从o(n²)降至o(n)；默认容量16，扩容策略为oldcapacity×2+2，预估长度应显式指定capacity；与stringbuffer本质区别在于无同步锁，支持jit内联与逃逸分析优化，单线程场景性能高10~20倍。
Java 中 StringBuilder 的面试题，重点不在背 API，而在理解它“为什么快”“何时用错”“和 String、StringBuffer 本质区别在哪”。真正能答出彩的，是能把底层原理、线程安全、扩容机制、JVM 优化（如字符串拼接的编译期优化）串起来讲清楚的人。
StringBuilder 为什么比 String 拼接快？关键在“可变”和“数组复用”
String 是不可变对象，每次“+”都会新建对象、复制内容；StringBuilder 内部维护一个 char[]（JDK 9 后是 byte[] + coder），append 时直接往数组末尾写，仅当容量不够时才扩容并复制一次。时间复杂度从 O(n²) 降到 O(n)。
建议回答时点明两个细节：
- 默认初始容量是 16，如果预估长度远大于此（比如拼接 1000 行日志），应显式指定 capacity，避免多次扩容（扩容策略：oldCapacity * 2 + 2）
- toString() 方法返回的是新 String 对象，但内部 char[] 是 copy 的（JDK 7u6 之后已修复“共享底层数组”的安全漏洞），所以不会意外影响原 StringBuilder
StringBuilder 和 StringBuffer 到底差在哪？别只说“线程安全”
表面看 StringBuffer 方法加了 synchronized，但真正影响性能的是锁粒度和 JIT 优化机会。StringBuilder 无锁，方法内联更彻底；StringBuffer 即使单线程运行，synchronized 也会抑制逃逸分析和锁消除（尤其在 JDK 8+ 默认开启的情况下）。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
面试官想听的是判断逻辑：
- 局部变量拼接（如方法内循环 append）→ 一定用 StringBuilder
- 成员变量被多个线程读写 → 要么加外部同步，要么用 StringBuffer（但更推荐用 ThreadLocal
或重构为无状态） - 别迷信“StringBuffer 更安全”，多数并发场景下它只是掩盖设计缺陷
这些代码看似正常，其实暴露了对 StringBuilder 的误解
面试常给一段代码让你找问题，典型陷阱有：
- 在循环外创建 StringBuilder，循环内反复 toString() + 重新赋值 → 忘了 clear() 或新建实例，导致越拼越长
- 用 sb.append(null) → 实际插入字符 'n','u','l','l'，不是空指针，但业务逻辑可能崩
- 链式调用后没接 toString()，直接 return sb → 返回的是 StringBuilder 对象，调用方拿到的是对象地址（toString 未重写前）
- 把 StringBuilder 当作 Map 的 key 或放入 HashSet → 它没重写 hashCode/equals，内容相同但对象不同，无法去重或查找
结合 JVM 看：编译器怎么“偷偷帮你优化” StringBuilder？
JDK 早期（String s = "a" + "b" + obj; 的表达式，在字节码里自动转成 StringBuilder.append；但 JDK 9+ 引入 StringConcatFactory，改用更加轻量的 MethodHandle 拼接（不创建 StringBuilder 对象），只有明确写出 new StringBuilder() 才真用它。
这意味着：
- 不要为了“性能”强行手写 StringBuilder 拼接简单字符串（如固定两三个字面量）
- 循环内拼接、动态长度拼接、多线程外的批量构建 —— 这些才是 StringBuilder 的主战场
- 如果用 Lombok 的 @ToString 或 Jackson 序列化大量对象，背后可能高频触发 StringBuilder，这时 capacity 预估就很重要
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
