java字符串优化需避免+拼接、善用stringbuilder预估容量、慎用intern()、构造时指定编码、禁用==比较、处理子串时强制隔离、缓存用带策略的工具。
Java里字符串用得多，但一不留神就吃掉大量内存。关键不是少用字符串，而是让每次创建、拼接、比较都更省资源。
拼接别用+号，尤其在循环里
每次用+=或+拼接，都会生成新String对象，旧对象进GC队列——循环100次，可能产生100个临时字符串。StringBuilder是专为这个场景设计的：
- 单线程环境直接用
StringBuilder，初始化时预估容量（比如new StringBuilder(256)），避免内部数组反复扩容 - 多线程且需同步拼接时，才考虑
StringBuffer，但多数业务场景其实不需要它 - 不要在循环外声明StringBuilder却在循环内反复
setLength(0)重用——不如每次新建，JVM对短生命周期对象优化得很好
重复字符串用intern()要懂边界
String.intern()能把字符串“钉”进常量池，相同内容只存一份。但它不是万能药：
- 只对真正高频重复的字符串有用，比如固定状态码（"SUCCESS"、"ERROR"）、枚举标识符
- JDK7以后常量池移到堆内存，但默认大小仅1009个桶，大量调用
intern()易引发哈希冲突，可用-XX:StringTableSize=60013调大 - 绝对避免对动态生成的字符串（如日志ID、时间戳、JSON字段值）调用
intern()，容易撑爆常量池，拖慢GC -
new String("abc").intern() == "abc"为true，但sb.toString().intern()这种链式调用要警惕——先生成堆对象再入池，反而多占一次内存
构造和比较时绕开隐形开销
字符串看似简单，构造和比较环节暗藏内存陷阱：
- 读取文件或网络数据后构建String，优先用
new String(bytes, StandardCharsets.UTF_8)而非new String(bytes)，后者依赖系统默认编码，可能触发额外字符集解析开销 - 永远不用
==比内容，除非确认两个变量都来自字面量或已明确调用过intern() - substring在JDK7之前会共享原char[]，导致小字符串持有了大数组的引用，现在虽已修复，但若处理超长文本切片，仍建议用
new String(str.substring(...))强制隔离 - 从JDK9起，String内部用byte[]替代char[]存储，对纯ASCII文本内存减半；但若混合中文等UTF-16字符，coder字段会自动切到双字节模式，无需手动干预
及时切断无用引用，防止缓存膨胀
字符串本身不可变，但持有它的容器可能长期存活：
- 静态Map缓存字符串结果时，用Guava Cache或Caffeine，配软引用+过期策略，而不是裸HashMap
- 处理完大文本（如XML/JSON解析结果）后，主动置空局部引用，尤其在长生命周期对象（如Servlet、Spring Bean）中
- 避免用String作为Map的key存储大量动态键（如用户输入的搜索词），改用规范后的token或哈希值，减少常量池压力
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
