StringBuilder与StringBuffer的核心区别是线程安全：StringBuffer方法均加synchronized，StringBuilder无同步，单线程下后者性能高10%–15%；二者底层均为char[]+count，API和扩容逻辑一致；多线程写同一实例必须用StringBuffer，局部拼接首选StringBuilder；均不可作Map key；append对包装类null输出"null"，toString()频繁调用易致GC压力。
StringBuilder 和 StringBuffer 的核心区别在哪
线程安全是唯一本质差异：StringBuffer 所有公开方法都加了 synchronized，StringBuilder 完全没有。这意味着在单线程场景下，StringBuilder 性能通常高 10%–15%，而 StringBuffer 多余的同步开销白费。
别被“Buffer”字面误导——两者底层都是 char[] 数组 + count 计数器，扩容逻辑、API 设计（append、insert、delete、reverse）几乎完全一致。
- 多线程写入同一实例？必须用
StringBuffer，否则可能抛ArrayIndexOutOfBoundsException或静默数据错乱 - 仅在局部方法内拼接（比如循环构建日志字符串）？无条件选
StringBuilder - 用作 Map 的 key 或跨线程传递？都不合适——二者都未重写
equals/hashCode，且可变性本身违反 key 不可变原则
append() 调用链中的隐式装箱和 toString() 陷阱
append() 系列方法对基本类型（int、boolean）直接转字符串，但对包装类（Integer、Boolean）会触发自动拆箱——如果传入 null，StringBuilder.append(Integer) 会直接拼出字符串 "null"，而非抛 NullPointerException；而 StringBuffer 行为完全相同，这点常被误认为线程安全带来的差异。
真正危险的是 toString()：它返回新创建的 String 对象，内容是当前内部数组的副本。频繁调用（比如在循环里反复 toString()）会制造大量临时对象，GC 压力陡增。
立即学习“Java免费学习笔记（深入）”；
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
sb.append(i);
String s = sb.toString(); // 每次都新建 String！
}- 如需最终结果，只在最后调用一次
toString() - 若中间需校验长度，用
sb.length()，别用sb.toString().length() - 避免在日志中写
log.info("result: {}", sb)——SLF4J 会隐式调用toString()，改用log.info("result: {}", sb.toString())更明确，也方便调试时打断点
初始容量设多少才不浪费也不扩容
两者默认构造函数都分配长度为 16 的 char[]。一旦超出，会按 newCapacity = oldCapacity * 2 + 2 扩容（JDK 8+），并复制原数组。频繁扩容=频繁内存分配+数组拷贝。
本文档主要讲述的是Android数据格式解析对象JSON用法；JSON可以将Java对象转成json格式的字符串，可以将json字符串转换成Java。比XML更轻量级，Json使用起来比较轻便和简单。JSON数据格式，在Android中被广泛运用于客户端和服务器通信，在网络数据传输与解析时非常方便。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
估算依据不是“字符个数”，而是“最大可能总长度”。例如拼接 100 个平均长度 20 的字符串，加上分隔符和前缀，预估 2200 字符，就该写 new StringBuilder(2200)。
- 完全无法估算？宁可略大（如 1024），别用默认 16——尤其在高频调用的方法里
- 已知固定长度（如生成 32 位 UUID），直接传精确值：
new StringBuilder(36) -
StringBuffer同样适用此规则，扩容逻辑与StringBuilder完全一致
为什么 replace() 和 delete() 的索引范围容易出错
所有涉及索引的操作（replace(int start, int end, String str)、delete(int start, int end)、substring(int start, int end)）都遵循“左闭右开”区间：包含 start，不包含 end。这是最常翻车的地方。
例如 sb.replace(0, 5, "XXX") 是把第 0、1、2、3、4 这 5 个位置替换成 "XXX"，不是替换前 5 个字符后还剩啥——如果原字符串只有 3 个字符，end=5 会直接抛 StringIndexOutOfBoundsException。
- 检查边界前先调用
sb.length()，别假设长度够 - 用
sb.indexOf("target")获取位置后，注意返回-1时不能直接传入replace() -
deleteCharAt(int index)删除单个字符更安全，它只接受一个有效索引（0 ）
线程安全不解决逻辑错误，StringBuffer 在索引越界时同样抛异常，不会默默吞掉错误。
