String不可变是通过final类、private final字符数组（JDK8为char[]，JDK9+为byte[]）及所有操作返回新对象三层机制实现；其根本原因在于支撑常量池安全复用、保障线程安全、缓存hashCode提升哈希容器性能，并确保敏感场景（如路径、密码）不被篡改。
要完美通关“String为什么不可变”这道面试题，关键不是背结论，而是能分层讲清它怎么做到不可变、为什么必须不可变、以及不可变带来什么实际影响。面试官想听的，是逻辑闭环，不是标准答案。
从源码看“不可变”是怎么实现的
不能只说“因为用了final”。真正起作用的是三层设计：
- String类被final修饰：防止子类绕过封装，重写方法破坏不可变性
- 内部字符数组（JDK8是char[]，JDK9+是byte[]）是private final：引用不可重赋值，外部无法访问数组本身
- 不提供任何修改数组内容的public方法：replace、concat、substring等全返回新对象；连setCharAt这种基础方法都不存在
注意：反射可以强行修改value数组（属于破坏封装的黑盒操作），但Java规范和日常开发中默认不考虑这种情况。
常量池依赖不可变性才能安全复用
字符串常量池不是“锦上添花”，而是JVM内存优化的核心机制。它的存在前提是——同一个字面量对应的对象，内容永远不变。
立即学习“Java免费学习笔记（深入）”；
- String a = "hello"; String b = "hello"; → a == b 为true，共享同一对象
- 如果String可变，a.toUpperCase() 就可能把池中"hello"变成"HELLO"，b的值也跟着变，逻辑彻底崩溃
- 所以不可变性是常量池机制成立的充要条件，不是附加好处
线程安全与哈希缓存是不可变的直接受益者
这两点常被候选人忽略，但恰恰最能体现设计深度：
- 天然线程安全：多个线程读同一个String，无需同步；没有“写-写冲突”或“读-写可见性”问题
- hash值可缓存：String内部有private int hash字段，首次调用hashCode()时计算并缓存，后续直接返回；若可变，每次都要重新算，HashMap/HashSet性能大打折扣
- 作为key的安全保障：put进HashMap的String key一旦被意外修改，会导致get失效（哈希值变了，找错桶），不可变彻底规避该风险
对比StringBuilder和StringBuffer能反向印证设计意图
面试官常追问“那需要可变怎么办？”——这不是让你背API，而是考你是否理解场景划分：
- StringBuilder：单线程拼接，无锁，性能高；适用于日志拼接、JSON组装等临时场景
- StringBuffer：所有方法加synchronized，线程安全但慢；已基本被并发工具替代，了解即可
- 而String专用于表示稳定语义：配置项、路径、URL、用户名、SQL模板……这些不该也不需被中途改写
