怎样优化Java Scanner读取大规模网格数据的性能

当使用 Scanner 读取超大二维字符网格（如 10000×10000）时，原始逐字符赋值方式因 I/O 阻塞和冗余操作导致严重性能瓶颈；改用 nextLine().toCharArray() 直接转换并避免嵌套循环，可将耗时从超时降至毫秒级。

当使用 scanner 读取超大二维字符网格（如 10000×10000）时，原始逐字符赋值方式因 i/o 阻塞和冗余操作导致严重性能瓶颈；改用 `nextline().tochararray()` 直接转换并避免嵌套循环，可将耗时从超时降至毫秒级。

在处理大规模网格输入（例如岛屿计数类算法题）时，I/O 性能往往成为程序瓶颈——尤其当网格尺寸达到 10⁴ × 10⁴ 级别时。问题根源并非 Scanner 本身“慢”，而是低效的读取模式：原始代码中嵌套双层循环（外层遍历行、内层遍历列），对每行调用 String.charAt(j) 进行 10⁴ 次重复索引访问，并伴随大量边界检查与方法调用开销；同时 Scanner.nextLine() 在高吞吐场景下仍存在内部缓冲同步开销。

✅ 正确优化思路是：减少方法调用层级、避免手动字符拆解、利用字符串原生能力。关键改进点包括：

• 跳过逐字符复制：不再用 charAt(j) 循环赋值，而是直接调用 String.toCharArray()，该方法由 JVM 底层高度优化，时间复杂度为 O(n)，且避免了 Java 层面的循环解释开销；
• 动态分配行数组：声明 char[][] seaCard = new char[rows][];（而非 new char[rows][cols]），允许每行按实际长度初始化，既节省内存又提升缓存局部性；
• 消除冗余 nextInt() 后的 nextLine() 冲突：nextInt() 不消费换行符，紧随其后的 nextLine() 会立即返回空行——需显式调用一次 nextLine() 清除缓冲区（已在示例中体现）；
• 优先使用文件输入替代标准输入：控制台输入受终端缓冲和系统调用限制，而文件读取可通过 JVM 文件系统缓存加速；若必须用 System.in，建议搭配 BufferedReader（见进阶提示）。

以下是优化后的生产就绪代码：

import java.io.File;import java.io.IOException;import java.util.Scanner;public static void main(String[] args) {    try (Scanner input = new Scanner(new File("input.txt"))) {        int rows = input.nextInt();        input.nextLine(); // consume newline after integer        char[][] seaCard = new char[rows][];        for (int r = 0; r < rows; r++) {            String line = input.nextLine();            seaCard[r] = line.toCharArray(); // ✅ 单次高效转换        }        System.out.println("Grid loaded successfully: " + rows + "×" + seaCard[0].length);    } catch (IOException e) {        System.err.println("Failed to read input file: " + e.getMessage());        System.exit(1);    }}

⚠️ 注意事项：

立即学习“Java免费学习笔记（深入）”；

• 若强制要求从 System.in 读取（如在线评测系统），请替换为 new Scanner(System.in)，但务必确认输入流已预热且无交互延迟；
• 对于极端规模（>10⁵ 行），建议进一步升级为 BufferedReader + StreamTokenizer 或 Files.lines() 流式处理，避免全量加载内存；
• toCharArray() 返回新数组，不共享原字符串内部 char[]（Java 9+ 使用 byte[] 存储字符串，但 toCharArray() 始终保证兼容性）；
• 切勿在循环内重复创建 Scanner 实例，资源泄漏会导致 IOException。

总结：性能问题 rarely 出自工具本身，而源于使用模式。将 O(rows × cols) 的手动字符拷贝降级为 O(rows) 的行级批量转换，配合合理的资源管理和输入源选择，即可轻松满足 8 秒时限——真正让算法逻辑而非 I/O 成为性能焦点。