Arrays.setAll 是用于按索引函数式初始化空数组的工具方法，适用于 new int[1000] 后用 i -> i * i 填充；不适用于修改已有数组，且 lambda 必须显式返回值。
Arrays.setAll 是什么，适合干啥
Arrays.setAll 是一个工具方法，用来按索引位置批量生成数组元素，本质是“用函数式方式填充数组”。它不适用于已有数据的修改，也不是替代循环的万能写法。
- 适用场景：初始化空数组（比如
new int[1000]），每个元素值由下标计算得出（如i -> i * i） - 常见误用：拿它去“更新”已存在的数组内容，结果发现没生效——因为如果 lambda 里没对数组做显式赋值（它本身不负责写入），就白跑了
- 注意参数顺序：
Arrays.setAll(array, generator)，第二个参数是IntUnaryOperator，接收下标i，返回要塞进array[i]的值 - 示例：
int[] arr = new int[5]; Arrays.setAll(arr, i -> i * 2 + 1); // [1, 3, 5, 7, 9]
parallelSort 比 sort 快在哪，什么时候别乱用
Arrays.parallelSort 在底层用了 ForkJoinPool，对大数组（通常 > 8192 元素）才真正开启并行分支。小数组反而因线程调度开销更慢。
- 默认阈值：JDK 8+ 中，
parallelSort对基本类型数组内部判断是否分段，int[]等会走ForkJoinPool.commonPool() - 容易踩的坑：
- 在受限线程环境（如 Web 容器、Android 主线程）调用，可能触发
ForkJoinPool.commonPool().awaitQuiescence阻塞或资源争抢 - 数组含
null或自定义对象但没实现Comparable，报NullPointerException或ClassCastException，错误信息里带Arrays$ParallelSortHelpers$FJObjectSorter就是它
- 在受限线程环境（如 Web 容器、Android 主线程）调用，可能触发
- 性能提示：若数组已基本有序，
Arrays.sort（Timsort）实际更快；parallelSort更适合随机分布的大数组
setAll + parallelSort 组合用，真能优化大数据量处理？
两者没有内在耦合，组合使用只是“先生成再排序”，不是流水线优化。但容易忽略中间状态和副作用。
- 常见错误现象：用
setAll生成对象数组（如String[]），再parallelSort，结果抛NullPointerException——因为setAll的 lambda 返回了null，而parallelSort对引用类型默认用自然序比较 - 参数差异注意点：
-
setAll的 generator 函数必须纯（无外部状态依赖），否则多线程下parallelSort可能读到未完成填充的元素 - 若用
parallelSort(array, comparator)，comparator 本身必须线程安全（不能含共享可变状态）
-
- 实操建议：
- 大于 10 万元素才考虑
parallelSort -
setAll后加一次Arrays.stream(array).noneMatch(Objects::isNull)校验（仅调试期，别留生产） - 不要为了“看起来高级”硬凑这两个 API，顺序执行
sort在多数业务场景下更稳
- 大于 10 万元素才考虑
parallelSort 的并发行为藏在哪，怎么观察它是否真并行了
它是否并行，取决于数组长度、JVM 当前可用并行度、commonPool 负载，而不是调用一次就必然起多个线程。
立即学习“Java免费学习笔记（深入）”；
- 查看是否触发并行：在 JDK 9+ 可加 JVM 参数
-Djava.util.concurrent.ForkJoinPool.common.parallelism=2限制并行度，再配合jstack观察线程栈里是否有FJObjectSorter或ArraysParallelSortHelpers相关帧 - 兼容性影响：JDK 7 不支持
parallelSort；Android API 24+ 才有完整实现；GraalVM Native Image 默认不包含ForkJoinPool的反射元数据，需额外配置 - 容易被忽略的点：如果你的应用重写了
ForkJoinPool.commonPool()（比如用自定义线程池替换），parallelSort会直接用那个池子——但它的队列策略、拒绝策略可能和排序任务不匹配，导致卡死或 OOM
事情说清了就结束
