不可变性确保哈希值恒定，使string可安全缓存hash字段：首次调用hashcode()计算并存储，后续直接返回，避免重复计算；若字符串可变，哈希值变化将导致hashmap等集合查找失败、数据错乱。
Java 中 String 的不可变性（immutability）是设计核心，而缓存哈希值（cached hash code）正是这一特性的直接受益者——正因为字符串内容永远不会变，所以它的哈希值算一次就能永久复用。
为什么不可变性让哈希值缓存安全？
哈希值用于 HashMap、HashSet 等集合的快速查找。如果字符串可变，比如 s = "abc" 先放进 HashSet，之后又改成 "def"，那它原本在桶中的位置就失效了，集合结构会被破坏，导致查不到、重复插入甚至死循环。
不可变性彻底杜绝了这种风险：对象一旦创建，value[] 数组和字段（包括 hash）就锁定。所以可以在第一次调用 hashCode() 时计算并缓存到私有字段 hash 中，后续直接返回，不用重复遍历字符数组。
缓存机制是怎么实现的？
看 JDK 源码（以 JDK 17 为例）：String 类内部有一个 private int hash; 字段，默认为 0。每次调用 hashCode() 时：
- 先检查
hash != 0—— 若已计算过，直接返回； - 否则按公式
s[0]×31^(n−1) + s[1]×31^(n−2) + … + s[n−1]计算，并赋值给hash； - 注意：初始值为 0 是合理的，因为合法哈希值也可能为 0（如空字符串 `""` 的 hash 就是 0），所以 JDK 还额外用一个标志位（或约定
hash == 0 && value.length > 0表示未计算）来区分，不同版本策略略有差异，但本质一致。
面试官可能追问的点 & 如何回应
Q：那如果我用反射修改了 String 的 value 数组，hash 缓存会不会出错？
A：会。但这属于破坏封装的非法操作，不属于正常语义范畴。String 的不可变性是靠“语言契约 + 设计约束”保障的（final 字段、无修改方法、构造后不暴露可变引用），不是靠底层内存防护。反射绕过访问控制，就像手动改 HashMap 的 table 数组一样，会导致所有依赖其不变性的逻辑崩溃——这恰恰反向印证了不可变性对缓存等优化的必要性。
Q：StringBuilder 修改字符串时，为什么没缓存 hash？
A：因为它可变，每次 toString() 都新建一个不可变 String 对象，新对象的 hash 初始为 0，首次调用才计算并缓存——缓存只属于那个具体实例，和 StringBuilder 无关。
一句话总结关键逻辑
不可变性 → 内容恒定 → 哈希值恒定 → 可安全缓存一次、复用多次 → 提升高频调用场景（如 Map 键、switch 字符串）性能。没有不可变性，缓存哈希值就是危险且无意义的优化。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
