JavaArrays工具类实战：排序查找填充转换

Java Arrays工具类看似简单，实则暗藏诸多易被忽视的“坑”：自定义对象排序需显式实现Comparable或传入Comparator，否则抛ClassCastException；基本类型与引用类型底层算法不同（双轴快排 vs TimSort），混用易致性能误判；binarySearch未找到时返回负数是刻意设计，需按-(insertionPoint+1)换算插入位置，且严格依赖数组已排序；fill填充引用类型会引发对象共享问题，导致“改一个全变”；toString仅展一层，多维数组必须用deepToString，否则输出无意义的哈希地址。这些细节不报错却悄然引发逻辑错误，调试成本远超编码本身——掌握它们，才能真正用好Arrays这个高频却高危的利器。

Arrays.sort() 为什么对自定义对象排序会报 ClassCastException

因为没实现 Comparable 接口，或没传 Comparator。Java 默认只认 Integer、String 这类自带比较逻辑的类型。

• 如果对象字段简单（比如只有 id），直接让类 implements Comparable，重写 compareTo()
• 如果要按不同字段多次排序（比如一会按姓名，一会按年龄），别改类，用 Arrays.sort(arr, Comparator.comparing(Person::getName))
• 注意：Arrays.sort() 对基本类型数组（int[]）和引用类型数组（Person[]）用的是两套底层算法，前者是双轴快排，后者是 TimSort —— 所以混用泛型和原始类型时行为不一致，容易误判性能

Arrays.binarySearch() 查不到元素却返回负数，怎么算实际插入位置

它返回的负数不是错误，而是设计好的：如果没找到，返回的是 -(insertionPoint + 1)。比如返回 -3，说明该元素应插在索引 2 的位置。

• 必须保证数组已升序排序，否则结果完全不可信 —— 它不会帮你检查，也不会抛异常
• 对 byte[]、double[] 等基本类型数组，有对应重载方法；但千万不能把 int[] 传给接收 Object[] 的版本，那会触发自动装箱成 Integer[]，结果查不到
• 如果数组里有重复元素，它只保证返回其中一个的索引，不保证是第一个还是最后一个

Arrays.fill() 填 null 到对象数组后，为什么修改一个元素所有都变了

因为你填的是同一个引用。比如 Arrays.fill(arr, new Person("A"))，表面看填了 10 个对象，其实只是把同一个 Person 实例的引用复制了 10 次。

• 正确做法是用循环单独 new： for (int i = 0; i
• Arrays.fill() 对基本类型安全（int[] 填 0 没问题），但对引用类型只适合填 null 或不可变对象（如 String、Integer）
• 如果真要批量初始化可变对象，考虑用 Stream.generate(() -> new Person()).limit(n).toArray(Person[]::new)

Arrays.toString() 和 Arrays.deepToString() 差在哪，什么时候用错会输出 [Ljava.lang.Object;@1b6d3586

前者只展开一层，遇到嵌套数组（比如 String[][]）就直接调用子数组的 toString()，而默认实现就是打印类名加哈希值。

• 一维数组用 Arrays.toString()，二维及以上必须用 Arrays.deepToString()
• 自定义类数组如果想让 toString() 可读，得自己重写 toString() 方法；否则哪怕用 deepToString()，里层还是那个 @xxx
• 日志里打数组内容时，别图省事直接 System.out.println(arr) —— 那等价于调 arr.toString()，永远是地址值

实际用的时候，最容易漏掉的是排序前是否真的有序、填引用对象时有没有意识到共享同一实例、还有多维数组 toString 的层级陷阱——这些地方不报错，但结果不对，debug 花的时间比写代码还长。

以上就是《JavaArrays工具类实战：排序查找填充转换》的详细内容，更多关于的资料请关注golang学习网公众号！