Scanner类关闭资源的正确方式：实践建议-程序员充电站

Scanner类关闭资源的正确方式：你真的会用吗？

在Java的世界里，Scanner可能是每个初学者最早接触的输入工具。写算法题、做课设、开发命令行小工具时，它几乎是“标配”——三行代码搞定一行输入，简单直接。

但你有没有想过这样一个问题：为什么有时候程序跑着跑着就卡住了？或者文件明明该读完却提示“无法访问”？

答案很可能藏在你忽略的一行代码里：scanner.close()。

一个看似无关紧要的操作，为何如此重要？

我们先来看一段再普通不过的代码：

Scanner scanner = new Scanner(System.in); int num = scanner.nextInt(); // ... 处理逻辑 // 忘了 close()

看起来没问题吧？编译通过，运行正常，输出也对。那是不是就可以不管了？

错。

虽然Scanner本身不占多少内存，但它背后封装的是输入流（InputStream），而这个流可能关联着操作系统级别的资源——比如文件句柄、网络连接缓冲区、标准输入通道等。

这些资源是有限的！尤其是在服务器端或批量处理场景中，如果每处理一次输入都创建一个新的Scanner却不关闭，很快就会出现：

文件句柄耗尽（Too many open files）
程序卡死或崩溃
资源泄漏导致性能下降

更隐蔽的是，这种问题往往不会立刻暴露，而是随着运行时间推移逐渐恶化，排查起来非常困难。

所以，别让一个小疏忽，变成线上事故的导火索。

Scanner到底持有什么资源？它是怎么工作的？

java.util.Scanner并不是一个“轻量级”的字符串解析器那么简单。它的本质是一个文本扫描器，底层依赖于Readable接口来读取字符数据。

当你这样创建一个Scanner：

new Scanner(new File("data.txt"))

实际上发生了什么？

JVM 打开文件data.txt
创建对应的FileInputStream
包装成InputStreamReader
最终被Scanner持有并用于逐个读取字符

这意味着：你打开了一个文件描述符。这个描述符属于系统资源，必须由程序员显式释放。

📌 小知识：现代操作系统对单个进程能打开的文件数是有上限的（Linux通常为1024）。一旦超过，哪怕只是多一个未关闭的Scanner，也可能导致整个服务拒绝响应。

而且，Scanner实现了AutoCloseable接口，这本身就是JDK在提醒你：“我需要被妥善关闭”。

到底该怎么关？三种姿势，只有一种推荐

❌ 姿势一：完全不关 —— 新手常见坑

public void bad() { Scanner s = new Scanner(System.in); s.nextInt(); // 无close，无try-finally，啥都没有 }

风险等级：🔴 高危！

尤其在循环或Web请求中重复调用，等于不断制造“资源黑洞”。虽然GC最终会回收对象，但流的关闭并不依赖垃圾回收机制。你不主动关，它就一直开着。

⚠️ 姿势二：手动关闭 + finally —— 老派但可靠

适用于 Java 7 之前的版本，或者你还得兼容旧环境的情况。

Scanner scanner = null; try { scanner = new Scanner(new File("config.txt")); while (scanner.hasNextLine()) { System.out.println(scanner.nextLine()); } } catch (FileNotFoundException e) { System.err.println("找不到文件：" + e.getMessage()); } finally { if (scanner != null) { scanner.close(); // 确保无论如何都会关闭 } }

优点是逻辑清晰，兼容性强；缺点也很明显：啰嗦、容易漏判空、出错概率高。

而且，一旦你在finally块里忘记判空，还可能抛出NullPointerException，那就真是“救火变纵火”了。

✅ 姿势三：try-with-resources —— 当前最佳实践

从 Java 7 开始，引入了自动资源管理语法（ARM, Automatic Resource Management）：

try (Scanner scanner = new Scanner(new File("input.txt"))) { while (scanner.hasNextLine()) { processLine(scanner.nextLine()); } } catch (FileNotFoundException e) { System.err.println("文件异常：" + e.getMessage()); } // 自动调用 close()，无需任何额外操作

这才是你应该写的代码。

自动关闭：无论是否抛异常，JVM都会确保close()被调用。
简洁安全：不用写冗长的finally判断。
支持嵌套：多个资源可以一起声明：

try ( FileInputStream fis = new FileInputStream("in.txt"); Scanner scanner = new Scanner(fis) ) { // 同时管理多个资源 }

💡 提示：所有实现了AutoCloseable或Closeable的类型，都应该优先使用 try-with-resources。

使用Scanner时最容易踩的雷：nextInt() 和 nextLine() 的恩怨情仇

除了资源关闭，另一个高频陷阱出现在方法混用上。

看这段代码：

Scanner scanner = new Scanner(System.in); System.out.print("请输入年龄："); int age = scanner.nextInt(); System.out.print("请输入姓名："); String name = scanner.nextLine(); // 这里为什么会跳过？

你会发现，“请输入姓名”刚打印出来，程序就结束了？或者name是个空字符串？

原因在于：
nextInt()只读取数值部分，不会消费换行符\n。当用户输入25\n，nextInt()拿走25，剩下的\n还留在缓冲区里。紧接着nextLine()看到第一个字符就是\n，认为“这是一行”，于是立即返回空串。

✅ 正确做法是在nextInt()后加一次“吸渣”操作：

int age = scanner.nextInt(); scanner.nextLine(); // 清除残留的换行符 String name = scanner.nextLine(); // 此时才能正常输入

这个技巧不仅适用于nextInt()，还包括nextDouble()、nextBoolean()等所有非行读取方法。

记住一句话：凡是不以行为单位读取的方法，都会留下“尾巴”，记得清理！

不同输入源的关闭策略，你分清了吗？

不是所有Scanner都能随便关，也不是所有都要立刻关。关键要看它包装的是哪种输入源。

输入源	是否建议关闭	原因说明
`new File("xxx")`	✅ 必须关闭	涉及文件句柄，不关会导致资源泄漏
`new ByteArrayInputStream(...)`	✅ 建议关闭	虽然内存流开销小，但仍应养成习惯
`System.in`	⚠️ 视情况而定	关闭后整个程序都无法再读标准输入
字符串常量（如`"abc"`）	✅ 可关闭	内部转为`StringReader`，虽影响小但也应规范

重点说一下System.in。

如果你这样写：

Scanner globalScanner = new Scanner(System.in); // 全局使用 // ... globalScanner.close(); // 危险！

这一关，不只是关了自己的Scanner，还会把System.in给关了！后续任何想从控制台读数据的代码都会失败。

怎么办？

有两种思路：

方案一：统一管理，程序退出前关闭

public class InputManager { private static final Scanner STDIN = new Scanner(System.in); public static String readLine() { return STDIN.nextLine(); } public static void shutdown() { STDIN.close(); // 在main结束前调用 } }

然后在主流程最后调用InputManager.shutdown()。

方案二：干脆就不关

对于交互式命令行程序，生命周期与用户会话一致，可以在JVM退出时由系统自动回收。此时选择不关，反而更安全。

🔔 原则：谁打开，谁负责关闭。如果是共享资源（如System.in），不要轻易替别人做决定。

实战建议：写出健壮又优雅的输入代码

1. 局部变量 + try-with-resources 是王道

public List<String> readLinesFromFile(String filename) { List<String> lines = new ArrayList<>(); try (Scanner scanner = new Scanner(new File(filename))) { while (scanner.hasNextLine()) { lines.add(scanner.nextLine()); } } catch (FileNotFoundException e) { throw new RuntimeException("文件不存在: " + filename, e); } return lines; }

短小精悍，资源安全，异常清晰。

2. 工具类设计要谨慎

如果你想封装一个通用输入工具，建议避免持有Scanner实例，改为每次临时创建：

public class ConsoleInput { public static int promptInt(String msg) { try (Scanner s = new Scanner(System.in)) { System.out.print(msg); return s.nextInt(); } } }

虽然每次新建有点开销，但在交互频率不高的场景下完全可以接受，且避免了关闭冲突。

3. 单元测试中模拟输入很简单

@Test void shouldParseUserInputCorrectly() { String input = "Alice\n30\nalice@domain.com"; try (Scanner scanner = new Scanner(input)) { assertEquals("Alice", scanner.nextLine()); assertEquals(30, scanner.nextInt()); scanner.nextLine(); // 吸收回车 assertEquals("alice@domain.com", scanner.nextLine()); } // 自动关闭，干净利落 }

用字符串构造Scanner，轻量、可控、易清理。