StringBuilder适合循环拼接大量字符串，因其可变性避免频繁创建对象；而String和+拼接在循环中每次生成新对象，JVM仅对编译期常量的+做优化。
StringBuilder 适合拼接大量字符串的循环场景
当需要在循环中反复追加字符串（比如构建日志、生成 HTML、组装 SQL 参数），StringBuilder 比 String 或 + 拼接快得多，因为后者每次都会创建新对象。JVM 不会对循环内的 + 做自动优化（仅对编译期常量才优化为 StringBuilder）。
常见错误现象：for (int i = 0; i 在大循环里会触发成千上万次对象分配和 GC。
- 推荐写法：
StringBuilder sb = new StringBuilder(); for (int i = 0; i - 注意初始容量：如果能预估最终长度，用
new StringBuilder(1024)避免多次数组扩容（默认容量 16，扩容策略是old * 2 + 2） - 不要在单次拼接中滥用：比如
"a" + "b" + "c"编译器已优化，用StringBuilder反而多此一举
多线程环境下不能直接用 StringBuilder
StringBuilder 是非线程安全的，所有方法都不加锁；若多个线程共享同一个实例并调用 append、setLength 等，会出现数据错乱或 ArrayIndexOutOfBoundsException（因内部 char[] 扩容与指针更新不同步）。
使用场景判断：只有明确单线程使用（如局部变量、方法内新建）才放心用 StringBuilder。
立即学习“Java免费学习笔记（深入）”；
- 替代方案：需要线程安全时改用
StringBuffer（方法加了synchronized），但性能略低 - 更现代的做法：用不可变对象 + 函数式风格，比如
Stream.collect(Collectors.joining())，避免共享可变状态 - 误用示例：
static StringBuilder sb = new StringBuilder();被多个 servlet 请求共用 → 必出问题
StringBuilder 的 toString() 不复制底层 char[]
toString() 方法返回的是一个新 String 对象，但 JDK 7u6 之后的版本已移除 String 的 char[] 共享机制，所以它一定会复制内容 —— 这不是 bug，是安全设计。这意味着你不能靠“不复制”来省内存。
影响点在于性能敏感路径：如果拼接后只读一次，又立刻丢弃 StringBuilder，那这次复制不可避免；但如果后续还要多次修改，就别频繁调用 toString()。
- 避免模式：
sb.toString().length(); sb.toString().indexOf(...);→ 改用sb.length()、CharSequence接口或自己遍历sb.charAt(i) - 扩容时的复制成本更高：一旦触发
Arrays.copyOf，不仅toString()复制，扩容本身也复制整个数组 - JDK 9+ 使用
byte[]存储字符串，StringBuilder内部仍是char[]，两者无共享优化可能
替换、截取、插入等操作比 String 更高效
当需要在字符串中间做修改（如替换某段、删除区间、插入字符），StringBuilder 的 replace()、delete()、insert() 都是原地操作（基于数组移动），比 String.substring() + 拼接快，且不产生中间 String 对象。
典型场景：解析协议帧、处理模板文本、清洗日志行。
- 示例：把第 5~10 位替换成星号：
sb.replace(5, 10, "*****");，比s.substring(0,5) + "*****" + s.substring(10)少两次拷贝 - 注意索引越界：所有带下标的方法（
charAt、delete、setCharAt）都用StringIndexOutOfBoundsException，不是NullPointerException或IllegalArgumentException - 慎用
reverse()：它会真实翻转内部数组，如果只是临时需求，考虑用Collections.reverse(Arrays.asList(...))或流式倒序
实际项目里最容易被忽略的是容量预估和线程归属——很多人只记得“StringBuilder 快”，却在静态字段里复用它，或者在百万级循环里用默认容量反复扩容。这些地方一出问题，表现往往是偶发性错字、长度异常或 GC 时间飙升，而不是直接报错。
