java中string.hashcode()的核心目标是为字符串生成足够分散的int哈希值以支撑hashmap高效查找，其算法采用以31为乘子的多项式散列，公式为s[0]×31^(n-1)+…+s[n-1]，等价于迭代计算h=31×h+c并缓存结果。
Java 中 String.hashCode() 的核心目标是：在有限的 int 范围（2³² 个值）内，为任意字符串生成一个“足够分散”的整数，支撑 HashMap 等集合高效查找。它不是密码学哈希，不追求抗碰撞或不可逆，而是兼顾速度、分布质量与实现简洁性。
hashCode 计算公式：多项式哈希 + 31 作为乘子
源码逻辑等价于以下递推式：
- 初始 h = 0
- 对每个字符 c（按从左到右顺序），执行：h = 31 * h + c，其中 c 是 char 的 Unicode 码点（ASCII 子集下即 ASCII 值）
- 最终结果就是 h，且会被缓存到 String 对象的
hash字段中，避免重复计算
展开后即为标准多项式形式：s[0]×31ⁿ⁻¹ + s[1]×31ⁿ⁻² + … + s[n−1]×31⁰，n 是字符串长度。
例如 "AB"（A=65, B=66）：h = 31×0 + 65 = 65；再 h = 31×65 + 66 = 2081。
为什么选 31？三个关键原因
31 不是随意挑选的 magic number，而是工程权衡的结果：
- 它是奇质数：偶数乘子（如 32）在溢出时等价于左移+补零，高位信息易丢失；质数能更好打散低位模式，降低规律性冲突
- 位运算友好：31 × i 可被 JVM 优化为 (i ，比普通乘法快，现代 HotSpot 会自动做此替换
- 实测碰撞率低：在数万真实英文单词、中文词组等测试集上，31 比邻近的 29、37、33 等乘子表现出更小的哈希碰撞概率，平衡了大小与质性
碰撞不可避免，但设计上已尽力控制
由于输出空间固定（int 共 4,294,967,296 种可能），而输入空间无限（任意长度字符串），碰撞必然发生，例如：
- "AaAaAa".hashCode() == "BBAaBB".hashCode() == 1952711232
- "通话".hashCode() == "重地".hashCode() == 1179322
实际碰撞概率取决于数据分布。在典型业务字符串（如 URL、ID、配置名）中，Java 的 31 多项式哈希表现稳健；但在人为构造的对抗性输入下，仍可能聚集。HashMap 等容器正是靠 equals() 二次校验 来解决碰撞，而非依赖 hashCode 绝对唯一。
使用注意事项：别把它当安全或持久标识
这个哈希值仅适用于 JVM 内存中临时散列场景：
- ❌ 不可用于数据库主键或索引——JDK 版本升级可能改变算法（虽然目前规范已稳定，但不保证长期不变）
- ❌ 不可用于网络校验或防篡改——它不加盐、无单向性，短字符串可暴力穷举还原
- ❌ 不可替代 equals() 判断相等——哈希相同只是“可能相等”，必须用 equals() 最终确认
- ✅ 正确用途：作为 HashMap / HashSet 的桶定位依据，加速 O(1) 平均查找
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
