java string不可变性是设计优势，但高频拼接等场景易致内存压力；应善用stringbuilder/stringbuffer、模板化日志、参数化sql、uri构建器及charsequence/char[]延迟转string等策略优化。
Java 中 String 的不可变性是设计优势，但确实会在高频拼接、动态构造或大量中间字符串生成的业务场景中引发内存压力。关键不是否定不可变性，而是用对工具、避开陷阱。
明确哪些操作真正触发新对象创建
不是所有“看起来像修改”的操作都会浪费内存，要区分清楚：
- concat()、+（非编译期常量）、substring()（JDK 7u6 之前）：每次调用都新建 String 对象，且底层 char[]/byte[] 被完整复制；
- String.valueOf()、String.copyValueOf()：若入参已是字符串或数组，通常不额外拷贝内容，但仍有新 String 实例；
- toLowerCase()/toUpperCase() 等转换方法：只要字符实际变化，就新建对象；若原串已满足条件（如全小写时调 toLowerCase），JDK 8+ 多数实现会直接返回 this，避免冗余对象；
- 正则替换（replaceAll、replaceFirst）：内部使用 StringBuilder 构建结果，但最终仍 new String(...) 返回，且匹配过程可能产生多个临时 CharSequence。
高频拼接场景统一用 StringBuilder 或 StringBuffer
尤其在循环内拼接、日志组装、SQL 动态构建、JSON 片段生成等业务逻辑中，禁止用 + 或 concat 拼接多个变量：
- 单线程环境优先选 StringBuilder（性能更高）；
- 多线程共享拼接器时才考虑 StringBuffer（同步开销可接受）；
- 初始化时尽量预估容量：
new StringBuilder(256)，避免数组多次扩容复制； - 拼接完成后只调一次 toString() 获取最终字符串，不要在循环中反复调用。
复用已有字符串，减少中间态生成
很多业务其实不需要“实时构造”，可通过结构优化规避无谓创建：
- 日志模板化：用 SLF4J 的 {} 占位符（如
log.info("User {} logged in at {}", userId, time)），参数不拼接成字符串，仅在启用日志级别时才格式化； - SQL 参数化：用 PreparedStatement 替代字符串拼接 SQL，既防注入又省 String 对象；
- 路径/URL 构造：使用 java.net.URI 或 Spring 的 UriComponentsBuilder，它们内部缓存并复用组件，比手动拼接更可控；
- 配置键名、枚举标识等固定组合，可提前定义为 static final String 常量，避免运行时重复计算。
必要时用 CharSequence 或 char[] 延迟转 String
当字符串只是中间载体，后续还要解析或校验（如解析 JSON 字段、校验手机号格式），可暂缓 toString：
- 接收输入时，若来源是 CharBuffer、StringBuffer 或文件流，先以 CharSequence 接口处理，直到必须传给 String 专属 API 时再转；
- 做子串提取且确定不会跨方法传递时，用 String.substring(int, int) 在 JDK 9+ 是安全的（底层共享 byte[]，无拷贝）；
- 敏感字段（如密码、token）处理中，用 char[] 承载，操作完立即
Arrays.fill(pwd, '\0')清空，避免 String 长期驻留堆中无法清除。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
