stringbuilder高效拼接因底层用可变char[]数组（默认16）直接修改，仅扩容时新建数组；无synchronized导致非线程安全；单线程下免同步开销，性能优于stringbuffer约10%–15%。
查Java StringBuilder核心大纲面试题，关键不是背题库，而是抓住三个底层逻辑：可变性怎么实现、线程安全为何缺失、性能优势从哪来。掌握这三点，所有变形题都能拆解。
StringBuilder为什么能高效拼接字符串
它内部用一个可变的char[]数组（默认容量16）存字符，所有append、insert、delete操作都直接改这个数组，不新建对象。只有当数组装不下时，才按“原容量×2+2”扩容——比如16→34→70，避免频繁分配内存。
- String每次“+”都会生成新对象，循环1万次就创建1万个String，触发GC压力
- StringBuilder同一对象反复修改，只在必要时扩容，内存和CPU开销小得多
- toString()只是把当前value数组复制封装成String，不额外拷贝内容
StringBuilder和StringBuffer到底差在哪
代码层面几乎一样，区别全在方法签名上：StringBuffer每个public方法都加了synchronized，StringBuilder完全没加。
- 多线程往同一个StringBuilder里append，可能丢数据、顺序错、甚至数组越界
- StringBuffer加锁保证原子性，但单线程下锁本身就有10%~15%性能损耗
- 实际项目中95%以上字符串操作都在单线程（如Controller参数拼接、日志组装），选StringBuilder是默认选择
String转StringBuilder和反过来怎么写
不能强制类型转换，必须走构造或方法调用：
- String → StringBuilder：new StringBuilder(str) 或 new StringBuilder().append(str)
- StringBuilder → String：sb.toString() —— 注意不是sb + ""，那会触发隐式转换再创建新String
- 别写sb.toString().intern()除非真要进常量池，日常场景纯属画蛇添足
面试常挖的细节陷阱
考官爱问“为什么StringBuilder不是final类”“count字段干啥用”“扩容失败会怎样”，其实都在验证你是否看过源码。
- value是char[]，count是当前有效字符数（≤value.length），扩容只看count是否超限
- 不是final，是因为JDK设计允许继承（虽然极少有人这么干）
- 扩容时如果新容量超过Integer.MAX_VALUE - 8，直接抛OutOfMemoryError，不是静默截断
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
