Arrays.binarySearch 不一定比遍历快，关键取决于数组是否严格升序、规模大小及查询频次；小数组（≤1000）遍历更快，大数组（≥10000）binarySearch 显著占优；查一次宜遍历，多次查询才值得预排序；替代结构如HashSet、TreeSet或Map索引更适高频查找场景。
Arrays.binarySearch 不一定比遍历快，关键看数组是否已排序、多大、查几次。盲目换方法反而拖慢性能。
前提决定能不能用 binarySearch
binarySearch 只认升序数组——不是“尽量有序”，而是必须严格升序。传入乱序或降序数组，返回值毫无意义：可能漏找、错位、甚至负数误判为“不存在”。
- 基本类型（int、double 等）：直接用
Arrays.sort(arr)排好再查 - 对象数组（String、自定义类）：若需按非自然顺序查找（如按字符串长度），必须用同一个
Comparator先排序，再用对应重载版binarySearch(arr, key, comparator) - 切忌边改数组边查：排序后手动修改某个元素，就破坏了有序性，后续所有 binarySearch 结果都不可信
数组大小影响实际快慢
小数组遍历更省事，大数组 binarySearch 才显优势。1000 是实测分水岭：
- ≤ 1000 元素：遍历平均耗时 2–3 万纳秒；binarySearch 因有递归/边界计算开销，反要约 5 万纳秒
- ≥ 10000 元素：binarySearch 稳定在 3–4 万纳秒；遍历跃升至 90–440 万纳秒，慢上百倍
- 100 万元素：binarySearch 仍约 3.5 万纳秒；遍历超 400 万纳秒
查一次 vs 查多次，策略完全不同
查一次，往往遍历更简单；查多次，才值得投入预处理成本：
立即学习“Java免费学习笔记（深入）”；
- 只查一两次：别折腾排序，直接 for 循环，代码短、逻辑清、无风险
- 同一数组反复查找（比如配置项读取、词典查询）：先
Arrays.sort()一次，后续每次binarySearch都是 O(log n) - 数据持续插入又需保持可查：考虑用
TreeSet或手动维护有序 ArrayList，避免重复排序
比数组更适合查找的替代结构
如果查找频次高、数组内容稳定，数组本身可能不是最优载体：
- 只关心“存不存在”：用
HashSet.contains()，平均 O(1)，无需排序，创建一次、查无数次 - 既要查又要保持顺序：用
TreeSet，插入和查找都是 O(log n)，且天然有序 - 需返回下标或频繁查多个值：一次性转成
Map<T, Integer>建索引，后续查就是常数时间
