java string性能优化核心在于理解其不可变性设计：通过常量池复用、byte[]紧凑存储、hashcode缓存提升效率，拼接需用stringbuilder避免临时对象爆炸，字面量优先、慎用new和intern。
Java 中 String 处理的性能问题，核心不在“怎么写”，而在“怎么理解它的行为”。String 的不可变性不是限制，而是为内存复用、缓存和安全铺路——真正影响性能的，是开发者是否顺着这个设计逻辑去用。
字符串创建：优先字面量，慎用 new
双引号字面量（如 "user"）自动进入常量池，JVM 会复用已有实例；而 new String("user") 总是在堆中新建对象，即使池里已存在相同内容。这不仅多占内存，还绕过所有优化机制。
- 推荐写法：String s = "config";
- 避免写法：String s = new String("config");
- 特殊情况需 intern：仅对少量、长期复用的字符串（如协议名、状态码），才考虑调用 .intern() 主动入池；大量或临时字符串调用反而加重元空间压力
拼接操作：按场景选工具，别迷信 +
+ 在编译期能确定数量的简单拼接（如 "a" + "b" + "c"）会被自动转为 StringBuilder，没问题；但一旦进入循环或动态构建，就会每轮都生成新 String 对象，引发临时对象爆炸。
- 单线程、高频拼接（如日志组装、JSON 构建）→ 用 StringBuilder，显式复用实例
- 多线程共享拼接器 → 用 StringBuffer（同步开销可接受时）
- JDK 25+ 可尝试 字符串模板（STR."Hello ${name}"），编译期生成高效字节码，兼顾可读与性能
内存观察：关注实际占用，而非表面长度
从 JDK 9 起，String 内部改用 byte[] + coder，对纯 ASCII 字符（英文、数字、符号）每个字符只占 1 字节，内存减半；含中文等则回退到 UTF-16（2 字节/字符）。这个切换完全透明，但直接影响堆内存用量。
- 不要只看 string.length()，它返回字符数，不是字节数
- 监控建议：用 JVM 自带的 jcmd
VM.native_memory summary 或 JFR（Java Flight Recorder）观察字符串相关堆外/堆内分配趋势 - 排查线索：若发现大量短字符串（如 ID、枚举值）长期驻留，检查是否该用 intern()；若发现大字符串频繁 GC，优先查 substring 或拼接逻辑是否触发了旧版遗留问题（JDK 7+ 已修复）
哈希与 Map：利用缓存，但别误判引用
String 的 hashCode() 只算一次并缓存，这让它成为 HashMap 最理想的 key 类型。但要注意：== 比较的是引用地址（常量池内相同字面量才为 true），.equals() 才比内容——混淆这两者会导致缓存失效或逻辑错误。
- 作为 Map key 时，只要内容一致，hashCode 就稳定，无需担心“修改导致 hash 变”
- 避免用 new String("key").equals(map.get("key")) 这类冗余判断；直接用字面量或已 intern 的字符串作 key 更可靠
- 若 Map 中 key 数量极大（如十万级配置项），String 的哈希缓存优势尤为明显，此时更要确保 key 创建方式统一、可复用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
