字符串能稳定作为哈希表键，核心在于其不可变性：final字符数组、哈希值缓存、常量池复用、线程安全且杜绝竞态，确保哈希一致性与检索可靠性。
字符串作为哈希表键（如 HashMap、Dictionary）能稳定工作，核心就在于它的不可变性——内容一旦创建，就无法被修改。这不是语法限制的“枷锁”，而是保障检索不失败、并发不混乱、安全不越界的底层设计。
确保哈希值全程一致
哈希表靠键的 hashCode() 定位存储位置（桶）。如果键对象中途被改了内容，哈希值就变了，原数据会被“锁”在旧桶里，再也找不回来。
字符串天然满足这点：内部字符数组被 final 修饰，所有看似修改的方法（如 replace、substring）都返回新对象，原对象毫发无损。因此：
- 首次调用 hashCode() 后，结果被缓存，后续直接复用，不重算；
- 哪怕同一字符串被反复用作不同 Map 的键，哈希值始终相同；
- 对比可变类型（如 StringBuilder），后者若用作键，一次 append() 就会让整个映射失效。
避免多线程下的竞态风险
多个线程同时读取同一个字符串键，完全无需加锁。因为没人能改它——既没有 public setter，也没有内部状态变更逻辑。
这和用可变对象（比如自定义的 Person 类）当键完全不同：一旦某个线程调用了 person.setName("new")，所有依赖该键的哈希操作（get、containsKey）都可能出错或返回 null。
所以：
- 共享字符串键时，不用考虑同步、volatile 或线程局部变量；
- 日志标签、配置项名、API 路由路径等高频读场景，用字符串键最省心；
- 即使把字符串传进异步任务或回调函数，也不用担心被意外篡改。
配合字符串常量池提升复用与一致性
字面量字符串（如 "user_id"）会进入 JVM 字符串常量池。相同内容只存一份，多个变量指向同一地址。
这对哈希键特别友好：
- Map
cache = new HashMap();
cache.put("timeout", 3000);
Object val = cache.get("timeout"); // 引用相等 + 内容相等，双重保障命中 - 即使不同模块各自声明 "config.host"，只要字面量一致，它们在池中就是同一个对象，哈希计算零误差；
- 调用 String.intern() 可强制归入池中，适合动态生成但需长期复用的键（如拼接后的 SQL 表名）。
实际编码中的关键习惯
不可变性是优势，但得用对方式才能真正落地：
- 优先使用字面量或 String.valueOf() 构造键，避免无谓的 new String(...)；
- 拼接多个字段做复合键时，用 String.format("u%d_t%d", userId, timestamp) 或 Objects.toString()，别用 StringBuilder.append 后 toString()——虽结果一样，但语义更清晰；
- 若必须用非字符串类型作键（如自定义类），务必保证其 equals() 和 hashCode() 基于 final 字段，且对象本身不提供修改方法；
- 警惕“伪不可变”：如用 char[] 手动构造字符串，或反射绕过 final 限制——这些会破坏哈希稳定性，生产环境禁用。
