1. Scanner 到底解决了什么问题1.1 在 Scanner 出现之前Java 控制台输入有多麻烦我刚开始写 Java 的时候第一个程序是 HelloWorld第二个程序就是控制台读用户输入。当时主流教法是BufferedReader搭配InputStreamReaderBufferedReader reader new BufferedReader(new InputStreamReader(System.in)); String line reader.readLine();这个写法能跑但痛点非常明显。第一只能按行读字符串想要整数还得自己Integer.parseInt()转一手用户手滑输入12.5或者abc立刻收获一个NumberFormatException第二调用链太长System.in是什么、InputStreamReader干嘛用的、BufferedReader又干嘛用的每一步都得理解才能不懵第三想按空格拆多个值得自己split()再遍历代码瞬间膨胀。更隐蔽的坑是readLine()在用户没按回车之前会一直阻塞很多初学者第一次写交互程序就卡在好像是死循环的错觉里。所以 Java 5 推出java.util.Scanner之后这个局面才彻底改观。Scanner直接接受System.in一行代码构造完成还自带nextInt()、nextDouble()、nextLine()这些方法把输入格式解析这个脏活累活全包了。Scanner的核心价值就在于把我们和底层字节流、字符解码之间的复杂度隔离开让我们专注于我想从输入里拿一个整数这种业务意图而不是纠结这一行字节怎么转成字符再转成数字。1.2 System.in 到底是什么很多人背过Scanner in new Scanner(System.in);这个固定写法但System.in到底是什么Scanner拿到它之后做了什么未必清楚。System.in是 JVM 提供的标准输入流类型是InputStream本质是一个字节流。它默认代表键盘输入但在命令行重定向之后它可以是一个文件、一个管道甚至另一个进程的输出。也就是说用Scanner包装System.in写好的逻辑执行java Main input.txt时可以直接读文件内容代码一行都不用改。Scanner拿到InputStream后内部做了好几层处理先把字节流包装成可读的字符流再在内部维护一个字符缓冲区每次调用nextXxx()时用默认的分隔符模式匹配字符命中后把匹配结果的前缀作为 token 返回。整个设计思路本质是正则 缓冲 迭代器的组合这也解释了为什么它这么灵活同时为什么有些坑这么隐蔽。2. 核心 API 用法拆解2.1 构造方法不止有 System.inScanner的构造方法能接收多种参数这是很多人忽略的点。new Scanner(InputStream)最常见比如System.in。new Scanner(File)直接读文件。new Scanner(Path)JDK 7 之后推荐配合字符集参数使用。new Scanner(String)把一个字符串当作输入源做文本解析特方便。new Scanner(Readable)接收任何实现了Readable接口的对象。其中new Scanner(String)我经常拿来做测试。比如写了一个解析方法不想每次跑到控制台敲一遍数据直接构造一个Scanner包字符串Scanner sc new Scanner(12 34 56 78); while (sc.hasNextInt()) { System.out.println(sc.nextInt()); }这种写法用来做单元测试、算法题本地调试都很快而且完全不依赖键盘输入避免了一跑测试就要切窗口去敲数据的尴尬。还有一点值得注意Scanner不是线程安全的多线程环境下共享同一个Scanner实例会导致状态错乱需要每个线程自己持有实例或者外部加锁。面试时偶尔有人问这一点知道就是加分项。2.2 nextXxx 系列值是怎么被读出来的next()、nextLine()、nextInt()是三大高频方法它们的行为差异非常关键。next()读取下一个以空白符分隔的 token返回值是String。nextInt()、nextDouble()等则是先取 token 再做类型转换。nextLine()特殊它不以空白符为分隔而是以换行符为边界读走的是一整行。底层执行顺序是这样的调用nextInt()时Scanner先跳过所有匹配分隔符模式的字符然后收集下一个 token尝试用相应类型解析。如果解析失败会抛出InputMismatchException但要注意那个 token 已经被消费掉了不会留在流里等你重新读。这个问题在实际开发中很常见Scanner sc new Scanner(System.in); int age sc.nextInt(); // 用户输入了 abcInputMismatchException抛出来之后abc已经被消费程序如果还想继续读后面的内容得自己处理异常逻辑否则流的位置已经往前走了。所以做健壮输入时我通常会先hasNextInt()判断再nextInt()读取。与nextLine()配合时还有个经典问题在nextInt()之后直接调用nextLine()得到的是一个空字符串因为上一次nextInt()只消费了数字本身行尾的换行符被留在了流里。后面第 4 章我会专门展开讲这个坑。2.3 useDelimiter自定义分隔符的正确玩法Scanner默认分隔符是\p{javaWhitespace}也就是所有 Java 空白符。但在处理 CSV、日志文件、自定义协议文本时默认分隔符经常不够用这时候就需要useDelimiter()。比如我解析一个用逗号分隔的文件一行是张三,25,北京可以设置分隔符为逗号加可选的空白Scanner sc new Scanner(new File(data.csv), UTF-8); sc.useDelimiter(,|\\r?\\n); while (sc.hasNext()) { System.out.println(sc.next()); }注意useDelimiter接受的是正则表达式不是普通字符串。这既是能力也是责任——写复杂正则时一定要先在测试环境验证因为像|、[、(这些正则元字符在实际数据里可能毫无征兆地出现一旦匹配错乱解析结果会非常诡异。一个我踩过多次的坑分隔符设置不当会导致hasNext()永远返回true造成死循环。比如你只想用逗号做分隔符但文件里实际存在换行那换行符会被当成 token 的一部分返回如果不能正确处理循环体里面对空串或异常格式处理不周程序就跑飞了。所以我会习惯性地把分隔符写成[,\\s]这种兼容英文逗号、中文逗号和空白的组合形式解析效率高很多。3. 实战键盘、文件、字符串三大场景3.1 键盘交互的标准写法先给一个我认为最稳妥的键盘输入模板Scanner in new Scanner(System.in); while (true) { System.out.print(请输入一个整数); if (in.hasNextInt()) { int num in.nextInt(); System.out.println(你输入的是 num); break; } else { in.nextLine(); // 清理掉错误输入防止死循环 } }这里有两个平时写代码容易忽略的动作。第一个是hasNextInt()前置判断避免InputMismatchException导致程序中断第二个是错误分支里的in.nextLine()把当前行的错误 token 清掉否则会死循环——错误输入永远是那个 token每次循环都在同样的位置拿到同样的错误值。很多新手写输入会用try { ... } catch (InputMismatchException e) { ... }的方式处理不是不行但catch里如果忘了重新消费掉错误 token程序依然会卡死。相比之下用hasNextXxx()前置判断的方式更清晰代码也更短。3.2 读取文件时必须处理编码用Scanner读文件是很多人会踩编码坑的场景。如果你直接new Scanner(new File(data.txt))底层会用平台默认编码在中文 Windows 上往往是 GBK而文件本身是 UTF-8读出来就是乱码。正确姿势是显式指定字符集Scanner sc new Scanner(Path.of(data.txt), StandardCharsets.UTF_8);JDK 10 之后Path.of()比Paths.get()写法更简洁默认就是 UTF-8 的Files.newBufferedReader行为一致。而且指定字符集后Scanner内部能正确处理多字节字符像中文、日文、表情符号都不需要额外担心。读文件还有一个场景要注意大文件。Scanner内部虽然有缓冲但它的定位是按 token 解析而不是高效逐行读。一个几百 MB 的日志文件如果只是想按行遍历建议用BufferedReader性能差距在数倍到十几倍但如果你需要按分隔符切 token、做类型转换、按正则过滤Scanner的代码量优势就体现出来了。根据场景选工具不要盲目迷信某一个。3.3 结合集合与流的进阶玩法Scanner说白了是一种IteratorString所以它能直接和集合、Stream API 配合写出很紧凑的代码。一个典型的例子从控制台读一行空格分隔的整数转成ListIntegerScanner sc new Scanner(System.in); ListInteger nums new ArrayList(); while (sc.hasNextInt()) { nums.add(sc.nextInt()); }更进阶的玩法是配合正则做文本清理。比如从一段日志里把时间戳全部提取出来Scanner sc new Scanner(logText); sc.useDelimiter([^0-9]{4}-[0-9]{2}-[0-9]{2}); while (sc.hasNext()) { System.out.println(sc.next()); }这段代码的实际效果是以非时间戳格式为分隔符把日志里所有符合年-月-日格式的片段单独分离出来。虽然写法上有些取巧但确实让我少写了不少正则提取逻辑。这种用分隔符反向提取目标的思路在处理特定格式的文本数据时非常实用。如果要在循环里把Scanner转成 Stream还会用到spliterator的概念Scanner实现了IteratorString所以StreamSupport.stream(Spliterators.spliteratorUnknownSize(sc, Spliterator.ORDERED), false)也能跑起来。不过说实话实际项目中我很少这么写因为Scanner的非线程安全和流式并行处理天然冲突强行并行只会踩坑。知道有这回事就行面试被问到可以答两句。4. 高频坑位与排查实录4.1 nextLine 吃回车问题这个坑简直是 Java 初学者的第一大拦路虎。代码长这样Scanner sc new Scanner(System.in); System.out.print(请输入年龄); int age sc.nextInt(); System.out.print(请输入姓名); String name sc.nextLine(); System.out.println(name); // 输出为空现象就是name读出来是空字符串。原因是nextInt()只消费了数字行尾的换行符还残留在缓冲区里紧接着的nextLine()直接把换行符读走于是得到空串。解决方案通常有几种在nextInt()之后手动调用一次nextLine()把残留换行消费掉。改用nextLine()读整行再自行Integer.parseInt()转换。用hasNextInt()配合nextInt()然后立刻在需要读字符串前调用nextLine()。我个人更推荐第二种思路把所有输入都按行读再用Integer.parseInt()转换。这样做代码虽然长几行但逻辑统一不会出现某个方法只吃一半的边界情况。我实际用得最多的组合是String line sc.nextLine(); int age Integer.parseInt(line.trim());这样明确知道每行输入就是一条记录格式错误也能精确捕获并提示用户重试。4.2 hasNext() 死循环与阻塞hasNext()和hasNextInt()在Scanner里是会阻塞的这一点很多文章没说透。当你用Scanner(System.in)时hasNext()会等待用户输入没有输入就阻塞线程看起来像卡死。这个问题在两类场景里特别突出。一类是算法竞赛、ACM 刷题时在线判题系统通过管道重定向输入文件读完时hasNext()会返回false行为正常但如果你在本地控制台手动跑同样的代码永远等不到false因为控制台不会自己发 EOF。另一类是自己在 IDE 里调试明明写好了while (sc.hasNext())结果程序一直等着让人以为死锁了。排查经验是先确认输入源。控制台手动输入时想结束输入得按组合键发送 EOFLinux 下是 CtrlDWindows 下是 CtrlZ 加回车否则hasNext()永远为真。如果希望程序在用户输入空行时自动结束可以写成while (sc.hasNextLine()) { String line sc.nextLine(); if (line.isEmpty()) { break; } // 处理 line }4.3 要不要关闭 Scanner资源回收的争议Scanner实现了Closeable但要不要关、什么时候关很多人分不清楚。关键区分在于Scanner 包装的是谁。如果包装的是文件、网络流这类外部资源必须关闭最稳的方式是 try-with-resourcestry (Scanner sc new Scanner(Path.of(data.txt), StandardCharsets.UTF_8)) { while (sc.hasNextLine()) { System.out.println(sc.nextLine()); } }如果包装的是System.in那就不能随意close()。因为Scanner.close()会把底层的Readable也关闭而System.in是 JVM 级别的标准输入流关掉之后整个进程都没法再用键盘输入了。尤其在写工具类、交互式命令行程序时一个close()下去后面的代码全都读不到输入这坑我年轻的时候踩过排查了半天才发现是资源被提前释放。稳妥的做法是System.in包出来的Scanner就让它自生自灭不显式关闭。JVM 退出时资源自然释放不用担心泄漏。4.4 正则开销与性能实测Scanner内部用正则匹配分隔符这是它慢的根本原因。我的实测数据一个 50 MB 的文本文件BufferedReader.readLine()逐行处理大概 2 秒内跑完Scanner用默认分隔符做同样的逐行解析通常要 8 秒以上如果分隔符是复杂正则差距还会拉大。但这不代表Scanner一无是处。它的优势场景是输入格式复杂、需要大量类型转换、需要按正则切分。在这些场景里Scanner的代码量可能是BufferedReader的十分之一调试成本也低很多。我的建议是项目里做配置文件解析、小型 DSL 解析、算法题本地调试大胆用Scanner日志清洗、ETL、大数据量导入老老实实用BufferedReader或者更高层的解析库。5. 面试考点与经验沉淀5.1 高频面试题与标准答案这部分我整理了面试中常被追问的Scanner相关问题附上我认为最稳的回答思路。Q1next()与nextLine()的区别next()以空白符为分隔符读取 token读完后光标停在当前 token 末尾不消费分隔符nextLine()以换行符为边界读取整行读完消费掉换行符。两者混合使用时最容易出问题。Q2nextInt()之后用nextLine()为什么会得到空串nextInt()只消费整数 token行尾换行符残留在缓冲区nextLine()读到这个残留换行符后返回空串。解决方式在前面第 4 章已经讲过了核心是要么主动消费掉残留换行要么干脆统一按行读取再解析。Q3Scanner是线程安全的吗不是。Scanner内部有缓冲区、当前位置索引等可变状态多线程共享会产生不可预料的读写错位。需要线程隔离或外部加锁。Q4hasNext()在控制台输入时会阻塞吗会。hasNext()等待输入源产生可用数据对于System.in用户不输入、不发送 EOFhasNext()就会一直阻塞。判断输入是否结束不能依赖hasNext()的false返回除非输入源是文件或管道。Q5Scanner相比BufferedReader的优势和劣势优势是内置类型转换、正则分隔、API 友好适合中小规模文本解析劣势是性能较低、基于正则的匹配有额外开销不适合大数据量逐行处理。5.2 我总结的几条使用规范根据多年的实际项目经验我总结了几条Scanner的使用规范团队代码评审时也经常按这个标准卡人。第一明确输入源后再决定是否关闭流。System.in不关闭文件流用 try-with-resources。第二混合使用nextInt()和nextLine()前必须考虑残留换行。第三处理用户错误输入时一定先把错误 token 消费掉否则循环会卡死。第四读文件务必显式指定字符集否则跨平台必栽跟头。第五写复杂正则分隔符时先用小数据量测试再上生产数据。另外我还会在代码里给Scanner指定一个固定的Locale。因为nextDouble()在不同默认语言环境下对小数点符号的处理不一样某些环境下3.14可能解析失败必须用3,14。稳妥的做法是Scanner sc new Scanner(System.in); sc.useLocale(Locale.ROOT);这个问题真的坑过我一回。一次在某个项目里解析用户上传的数值文件本地开发环境用的是英文Locale一切正常部署到服务器上有一部分用户的数据解析失败排查半天才发现服务器默认Locale是小语种小数点符号规则变了。从那以后我只要用Scanner做数值解析必定先useLocale(Locale.ROOT)。5.3 从入门到精通的练习路线很多人问Scanner到底学到什么程度算精通我列一条实战路线按这个顺序练基本没什么盲区。第一步用Scanner做最基础的控制台交互实现一个简单的学生信息录入系统要求支持整数、浮点数、字符串混合输入并做异常兜底。第二步用Scanner读取一个 CSV 文件通过useDelimiter自定义分隔符正确解析每一列。第三步把解析出来的内容封装成对象存入集合做一个简单的统计功能比如按部门分组、计算平均分。第四步把Scanner换成BufferedReader重写同样的功能对比两者的代码量和性能体会各自适用的场景。第五步尝试用Scanner配合正则实现一个迷你日志解析器提取时间戳、日志级别、错误消息。走完这五步Scanner的常规用法、坑点、性能边界你都有切身体会了。面试问起来随口就能说出细节而且说的是真实踩坑经验不是背八股文。最后再分享一个小技巧。我调试算法题的时候习惯把测试数据放在一个字符串里用Scanner直接解析写完逻辑后切一个Scanner(System.in)就能跑正式输入只需要改一行构造参数。这样既能快速反复验证又不会因为手速跟不上算法逻辑而浪费时间。这个习惯帮我省下了大量调试时间你们可以试试。
1. Scanner 到底解决了什么问题1.1 在 Scanner 出现之前Java 控制台输入有多麻烦我刚开始写 Java 的时候第一个程序是 HelloWorld第二个程序就是控制台读用户输入。当时主流教法是BufferedReader搭配InputStreamReaderBufferedReader reader new BufferedReader(new InputStreamReader(System.in)); String line reader.readLine();这个写法能跑但痛点非常明显。第一只能按行读字符串想要整数还得自己Integer.parseInt()转一手用户手滑输入12.5或者abc立刻收获一个NumberFormatException第二调用链太长System.in是什么、InputStreamReader干嘛用的、BufferedReader又干嘛用的每一步都得理解才能不懵第三想按空格拆多个值得自己split()再遍历代码瞬间膨胀。更隐蔽的坑是readLine()在用户没按回车之前会一直阻塞很多初学者第一次写交互程序就卡在好像是死循环的错觉里。所以 Java 5 推出java.util.Scanner之后这个局面才彻底改观。Scanner直接接受System.in一行代码构造完成还自带nextInt()、nextDouble()、nextLine()这些方法把输入格式解析这个脏活累活全包了。Scanner的核心价值就在于把我们和底层字节流、字符解码之间的复杂度隔离开让我们专注于我想从输入里拿一个整数这种业务意图而不是纠结这一行字节怎么转成字符再转成数字。1.2 System.in 到底是什么很多人背过Scanner in new Scanner(System.in);这个固定写法但System.in到底是什么Scanner拿到它之后做了什么未必清楚。System.in是 JVM 提供的标准输入流类型是InputStream本质是一个字节流。它默认代表键盘输入但在命令行重定向之后它可以是一个文件、一个管道甚至另一个进程的输出。也就是说用Scanner包装System.in写好的逻辑执行java Main input.txt时可以直接读文件内容代码一行都不用改。Scanner拿到InputStream后内部做了好几层处理先把字节流包装成可读的字符流再在内部维护一个字符缓冲区每次调用nextXxx()时用默认的分隔符模式匹配字符命中后把匹配结果的前缀作为 token 返回。整个设计思路本质是正则 缓冲 迭代器的组合这也解释了为什么它这么灵活同时为什么有些坑这么隐蔽。2. 核心 API 用法拆解2.1 构造方法不止有 System.inScanner的构造方法能接收多种参数这是很多人忽略的点。new Scanner(InputStream)最常见比如System.in。new Scanner(File)直接读文件。new Scanner(Path)JDK 7 之后推荐配合字符集参数使用。new Scanner(String)把一个字符串当作输入源做文本解析特方便。new Scanner(Readable)接收任何实现了Readable接口的对象。其中new Scanner(String)我经常拿来做测试。比如写了一个解析方法不想每次跑到控制台敲一遍数据直接构造一个Scanner包字符串Scanner sc new Scanner(12 34 56 78); while (sc.hasNextInt()) { System.out.println(sc.nextInt()); }这种写法用来做单元测试、算法题本地调试都很快而且完全不依赖键盘输入避免了一跑测试就要切窗口去敲数据的尴尬。还有一点值得注意Scanner不是线程安全的多线程环境下共享同一个Scanner实例会导致状态错乱需要每个线程自己持有实例或者外部加锁。面试时偶尔有人问这一点知道就是加分项。2.2 nextXxx 系列值是怎么被读出来的next()、nextLine()、nextInt()是三大高频方法它们的行为差异非常关键。next()读取下一个以空白符分隔的 token返回值是String。nextInt()、nextDouble()等则是先取 token 再做类型转换。nextLine()特殊它不以空白符为分隔而是以换行符为边界读走的是一整行。底层执行顺序是这样的调用nextInt()时Scanner先跳过所有匹配分隔符模式的字符然后收集下一个 token尝试用相应类型解析。如果解析失败会抛出InputMismatchException但要注意那个 token 已经被消费掉了不会留在流里等你重新读。这个问题在实际开发中很常见Scanner sc new Scanner(System.in); int age sc.nextInt(); // 用户输入了 abcInputMismatchException抛出来之后abc已经被消费程序如果还想继续读后面的内容得自己处理异常逻辑否则流的位置已经往前走了。所以做健壮输入时我通常会先hasNextInt()判断再nextInt()读取。与nextLine()配合时还有个经典问题在nextInt()之后直接调用nextLine()得到的是一个空字符串因为上一次nextInt()只消费了数字本身行尾的换行符被留在了流里。后面第 4 章我会专门展开讲这个坑。2.3 useDelimiter自定义分隔符的正确玩法Scanner默认分隔符是\p{javaWhitespace}也就是所有 Java 空白符。但在处理 CSV、日志文件、自定义协议文本时默认分隔符经常不够用这时候就需要useDelimiter()。比如我解析一个用逗号分隔的文件一行是张三,25,北京可以设置分隔符为逗号加可选的空白Scanner sc new Scanner(new File(data.csv), UTF-8); sc.useDelimiter(,|\\r?\\n); while (sc.hasNext()) { System.out.println(sc.next()); }注意useDelimiter接受的是正则表达式不是普通字符串。这既是能力也是责任——写复杂正则时一定要先在测试环境验证因为像|、[、(这些正则元字符在实际数据里可能毫无征兆地出现一旦匹配错乱解析结果会非常诡异。一个我踩过多次的坑分隔符设置不当会导致hasNext()永远返回true造成死循环。比如你只想用逗号做分隔符但文件里实际存在换行那换行符会被当成 token 的一部分返回如果不能正确处理循环体里面对空串或异常格式处理不周程序就跑飞了。所以我会习惯性地把分隔符写成[,\\s]这种兼容英文逗号、中文逗号和空白的组合形式解析效率高很多。3. 实战键盘、文件、字符串三大场景3.1 键盘交互的标准写法先给一个我认为最稳妥的键盘输入模板Scanner in new Scanner(System.in); while (true) { System.out.print(请输入一个整数); if (in.hasNextInt()) { int num in.nextInt(); System.out.println(你输入的是 num); break; } else { in.nextLine(); // 清理掉错误输入防止死循环 } }这里有两个平时写代码容易忽略的动作。第一个是hasNextInt()前置判断避免InputMismatchException导致程序中断第二个是错误分支里的in.nextLine()把当前行的错误 token 清掉否则会死循环——错误输入永远是那个 token每次循环都在同样的位置拿到同样的错误值。很多新手写输入会用try { ... } catch (InputMismatchException e) { ... }的方式处理不是不行但catch里如果忘了重新消费掉错误 token程序依然会卡死。相比之下用hasNextXxx()前置判断的方式更清晰代码也更短。3.2 读取文件时必须处理编码用Scanner读文件是很多人会踩编码坑的场景。如果你直接new Scanner(new File(data.txt))底层会用平台默认编码在中文 Windows 上往往是 GBK而文件本身是 UTF-8读出来就是乱码。正确姿势是显式指定字符集Scanner sc new Scanner(Path.of(data.txt), StandardCharsets.UTF_8);JDK 10 之后Path.of()比Paths.get()写法更简洁默认就是 UTF-8 的Files.newBufferedReader行为一致。而且指定字符集后Scanner内部能正确处理多字节字符像中文、日文、表情符号都不需要额外担心。读文件还有一个场景要注意大文件。Scanner内部虽然有缓冲但它的定位是按 token 解析而不是高效逐行读。一个几百 MB 的日志文件如果只是想按行遍历建议用BufferedReader性能差距在数倍到十几倍但如果你需要按分隔符切 token、做类型转换、按正则过滤Scanner的代码量优势就体现出来了。根据场景选工具不要盲目迷信某一个。3.3 结合集合与流的进阶玩法Scanner说白了是一种IteratorString所以它能直接和集合、Stream API 配合写出很紧凑的代码。一个典型的例子从控制台读一行空格分隔的整数转成ListIntegerScanner sc new Scanner(System.in); ListInteger nums new ArrayList(); while (sc.hasNextInt()) { nums.add(sc.nextInt()); }更进阶的玩法是配合正则做文本清理。比如从一段日志里把时间戳全部提取出来Scanner sc new Scanner(logText); sc.useDelimiter([^0-9]{4}-[0-9]{2}-[0-9]{2}); while (sc.hasNext()) { System.out.println(sc.next()); }这段代码的实际效果是以非时间戳格式为分隔符把日志里所有符合年-月-日格式的片段单独分离出来。虽然写法上有些取巧但确实让我少写了不少正则提取逻辑。这种用分隔符反向提取目标的思路在处理特定格式的文本数据时非常实用。如果要在循环里把Scanner转成 Stream还会用到spliterator的概念Scanner实现了IteratorString所以StreamSupport.stream(Spliterators.spliteratorUnknownSize(sc, Spliterator.ORDERED), false)也能跑起来。不过说实话实际项目中我很少这么写因为Scanner的非线程安全和流式并行处理天然冲突强行并行只会踩坑。知道有这回事就行面试被问到可以答两句。4. 高频坑位与排查实录4.1 nextLine 吃回车问题这个坑简直是 Java 初学者的第一大拦路虎。代码长这样Scanner sc new Scanner(System.in); System.out.print(请输入年龄); int age sc.nextInt(); System.out.print(请输入姓名); String name sc.nextLine(); System.out.println(name); // 输出为空现象就是name读出来是空字符串。原因是nextInt()只消费了数字行尾的换行符还残留在缓冲区里紧接着的nextLine()直接把换行符读走于是得到空串。解决方案通常有几种在nextInt()之后手动调用一次nextLine()把残留换行消费掉。改用nextLine()读整行再自行Integer.parseInt()转换。用hasNextInt()配合nextInt()然后立刻在需要读字符串前调用nextLine()。我个人更推荐第二种思路把所有输入都按行读再用Integer.parseInt()转换。这样做代码虽然长几行但逻辑统一不会出现某个方法只吃一半的边界情况。我实际用得最多的组合是String line sc.nextLine(); int age Integer.parseInt(line.trim());这样明确知道每行输入就是一条记录格式错误也能精确捕获并提示用户重试。4.2 hasNext() 死循环与阻塞hasNext()和hasNextInt()在Scanner里是会阻塞的这一点很多文章没说透。当你用Scanner(System.in)时hasNext()会等待用户输入没有输入就阻塞线程看起来像卡死。这个问题在两类场景里特别突出。一类是算法竞赛、ACM 刷题时在线判题系统通过管道重定向输入文件读完时hasNext()会返回false行为正常但如果你在本地控制台手动跑同样的代码永远等不到false因为控制台不会自己发 EOF。另一类是自己在 IDE 里调试明明写好了while (sc.hasNext())结果程序一直等着让人以为死锁了。排查经验是先确认输入源。控制台手动输入时想结束输入得按组合键发送 EOFLinux 下是 CtrlDWindows 下是 CtrlZ 加回车否则hasNext()永远为真。如果希望程序在用户输入空行时自动结束可以写成while (sc.hasNextLine()) { String line sc.nextLine(); if (line.isEmpty()) { break; } // 处理 line }4.3 要不要关闭 Scanner资源回收的争议Scanner实现了Closeable但要不要关、什么时候关很多人分不清楚。关键区分在于Scanner 包装的是谁。如果包装的是文件、网络流这类外部资源必须关闭最稳的方式是 try-with-resourcestry (Scanner sc new Scanner(Path.of(data.txt), StandardCharsets.UTF_8)) { while (sc.hasNextLine()) { System.out.println(sc.nextLine()); } }如果包装的是System.in那就不能随意close()。因为Scanner.close()会把底层的Readable也关闭而System.in是 JVM 级别的标准输入流关掉之后整个进程都没法再用键盘输入了。尤其在写工具类、交互式命令行程序时一个close()下去后面的代码全都读不到输入这坑我年轻的时候踩过排查了半天才发现是资源被提前释放。稳妥的做法是System.in包出来的Scanner就让它自生自灭不显式关闭。JVM 退出时资源自然释放不用担心泄漏。4.4 正则开销与性能实测Scanner内部用正则匹配分隔符这是它慢的根本原因。我的实测数据一个 50 MB 的文本文件BufferedReader.readLine()逐行处理大概 2 秒内跑完Scanner用默认分隔符做同样的逐行解析通常要 8 秒以上如果分隔符是复杂正则差距还会拉大。但这不代表Scanner一无是处。它的优势场景是输入格式复杂、需要大量类型转换、需要按正则切分。在这些场景里Scanner的代码量可能是BufferedReader的十分之一调试成本也低很多。我的建议是项目里做配置文件解析、小型 DSL 解析、算法题本地调试大胆用Scanner日志清洗、ETL、大数据量导入老老实实用BufferedReader或者更高层的解析库。5. 面试考点与经验沉淀5.1 高频面试题与标准答案这部分我整理了面试中常被追问的Scanner相关问题附上我认为最稳的回答思路。Q1next()与nextLine()的区别next()以空白符为分隔符读取 token读完后光标停在当前 token 末尾不消费分隔符nextLine()以换行符为边界读取整行读完消费掉换行符。两者混合使用时最容易出问题。Q2nextInt()之后用nextLine()为什么会得到空串nextInt()只消费整数 token行尾换行符残留在缓冲区nextLine()读到这个残留换行符后返回空串。解决方式在前面第 4 章已经讲过了核心是要么主动消费掉残留换行要么干脆统一按行读取再解析。Q3Scanner是线程安全的吗不是。Scanner内部有缓冲区、当前位置索引等可变状态多线程共享会产生不可预料的读写错位。需要线程隔离或外部加锁。Q4hasNext()在控制台输入时会阻塞吗会。hasNext()等待输入源产生可用数据对于System.in用户不输入、不发送 EOFhasNext()就会一直阻塞。判断输入是否结束不能依赖hasNext()的false返回除非输入源是文件或管道。Q5Scanner相比BufferedReader的优势和劣势优势是内置类型转换、正则分隔、API 友好适合中小规模文本解析劣势是性能较低、基于正则的匹配有额外开销不适合大数据量逐行处理。5.2 我总结的几条使用规范根据多年的实际项目经验我总结了几条Scanner的使用规范团队代码评审时也经常按这个标准卡人。第一明确输入源后再决定是否关闭流。System.in不关闭文件流用 try-with-resources。第二混合使用nextInt()和nextLine()前必须考虑残留换行。第三处理用户错误输入时一定先把错误 token 消费掉否则循环会卡死。第四读文件务必显式指定字符集否则跨平台必栽跟头。第五写复杂正则分隔符时先用小数据量测试再上生产数据。另外我还会在代码里给Scanner指定一个固定的Locale。因为nextDouble()在不同默认语言环境下对小数点符号的处理不一样某些环境下3.14可能解析失败必须用3,14。稳妥的做法是Scanner sc new Scanner(System.in); sc.useLocale(Locale.ROOT);这个问题真的坑过我一回。一次在某个项目里解析用户上传的数值文件本地开发环境用的是英文Locale一切正常部署到服务器上有一部分用户的数据解析失败排查半天才发现服务器默认Locale是小语种小数点符号规则变了。从那以后我只要用Scanner做数值解析必定先useLocale(Locale.ROOT)。5.3 从入门到精通的练习路线很多人问Scanner到底学到什么程度算精通我列一条实战路线按这个顺序练基本没什么盲区。第一步用Scanner做最基础的控制台交互实现一个简单的学生信息录入系统要求支持整数、浮点数、字符串混合输入并做异常兜底。第二步用Scanner读取一个 CSV 文件通过useDelimiter自定义分隔符正确解析每一列。第三步把解析出来的内容封装成对象存入集合做一个简单的统计功能比如按部门分组、计算平均分。第四步把Scanner换成BufferedReader重写同样的功能对比两者的代码量和性能体会各自适用的场景。第五步尝试用Scanner配合正则实现一个迷你日志解析器提取时间戳、日志级别、错误消息。走完这五步Scanner的常规用法、坑点、性能边界你都有切身体会了。面试问起来随口就能说出细节而且说的是真实踩坑经验不是背八股文。最后再分享一个小技巧。我调试算法题的时候习惯把测试数据放在一个字符串里用Scanner直接解析写完逻辑后切一个Scanner(System.in)就能跑正式输入只需要改一行构造参数。这样既能快速反复验证又不会因为手速跟不上算法逻辑而浪费时间。这个习惯帮我省下了大量调试时间你们可以试试。
