arrays.fill 无稀疏数组性能损耗，因 java 数组天然稠密且 fill 总执行 o(n) 全量写入；所谓“稀疏”仅是逻辑设计模式，如 map 或 sparsearray；误将高默认值数组当稀疏结构优化才导致低效。
Arrays.fill 本身不处理稀疏数组，也不感知“稀疏性”——它只对已分配的数组对象执行内存填充操作，而 Java 的普通一维/二维数组天然不具备 JavaScript 那种“空槽（hole）”语义。 所以严格来说，Arrays.fill 在 Java 中不存在“因稀疏数组导致的性能损耗”。真正需要区分的是：你面对的是传统稠密数组、手动模拟的稀疏结构（如自定义 SparseArray 类），还是误将“含大量默认值的数组”等同于“稀疏数组”。
Java 里没有运行时稀疏数组概念
Java 数组（int[]、Object[] 等）在创建时即完成内存分配与默认初始化（如 int 元素全为 0，Object 元素全为 null）。它始终是**物理稠密**的——每个索引位置都有确定的内存单元。所谓“稀疏”，在 Java 生态中仅作为**逻辑数据结构设计模式**存在（例如用 Map<integer t></integer> 或自定义 SparseArray 存储非默认值），而非 JVM 原生支持的数组类型。
这意味着：
-
Arrays.fill(arr, val)总是对arr.length个连续内存位置写入，时间复杂度稳定为 O(n) - 它不会跳过任何索引，也无需检测“是否为空”——因为每个位置都可安全访问
- 如果你用
new int[1000000]创建大数组，JVM 已在分配时将全部元素设为 0；此时Arrays.fill(arr, 5)是一次完整遍历，但这是预期行为，不是“损耗”
真正有性能影响的场景：误用或混淆
当开发者把“含大量重复默认值的数组”当作稀疏数组来优化时，容易引发两类低效操作：
-
用
Arrays.fill去“重置”本该用稀疏结构替代的巨型数组：比如一个 1000 万元素的int[]，其中仅 100 个位置非零。反复调用fill(0)清零，不如直接复用一个空HashMap或专用稀疏容器 -
在二维稀疏模拟中滥用 fill：例如
int[][] matrix = new int[1000][1000]后用Arrays.fill(matrix[i], 0)逐行清零。虽然单次 fill 快，但整体仍是百万级赋值；若业务只需存几百个非零点，应改用Map<pair integer></pair>或压缩存储格式
对比 JavaScript 的关键差异
JavaScript 的“稀疏数组”（如 Array(1000)）本质是哈希表模拟，索引不连续 → map() 会跳过空位；而 Java 数组是连续内存块 → fill() 必然覆盖全部长度。这种根本差异决定了：
- JS 中需
fill()“补洞”才能让高阶函数正常工作；Java 中完全不需要 - JS 引擎对稀疏数组有隐藏类退化、遍历开销等惩罚；Java JIT 对
Arrays.fill有高度优化（如向量化写入），无此类问题 - 若你在 Java 项目中看到类似“稀疏数组性能差”的报告，大概率是用了低效的自定义实现，而非
Arrays.fill本身的问题
实用建议：什么情况下该避开 fill？
不是 Arrays.fill 有问题，而是它可能用错了地方：
- 需要频繁部分更新、极少全量重置 → 改用
java.util.BitSet（布尔场景）或LongSparseArray（Android）等专用结构 - 数组超大（接近
Integer.MAX_VALUE）且稀疏度 > 99.9% → 考虑外部存储（数据库/Redis）或流式计算，避免堆内存压力 - 多线程共享数组并需原子初始化 →
Arrays.fill不提供可见性保证，应配合volatile引用或使用java.util.concurrent.atomic.AtomicIntegerArray
