Java数组的hashCode()返回对象地址哈希，不反映内容；内容哈希需用Arrays.hashCode()或Arrays.deepHashCode()，以确保语义清晰、性能可控且符合hashCode契约。
Java中数组对象的hashCode()方法返回的值，本质上就是Object默认实现的结果——它不关心数组里存了什么，只把数组本身当作一个普通对象来处理。这和String、Integer等类主动重写hashCode()以反映内容逻辑完全不同。
数组没有重写 hashCode 方法
Java语言规范明确要求：所有数组类型（如int[]、String[]、Object[][]）都直接继承Object.hashCode()，既不能也不被允许重写该方法。JVM层面将数组视为“原始容器”，其身份由创建时的分配行为决定，而非元素内容。
- 这是JVM规范强制约定，不是设计疏忽或历史遗留
- 即便你声明
final int[] arr = {1,2,3};，arr.hashCode()也和arr是否被修改无关 - 数组类（如
[I、[Ljava.lang.String;）在字节码中是特殊类型，不参与用户类的继承链
内容哈希交给 Arrays 工具类统一管理
Java把“按内容算哈希”这件事完全剥离出来，交由java.util.Arrays提供静态方法：
-
Arrays.hashCode(int[])：对基本类型数组逐元素计算，公式为result = 31 * result + element[i]，初始result = 1 -
Arrays.deepHashCode(Object[])：递归展开嵌套数组，比如int[][]会被真正遍历到底层数值 - 若误用
Arrays.hashCode()处理含二维数组的Object[]，它不会自动调用deepHashCode，而是对子数组调用其默认hashCode()——这就回到了地址哈希
这样设计的核心原因
保持语义清晰和性能可控：
立即学习“Java免费学习笔记（深入）”；
-
身份 vs 内容分离：数组引用的“相等性”默认是
==，与其hashCode()保持一致；而内容相等需显式调用Arrays.equals()或deepEquals() -
避免隐式开销：每次调用
hashCode()就遍历整个数组，对大数组或频繁哈希场景（如作为HashMap key）代价过高 -
规避一致性风险：如果数组
hashCode()依赖内容，但数组又可变（如arr[0] = 99），那哈希值就得变——这直接违反hashCode()契约（同一对象多次调用必须返回相同值）
实际开发中的典型误区
很多人期望new int[]{1,2,3}.hashCode() == new int[]{1,2,3}.hashCode()成立，但它几乎总是不成立——因为两个数组是不同对象，地址哈希不同。正确做法是：
- 比较内容是否相等 → 用
Arrays.equals(a, b) - 需要内容哈希用于集合 → 用
Arrays.hashCode(a)，且确保该数组不再修改 - 多维数组做key → 必须用
Arrays.deepHashCode(a)，否则子数组哈希无效
