Java字符串的hashCode()按固定公式s[0]×31^(n-1)+s[1]×31^(n-2)+…+s[n-1]计算，等价于霍纳法迭代h=31×h+s[i]，避免溢出；其值由字符Unicode码点和位置决定，非随机亦非加密。
Java字符串的hashCode()到底怎么算出来的
它不是随机数，也不是加密哈希，而是按固定公式逐字符计算的整数。理解这个公式，才能预测值、调试散列冲突、避免误用。
核心公式是：s[0] * 31^(n-1) + s[1] * 31^(n-2) + ... + s[n-1]，其中s[i]是字符的char数值（即Unicode码点），n是字符串长度。
实际计算用的是等价的霍纳法（Horner’s method），避免大指数和溢出：
31 * h == (h ）；整数溢出是故意允许的——Java中int溢出自动回绕，不影响一致性。
-
"a"→31 * 0 + 'a'→97 -
"ab"→31 * 97 + 'b'→31 * 97 + 98 = 3105 -
"A"→65（大写A的Unicode是65，和小写a不同）
大小写敏感、全角/半角字符（如'Ａ' U+FF21 vs 'A' U+0041）必然产生不同哈希值——这是预期行为，不是bug。
什么时候不该依赖String.hashCode()的结果
它的设计目标是高效、一致、低冲突（对典型英文文本），但不保证跨JDK版本或未来不变。虽然至今未变，但JVM规范只保证“同一程序内相同字符串值返回相同哈希”，不承诺长期稳定。
以下场景必须避开：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 持久化存储哈希值（比如存数据库当索引键），升级JDK后可能失效
- 网络传输中用作校验码——它不抗碰撞，也不防篡改
- 替代
Objects.equals()做相等判断：哈希相等≠字符串相等（可能冲突），必须配合equals() - 密码或敏感数据的“摘要”——它没有单向性、无盐、易逆（短字符串可暴力穷举）
真要稳定哈希，用java.security.MessageDigest（如SHA-256）；要快速比较，仍用equals()——hashCode()只是HashMap等集合提速的中间工具。
调试哈希冲突时最容易忽略的一点
两个不同字符串算出相同hashCode()不罕见，尤其短字符串。例如："Aa"和"BB"在Java中都返回2112（可自行验证）。这不是算法缺陷，而是32位整数空间有限的必然结果。
真正影响性能的是“哈希桶内链表/红黑树长度”。如果大量字符串哈希集中在少数几个值上（比如都以相同前缀开头、或全是数字字符串），HashMap查找会退化为O(n)。
排查时别只看单个hashCode()，要统计分布：
strings.stream()
.collect(Collectors.groupingBy(String::hashCode, Collectors.counting()))
.entrySet().stream()
.filter(e -> e.getValue() > 10)
.forEach(System.out::println);
如果发现某哈希值聚集了上百个字符串，问题大概率不在hashCode()本身，而在你的数据模式——比如日志ID全是时间戳前缀，导致高位字符高度重复。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
