1. 从一段活见鬼的代码谈起为什么同样读文件结果天差地别刚学Java那会儿我写过一段自认为很标准的读文件代码大概长这样FileInputStream fis new FileInputStream(test.txt); byte[] buffer new byte[1024]; int len; while ((len fis.read(buffer)) ! -1) { System.out.print(new String(buffer, 0, len)); } fis.close();文件里明明放着你好世界控制台却打出来一堆奇怪的符号。后来查了才知道new String(bytes)用的是平台默认字符集在Windows上大概率是GBK而文件是UTF-8编码保存的——这俩对不上中文自然全花了。这是很多初学者遇到的第一个坎** FileInputStream 读的是字节而文本是字符中间隔着一道编码的鸿沟。** 我当时的解决思路很简单——既然读字节会乱码那就让JVM帮我做字节到字符的转换于是找到了InputStreamReader。再用它读文本时又发现逐字节转字符效率太差而且一行一行读很不方便于是又引入了BufferedReader。BufferedReader和InputStreamReader这两个类其实是Java I/O体系里最常用的搭子之一。InputStreamReader负责把字节流翻译成字符流BufferedReader负责在这条字符流上提供缓冲加速和按行读取的能力。两者一组合就成了Java里处理文本文件、控制台输入、网络响应体的经典姿势BufferedReader reader new BufferedReader( new InputStreamReader( new FileInputStream(test.txt), StandardCharsets.UTF_8));这篇博文不打算复读API文档而是想把这些类背后为什么这么设计为什么踩坑怎么选参数讲明白再给几个可以直接抄走的实战模板。无论你是刚接触Java I/O的新手还是被乱码、性能问题折磨过的老手都应该能从中找到点东西。2. 先搞清楚层级关系Reader、InputStream、InputStreamReader各管哪一段很多文章一上来就贴代码但没有先把I/O体系的层级讲清楚导致读者只知道这俩能配着用不知道为什么配着用。先看一幅简化的继承关系Reader字符输入流的抽象基类所有读字符的操作都继承它。核心方法read()返回一个char实际是int按字符为单位工作。InputStream字节输入流的抽象基类所有读字节的操作都继承它。核心方法read()返回一个byte实际是int按字节为单位工作。InputStreamReaderReader的子类它接收一个InputStream字节流内部完成字节到字符的转换。它是字节流到字符流的桥。BufferedReader也是Reader的子类但它不直接对接数据源而是包在另一个Reader外面给被包装的字符流提供更大的内部缓冲区和便捷的readLine()方法。把这个关系想清楚为什么要两层包装的问题就迎刃而解了。打个比方InputStream相当于原始货物运输一箱一箱的字节InputStreamReader是报关翻译把货物清单从字节语言翻译成字符语言BufferedReader则是仓库的分拣缓存区一次性搬一大批进来再按行分发给你。没有翻译官你对着字节清单一脸懵没有缓存区你就要一趟一趟去取货费时费力。再往下一层还有一个经常被误用的类叫FileReader。它实际上是InputStreamReader的一个子类内部帮你new FileInputStream(path)但它有一个致命短板——构造时不能指定字符集永远使用平台的默认字符集。在跨平台部署或者读取固定编码的第三方数据时这就是一颗定时炸弹。所以业界很多老手干脆不用FileReader一律通过InputStreamReader显式传Charset。搞清楚了角色分工接下来就要深入这两个类各自的原理看看里面到底做了哪些事情。3. InputStreamReader的核心机制它怎么做到字节变字符不出错InputStreamReader看起来只是包了一层InputStream但内部的转换逻辑远比想象中复杂。它真正干活的是一个叫StreamDecoder的类InputStreamReader的read()方法最后都会委托给它。3.1 一次read()背后发生了什么当你调用reader.read()时StreamDecoder并不是立刻去向底层InputStream要一个字节而是会先看自己的内部字节缓冲区里还有没有未用完的数据。它的默认字节缓冲区大小是8192字节8KB。如果缓冲区里没数据了它才真正触发底层读取一次性向文件或网络读取最多8192字节填充到缓冲区然后从这批字节中按照当前字符集解码出字符返回。这个设计的直接后果是虽然read()每次看起来只返回一个字符但底层实际读取次数远远少于字符个数。这也是InputStreamReader单独使用也能维持一定效率的原因——它自己其实已经有一层缓冲。3.2 编码参数不传就是一颗不定时炸弹构造InputStreamReader时有三种常见写法// 写法一不指定编码不推荐 new InputStreamReader(inputStream) // 写法二指定编码名称可用但字符串容易打错比如UTF8 new InputStreamReader(inputStream, UTF-8) // 写法三指定Charset对象推荐编译期就能检查 new InputStreamReader(inputStream, StandardCharsets.UTF_8) // 或者 new InputStreamReader(inputStream, Charset.forName(UTF-8))写法一的问题在于它调用StreamDecoder.forInputStreamReader()时会获取Charset.defaultCharset()。这个默认值由JVM启动参数file.encoding和操作系统环境决定。在Windows中文系统上往往是GBK在Linux服务器上往往是UTF-8。同一份代码本地跑得好好的部署到服务器上就乱码——八成就是这个原因。更坑的是file.encoding这个参数的影响范围比很多人想的大它不只影响InputStreamReader的默认行为还会影响FileWriter、PrintStream、String.getBytes()等一系列类的默认行为。所以只要涉及跨平台就必须显式指定字符集不要依赖默认值。这是我踩过最深的一个坑强烈建议大家在团队代码规范里直接把它写成硬性要求。3.3 read()为什么返回int而不是char看API文档会发现Reader.read()返回的是int范围从0到65535即一个char能表达的范围内或者返回-1表示流已读完。这样的设计是为了同时表达读到字符和读完了两种状态。如果返回char类型它没法表示没有数据了这个特殊状态。因为你不知道\u0000到底表示空字符还是读完。用int之后-1表示结束0~65535表示真实字符语义就清晰了。这一点同样解释了为什么read(char[] cbuf)方法的返回值是读到的字符数而不会在读到0时自动帮你退出循环。很多初学者写循环时只判断返回值是不是0没判断是不是-1就可能陷入死循环。正确写法是char[] buf new char[1024]; int readCount; while ((readCount reader.read(buf)) ! -1) { // 只处理readCount个字符而不是整个buf }4. BufferedReader的隐藏价值它到底加速了什么readLine凭什么能用说完了InputStreamReader轮到BufferedReader。很多人只知道加个缓冲能变快但不知道快在哪里也不知道缓冲区设置多少合适。4.1 缓冲的核心是减少系统调用次数没有BufferedReader时如果你用InputStreamReader逐个read()字符每读一个字符都可能触发一次底层文件系统或网络调用来获取数据。一次系统调用即使只读一个字节开销也在微秒级别看似不多但当你读几百MB的文件时几百万次微秒级调用累积起来就是几百秒的差距。BufferedReader内部维护了一个char数组缓冲区默认大小是8192个字符。它一次性从被包装的Reader里读入8192个字符存到缓冲区之后你的每次read()或者readLine()都先从缓冲区里取取空了再去触发一次底层读取。这样就把每次读一个字符就发起一次底层调用变成了每8192个字符才发起一次底层调用系统调用次数直接降到几千分之一。到这里你可能会问那InputStreamReader内部不也有字节缓冲区吗为什么还需要BufferedReader这是个很好的问题。InputStreamReader的缓冲区是字节层面的它能减少底层的字节读取次数但每次调用read()返回字符时仍然要做一次从字节到字符的解码。而BufferedReader的缓冲是在字符层面它直接把解码好的字符缓存起来省去了反复解码的过程。两者层级不同解决的问题不完全重叠。不过如果底层Reader没有自动缓冲BufferedReader的收益更明显如果底层Reader自身有缓冲收益会小一些但readLine()这种便捷方法依然是巨大的效率/编码便利性提升。4.2 readLine()的实现逻辑和两个隐蔽细节readLine()大概是BufferedReader最受欢迎的方法它按行读取文本。内部实现逻辑是循环从缓冲区取字符遇到\n或\r\n或\r就停下来把这之前的内容拼成一个字符串返回行尾的换行符不会包含在返回的字符串里。这里有两个隐蔽细节值得注意第一readLine()不包含行尾符。如果你要逐行读取后再原样写回文件直接拼接\n可能会改变原始文件的换行风格比如把\r\n变成了\n。跨平台处理文本时原始文件的换行符是什么一定要先探测或者至少知道否则你读改写一遍文件的行尾符可能就被悄悄换掉了。第二readLine()对空行和文件结尾的判断容易搞混。文件里如果最后一行后面没有换行符readLine()能正常读到最后一行的内容但如果文件以一个换行符结尾那么readLine()读完最后一个空行后返回空字符串再读一次才返回-1null。也就是说返回空字符串不等于文件读完返回null才是读完。4.3 缓冲区大小怎么定默认值就够别瞎折腾BufferedReader的构造方法有两个new BufferedReader(reader, 8192) // 显式指定缓冲区大小 new BufferedReader(reader) // 使用默认8192很多性能强迫症会想那我是不是把缓冲区调到64KB、1MB会更快实测结论是对大多数场景默认8192个字符约8KB ~ 16KB取决于编码已经足够。底层文件系统、操作系统的I/O路径会对读取做页对齐通常4KB磁盘和网络的瓶颈远远大于你这个缓冲区大小。把缓冲区从8KB调到64KB读取性能提升往往在2%以内却白白增加了内存占用。真正需要调大缓冲区的场景是网络状况差、小数据包频繁到达且你特别在意总调用次数的网络流处理这时设置16KB或32KB可以显著减少read返回次数但也别超过64KB收益就开始递减了。5. 从控制台到文件两份可以直接抄走的组合代码模板接下来给两段实际项目中经常用到的模板附带一些我自己的注释和避坑点方便直接改改用。5.1 控制台输入为什么System.in必须包两层System.in是一个InputStream你要读取用户在控制台输入的一行文字比如用户名、命令必须把它转为字符流同时最好加上缓冲支持readLine()。最经典的写法// 标准写法InputStreamReader BufferedReader try (BufferedReader consoleReader new BufferedReader( new InputStreamReader(System.in, StandardCharsets.UTF_8))) { System.out.print(请输入你的名字); String name consoleReader.readLine(); System.out.println(你好 name); }有人会问既然控制台显示本来就是字符为什么System.in不能直接返回字符因为控制台的输入在系统层面仍然是字节序列。它在Windows下可能来自命令行的GBK编码在Linux下可能来自终端的UTF-8编码。InputStreamReader在这里的作用就是按照你和终端约定的编码把字节串翻译成正确的字符。IDE的控制台通常已经配置为UTF-8所以你显式传StandardCharsets.UTF_8通常没问题但在Windows CMD里跑可能需要改成Charset.defaultCharset()或者GBK否则会乱码。这也是一个很经典的本地好好的换到CMD就乱的坑。5.2 按行读取UTF-8文件标准套餐读取一个UTF-8编码的文本文件并逐行处理最标准的姿势如下Path filePath Paths.get(data.txt); try (BufferedReader reader Files.newBufferedReader(filePath, StandardCharsets.UTF_8)) { String line; int lineNumber 0; while ((line reader.readLine()) ! null) { lineNumber; if (line.isBlank()) { // 跳过空行但你要注意空行和空字符串行是两回事 continue; } processLine(line, lineNumber); // 你的业务逻辑 } }这里有一个细节while ((line reader.readLine()) ! null)是铁律。不要把判断写成while (reader.ready())ready()表示下一次读不会阻塞它不等于还有数据。在文件流里有时碰巧能工作但在网络流或管道流里会出大问题——ready()返回false不代表流关闭了可能只是暂时没有数据到达。另外用Files.newBufferedReader()还是new BufferedReader(new InputStreamReader(...))两者其实没本质区别。Files.newBufferedReader替你省了构造这层包装的代码内部也是在创建InputStreamReader。我建议新代码直接用Files.newBufferedReader(filePath, charset)写起来更简洁返回类型依然是BufferedReader完全兼容。5.3 资源释放try-with-resources是底线老代码经常写finally { reader.close(); }如果你还在写这种风格建议全部改用try-with-resources。Reader/InputStream都实现了Closeable接口try-with-resources会自动关闭最外层资源并且会正确传播内部资源关闭时的异常。不过这里的细节是try-with-resources里声明的变量会自动关闭但如果你在try块内部手动创建了资源比如new BufferedReader(...)返回的Reader没有赋给变量它不会自动关闭。所以一定要把资源创建写在try的圆括号里// 正确示范 try (BufferedReader reader new BufferedReader(...)) { ... } // 错误示范内部的reader不会自动关闭 BufferedReader reader new BufferedReader(...); try { ... }还有一点当你用try-with-resources声明了外层BufferedReader时它关闭时会级联关闭内层的InputStreamReader和FileInputStream你不需要也不应该在内层再手动关闭一次否则会重复关闭并有可能抛出IOException虽然通常会被吞掉但是日志不干净。6. 实测对比与高频翻车场景把数据摆出来把坑填平这部分是我在实际项目里做过的性能对比和踩坑整理希望能帮大家少走弯路。6.1 三种读取方式的性能差距有多大有一次我在本地测试读取一个约120MB的UTF-8文本日志文件分别用了三种方式测耗时JVM版本是17Windows 11文件放在NVMe SSD上数据偏向常规多行日志读取方式核心代码实测耗时三次平均备注普通字节流逐字节读fis.read()每次读1个byte约26秒不建议用于文本读取字节数组批量读fis.read(byte[])8KB缓冲约180毫秒字节层面效率很高InputStreamReader BufferedReader按行读br.readLine()循环约190毫秒和字节数组批量读基本持平BufferReader按char[]读br.read(char[])约170毫秒和readLine几乎无差别结论很明显纯逐字节读取比缓冲区读取慢了两个数量级而加了BufferedReader的组合性能基本不输给手动字节数组批量读同时还白送了你readLine()的便利性。所以对于文本处理BufferedReaderInputStreamReader组合在性能和可读性上都是最优解。我自己第一次跑这个对比时也被这个差距吓到了。所以后来在代码评审里只要看到有人用FileReader或者裸FileInputStream.read()循环读文本我都会建议换成标准组合。性能问题不是靠调缓冲区大小解决的而是靠减少无效系统调用解决的。6.2 高频翻车点一编码错乱为什么经常只出现在线上组里之前遇到过一起线上事故本地跑批量任务处理一批十几万行的文本规则一切正常发到Linux服务器上跑出来的规则文件从第100行开始出现中文乱码。排查了半天根因就一句话本地Windows默认GBK服务器默认UTF-8。而代码里有一处用了new FileReader(path)还有一处用了new String(byteArr)没指定编码。这俩API的默认字符集都被平台环境影响所以环境一变就炸。这类问题有几个非常典型的特征本地单测和联调环境一切正常发到服务器或者容器里才暴露。只影响中文或者其他非ASCII字符英文数字完全正常。乱码不是全部乱而是部分乱比如第一行正常后面乱常见于文件是混合编码或者BOM头被错误消费。修复思路全员规范——项目里禁止裸FileReader、裸new String(bytes)、裸getBytes()。统一封装一个TextFileReader工具内部强制StandardCharsets.UTF_8。代码评审在CI规则里加一条扫描发现Charset.defaultCharset()直接标记为问题。这套组合拳下来因为编码导致的线上bug基本绝迹。6.3 高频翻车点二readLine()读到一半数据去哪了还有一个特别容易踩的坑来自readLine()的阻塞语义。它在网络流中的应用尤其危险。假设你从Socket输入流读数据服务端约定一条消息以换行符结尾。你的代码BufferedReader reader new BufferedReader( new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)); String line reader.readLine();如果服务端迟迟不发换行符或者发送的数据中间有半个消息TCP粘包/半包readLine()会一直阻塞等\n。这在同步编程里是正常的但很多新手误以为readLine()返回null就代表连接断了其实恰恰相反——如果连接保持打开但没有更多数据readLine()会无限期阻塞而不是返回null。只有对端正常关闭连接发送FIN包或发生RST时readLine()才会返回null或抛出异常。处理这类场景的常见方案用超时控制设置socket.setSoTimeout(3000)让readLine()在超过3秒没数据时抛出SocketTimeoutException。改用read(char[])配合状态机解析半包而不是依赖按行读取。消息协议里显式带上长度字段比如前4字节表示长度不要依赖换行符分隔。6.4 高频翻车点三BOM头与压缩编码的特殊情况UTF-8编码的文本文件如果开头有BOM\uFEFFreadLine()读第一行时这仨字节会被当作一个不可见字符一起读进来。最常见的影响是解析第一行开头的字段时多了一个\uFEFF前缀导致startsWith、JSON解析第一层键名匹配等操作莫名其妙失败。处理方式通常在工具类里做一次BOM剥离public static BufferedReader openUtf8WithBomSkip(Path file) throws IOException { InputStream in new FileInputStream(file.toFile()); PushbackInputStream pbin new PushbackInputStream(in, 3); byte[] bom new byte[3]; int len pbin.read(bom); if (!(len 3 (bom[0] 0xFF) 0xEF (bom[1] 0xFF) 0xBB (bom[2] 0xFF) 0xBF)) { if (len 0) pbin.unread(bom, 0, len); } return new BufferedReader(new InputStreamReader(pbin, StandardCharsets.UTF_8)); }另外和编码相关的还有压缩场景GZIPInputStream包裹后在外部再套InputStreamReader和BufferedReader顺序不能乱。一定是BufferedReader最外、InputStreamReader中间、GZIPInputStream最里反了就会被解码后的字符喂给压缩流直接报错。6.5 为什么异常日志里经常看到Stream closed用了try-with-resources后还偶尔看到IOException: Stream closed这是怎么回事通常是代码里把BufferedReader传给了别的组件那个组件在自己close()的时候顺手把你这个reader也关了。或者你对同一个BufferedReader同时在两个线程里调用readLine()。BufferedReader不是线程安全的它内部没有锁保护多线程同时读会互相竞争内部缓冲区轻则丢数据重则抛Stream closed。我见过的最离谱的案例是一个BufferedReader被放进了全局静态变量然后一个Web服务的每个请求线程都来readLine()。当时的代码能跑纯粹是运气好——多个线程恰好每次都读到同一条缓存后来流量一上来就彻底乱了。对于共享的reader请在每次使用时创建局部实例用完立刻关闭。如果你确实需要多线程共享读取同一个文件为每个线程各自创建一个独立reader每个reader从文件的独立偏移量开始读。7. 现代Java的替代选择与我的取舍建议Java 8之后Files工具类和String方法让文本读取有了更多选择。这部分聊聊面对这些新写法我应该用谁。7.1 Files.readAllLines和Files.readStringJava 8引入Files.readAllLines(path, charset)Java 11又给出Files.readString(path, charset)。这两个方法非常适合一次性把整个小文件读进内存的场合。// Java 11 一次性读取整个文件 String content Files.readString(Paths.get(data.txt), StandardCharsets.UTF_8); // Java 8 按行读取并返回List ListString lines Files.readAllLines(Paths.get(data.txt), StandardCharsets.UTF_8);它们处理的场景是文件不大内存放得下。注意readAllLines底层其实会把整个文件读入内存再按行拆分一份字节副本一份行列表每行一个String对象内存占用远大于文件本身大小。用来读配置文件、小数据文件没什么问题但拿去读几百MB的日志内存直接原地起飞。我的经验阈值是文件大小在10MB以内且你需要全部内容时用 readString/readAllLines超过这个量或者你想逐行流式处理老老实实用BufferedReader.readLine()循环。7.2 Scanner是备胎还是优选Scanner也可以读文本文件和控制台还提供了nextInt()、nextDouble()这类便捷方法。但它自身没有高性能缓冲内部使用的是InputStreamReader 字符缓冲的组合解析耗时偏长而且默认分隔符是空白字符处理中英文混排文本时容易踩坑。我的看法是Scanner适合教学和快速写工具脚本不适合做正式的文件批处理或者网络流解析。你自己掂量一下如果只是写个一次性脚本扫几行输入选谁都行但要处理几十万行的业务数据务必回到BufferedReader。7.3 这些新API里依然存在的编码坑需要注意的是Files.readAllLines(path)这个重载方法如果不传Charset同样会用UTF-8Java 18之前其实是UTF-8Java 18之后Files相关方法默认编码统一为UTF-8但没有全部API都改。说白了新API只是把默认行为统一了些但老APIFileReader等依然深陷平台默认字符集的泥潭。团队内依然要立规矩凡是文本处理要么显式传Charset要么只用明确文档说明默认是UTF-8的新API。7.4 什么时候我依然会回到InputStreamReaderBufferedReader虽然Files.readString方便但我个人遇到以下三种情况还是会默认写BufferedReader流式处理大文件必须逐行执行某些有状态操作比如聚合统计、逐行校验。从网络、管道、标准输入读取字符流此时只有InputStreamReader能接住字节流的实时性readAllLines这类方法是没法操作Stream的。需要精细控制读取进度和异常恢复BufferedReader的read(char[], off, len)能精确控制读取量方便断点续读。如果你也是写批处理、中间件、爬虫这类经常和IO打交道的代码建议把BufferedReader InputStreamReader组合练成条件反射。它不是最花哨的写法但它是Java文本I/O里最能打的基础底座。8. 最后分享两个实用的小习惯第一在封装工具类时永远别只提供便捷方法而不暴露编码参数。我见过很多工具类的readText(Path path)签名只有一个参数内部默默使用默认编码使用的人完全感知不到。后来我在团队里定了个小规则凡是文本读写相关的工具方法至少提供一个显式传Charset的重载。哪怕90%的调用方永远只传StandardCharsets.UTF_8也一定要留下这个口子。第二在私有协议或日志打印里最好别依赖readLine()返回null作为结束的唯一标志。尤其是从 Socket 流读取时尽量设置soTimeout避免服务端异常迟迟不关闭连接导致线程永久阻塞。这个习惯在写长连接服务时能救你一命。这两个类用好了Java文本处理的基本功就算扎实了。剩下的各种编码细节和性能陷阱多踩几次、多测几次自然就能形成肌肉记忆。
1. 从一段活见鬼的代码谈起为什么同样读文件结果天差地别刚学Java那会儿我写过一段自认为很标准的读文件代码大概长这样FileInputStream fis new FileInputStream(test.txt); byte[] buffer new byte[1024]; int len; while ((len fis.read(buffer)) ! -1) { System.out.print(new String(buffer, 0, len)); } fis.close();文件里明明放着你好世界控制台却打出来一堆奇怪的符号。后来查了才知道new String(bytes)用的是平台默认字符集在Windows上大概率是GBK而文件是UTF-8编码保存的——这俩对不上中文自然全花了。这是很多初学者遇到的第一个坎** FileInputStream 读的是字节而文本是字符中间隔着一道编码的鸿沟。** 我当时的解决思路很简单——既然读字节会乱码那就让JVM帮我做字节到字符的转换于是找到了InputStreamReader。再用它读文本时又发现逐字节转字符效率太差而且一行一行读很不方便于是又引入了BufferedReader。BufferedReader和InputStreamReader这两个类其实是Java I/O体系里最常用的搭子之一。InputStreamReader负责把字节流翻译成字符流BufferedReader负责在这条字符流上提供缓冲加速和按行读取的能力。两者一组合就成了Java里处理文本文件、控制台输入、网络响应体的经典姿势BufferedReader reader new BufferedReader( new InputStreamReader( new FileInputStream(test.txt), StandardCharsets.UTF_8));这篇博文不打算复读API文档而是想把这些类背后为什么这么设计为什么踩坑怎么选参数讲明白再给几个可以直接抄走的实战模板。无论你是刚接触Java I/O的新手还是被乱码、性能问题折磨过的老手都应该能从中找到点东西。2. 先搞清楚层级关系Reader、InputStream、InputStreamReader各管哪一段很多文章一上来就贴代码但没有先把I/O体系的层级讲清楚导致读者只知道这俩能配着用不知道为什么配着用。先看一幅简化的继承关系Reader字符输入流的抽象基类所有读字符的操作都继承它。核心方法read()返回一个char实际是int按字符为单位工作。InputStream字节输入流的抽象基类所有读字节的操作都继承它。核心方法read()返回一个byte实际是int按字节为单位工作。InputStreamReaderReader的子类它接收一个InputStream字节流内部完成字节到字符的转换。它是字节流到字符流的桥。BufferedReader也是Reader的子类但它不直接对接数据源而是包在另一个Reader外面给被包装的字符流提供更大的内部缓冲区和便捷的readLine()方法。把这个关系想清楚为什么要两层包装的问题就迎刃而解了。打个比方InputStream相当于原始货物运输一箱一箱的字节InputStreamReader是报关翻译把货物清单从字节语言翻译成字符语言BufferedReader则是仓库的分拣缓存区一次性搬一大批进来再按行分发给你。没有翻译官你对着字节清单一脸懵没有缓存区你就要一趟一趟去取货费时费力。再往下一层还有一个经常被误用的类叫FileReader。它实际上是InputStreamReader的一个子类内部帮你new FileInputStream(path)但它有一个致命短板——构造时不能指定字符集永远使用平台的默认字符集。在跨平台部署或者读取固定编码的第三方数据时这就是一颗定时炸弹。所以业界很多老手干脆不用FileReader一律通过InputStreamReader显式传Charset。搞清楚了角色分工接下来就要深入这两个类各自的原理看看里面到底做了哪些事情。3. InputStreamReader的核心机制它怎么做到字节变字符不出错InputStreamReader看起来只是包了一层InputStream但内部的转换逻辑远比想象中复杂。它真正干活的是一个叫StreamDecoder的类InputStreamReader的read()方法最后都会委托给它。3.1 一次read()背后发生了什么当你调用reader.read()时StreamDecoder并不是立刻去向底层InputStream要一个字节而是会先看自己的内部字节缓冲区里还有没有未用完的数据。它的默认字节缓冲区大小是8192字节8KB。如果缓冲区里没数据了它才真正触发底层读取一次性向文件或网络读取最多8192字节填充到缓冲区然后从这批字节中按照当前字符集解码出字符返回。这个设计的直接后果是虽然read()每次看起来只返回一个字符但底层实际读取次数远远少于字符个数。这也是InputStreamReader单独使用也能维持一定效率的原因——它自己其实已经有一层缓冲。3.2 编码参数不传就是一颗不定时炸弹构造InputStreamReader时有三种常见写法// 写法一不指定编码不推荐 new InputStreamReader(inputStream) // 写法二指定编码名称可用但字符串容易打错比如UTF8 new InputStreamReader(inputStream, UTF-8) // 写法三指定Charset对象推荐编译期就能检查 new InputStreamReader(inputStream, StandardCharsets.UTF_8) // 或者 new InputStreamReader(inputStream, Charset.forName(UTF-8))写法一的问题在于它调用StreamDecoder.forInputStreamReader()时会获取Charset.defaultCharset()。这个默认值由JVM启动参数file.encoding和操作系统环境决定。在Windows中文系统上往往是GBK在Linux服务器上往往是UTF-8。同一份代码本地跑得好好的部署到服务器上就乱码——八成就是这个原因。更坑的是file.encoding这个参数的影响范围比很多人想的大它不只影响InputStreamReader的默认行为还会影响FileWriter、PrintStream、String.getBytes()等一系列类的默认行为。所以只要涉及跨平台就必须显式指定字符集不要依赖默认值。这是我踩过最深的一个坑强烈建议大家在团队代码规范里直接把它写成硬性要求。3.3 read()为什么返回int而不是char看API文档会发现Reader.read()返回的是int范围从0到65535即一个char能表达的范围内或者返回-1表示流已读完。这样的设计是为了同时表达读到字符和读完了两种状态。如果返回char类型它没法表示没有数据了这个特殊状态。因为你不知道\u0000到底表示空字符还是读完。用int之后-1表示结束0~65535表示真实字符语义就清晰了。这一点同样解释了为什么read(char[] cbuf)方法的返回值是读到的字符数而不会在读到0时自动帮你退出循环。很多初学者写循环时只判断返回值是不是0没判断是不是-1就可能陷入死循环。正确写法是char[] buf new char[1024]; int readCount; while ((readCount reader.read(buf)) ! -1) { // 只处理readCount个字符而不是整个buf }4. BufferedReader的隐藏价值它到底加速了什么readLine凭什么能用说完了InputStreamReader轮到BufferedReader。很多人只知道加个缓冲能变快但不知道快在哪里也不知道缓冲区设置多少合适。4.1 缓冲的核心是减少系统调用次数没有BufferedReader时如果你用InputStreamReader逐个read()字符每读一个字符都可能触发一次底层文件系统或网络调用来获取数据。一次系统调用即使只读一个字节开销也在微秒级别看似不多但当你读几百MB的文件时几百万次微秒级调用累积起来就是几百秒的差距。BufferedReader内部维护了一个char数组缓冲区默认大小是8192个字符。它一次性从被包装的Reader里读入8192个字符存到缓冲区之后你的每次read()或者readLine()都先从缓冲区里取取空了再去触发一次底层读取。这样就把每次读一个字符就发起一次底层调用变成了每8192个字符才发起一次底层调用系统调用次数直接降到几千分之一。到这里你可能会问那InputStreamReader内部不也有字节缓冲区吗为什么还需要BufferedReader这是个很好的问题。InputStreamReader的缓冲区是字节层面的它能减少底层的字节读取次数但每次调用read()返回字符时仍然要做一次从字节到字符的解码。而BufferedReader的缓冲是在字符层面它直接把解码好的字符缓存起来省去了反复解码的过程。两者层级不同解决的问题不完全重叠。不过如果底层Reader没有自动缓冲BufferedReader的收益更明显如果底层Reader自身有缓冲收益会小一些但readLine()这种便捷方法依然是巨大的效率/编码便利性提升。4.2 readLine()的实现逻辑和两个隐蔽细节readLine()大概是BufferedReader最受欢迎的方法它按行读取文本。内部实现逻辑是循环从缓冲区取字符遇到\n或\r\n或\r就停下来把这之前的内容拼成一个字符串返回行尾的换行符不会包含在返回的字符串里。这里有两个隐蔽细节值得注意第一readLine()不包含行尾符。如果你要逐行读取后再原样写回文件直接拼接\n可能会改变原始文件的换行风格比如把\r\n变成了\n。跨平台处理文本时原始文件的换行符是什么一定要先探测或者至少知道否则你读改写一遍文件的行尾符可能就被悄悄换掉了。第二readLine()对空行和文件结尾的判断容易搞混。文件里如果最后一行后面没有换行符readLine()能正常读到最后一行的内容但如果文件以一个换行符结尾那么readLine()读完最后一个空行后返回空字符串再读一次才返回-1null。也就是说返回空字符串不等于文件读完返回null才是读完。4.3 缓冲区大小怎么定默认值就够别瞎折腾BufferedReader的构造方法有两个new BufferedReader(reader, 8192) // 显式指定缓冲区大小 new BufferedReader(reader) // 使用默认8192很多性能强迫症会想那我是不是把缓冲区调到64KB、1MB会更快实测结论是对大多数场景默认8192个字符约8KB ~ 16KB取决于编码已经足够。底层文件系统、操作系统的I/O路径会对读取做页对齐通常4KB磁盘和网络的瓶颈远远大于你这个缓冲区大小。把缓冲区从8KB调到64KB读取性能提升往往在2%以内却白白增加了内存占用。真正需要调大缓冲区的场景是网络状况差、小数据包频繁到达且你特别在意总调用次数的网络流处理这时设置16KB或32KB可以显著减少read返回次数但也别超过64KB收益就开始递减了。5. 从控制台到文件两份可以直接抄走的组合代码模板接下来给两段实际项目中经常用到的模板附带一些我自己的注释和避坑点方便直接改改用。5.1 控制台输入为什么System.in必须包两层System.in是一个InputStream你要读取用户在控制台输入的一行文字比如用户名、命令必须把它转为字符流同时最好加上缓冲支持readLine()。最经典的写法// 标准写法InputStreamReader BufferedReader try (BufferedReader consoleReader new BufferedReader( new InputStreamReader(System.in, StandardCharsets.UTF_8))) { System.out.print(请输入你的名字); String name consoleReader.readLine(); System.out.println(你好 name); }有人会问既然控制台显示本来就是字符为什么System.in不能直接返回字符因为控制台的输入在系统层面仍然是字节序列。它在Windows下可能来自命令行的GBK编码在Linux下可能来自终端的UTF-8编码。InputStreamReader在这里的作用就是按照你和终端约定的编码把字节串翻译成正确的字符。IDE的控制台通常已经配置为UTF-8所以你显式传StandardCharsets.UTF_8通常没问题但在Windows CMD里跑可能需要改成Charset.defaultCharset()或者GBK否则会乱码。这也是一个很经典的本地好好的换到CMD就乱的坑。5.2 按行读取UTF-8文件标准套餐读取一个UTF-8编码的文本文件并逐行处理最标准的姿势如下Path filePath Paths.get(data.txt); try (BufferedReader reader Files.newBufferedReader(filePath, StandardCharsets.UTF_8)) { String line; int lineNumber 0; while ((line reader.readLine()) ! null) { lineNumber; if (line.isBlank()) { // 跳过空行但你要注意空行和空字符串行是两回事 continue; } processLine(line, lineNumber); // 你的业务逻辑 } }这里有一个细节while ((line reader.readLine()) ! null)是铁律。不要把判断写成while (reader.ready())ready()表示下一次读不会阻塞它不等于还有数据。在文件流里有时碰巧能工作但在网络流或管道流里会出大问题——ready()返回false不代表流关闭了可能只是暂时没有数据到达。另外用Files.newBufferedReader()还是new BufferedReader(new InputStreamReader(...))两者其实没本质区别。Files.newBufferedReader替你省了构造这层包装的代码内部也是在创建InputStreamReader。我建议新代码直接用Files.newBufferedReader(filePath, charset)写起来更简洁返回类型依然是BufferedReader完全兼容。5.3 资源释放try-with-resources是底线老代码经常写finally { reader.close(); }如果你还在写这种风格建议全部改用try-with-resources。Reader/InputStream都实现了Closeable接口try-with-resources会自动关闭最外层资源并且会正确传播内部资源关闭时的异常。不过这里的细节是try-with-resources里声明的变量会自动关闭但如果你在try块内部手动创建了资源比如new BufferedReader(...)返回的Reader没有赋给变量它不会自动关闭。所以一定要把资源创建写在try的圆括号里// 正确示范 try (BufferedReader reader new BufferedReader(...)) { ... } // 错误示范内部的reader不会自动关闭 BufferedReader reader new BufferedReader(...); try { ... }还有一点当你用try-with-resources声明了外层BufferedReader时它关闭时会级联关闭内层的InputStreamReader和FileInputStream你不需要也不应该在内层再手动关闭一次否则会重复关闭并有可能抛出IOException虽然通常会被吞掉但是日志不干净。6. 实测对比与高频翻车场景把数据摆出来把坑填平这部分是我在实际项目里做过的性能对比和踩坑整理希望能帮大家少走弯路。6.1 三种读取方式的性能差距有多大有一次我在本地测试读取一个约120MB的UTF-8文本日志文件分别用了三种方式测耗时JVM版本是17Windows 11文件放在NVMe SSD上数据偏向常规多行日志读取方式核心代码实测耗时三次平均备注普通字节流逐字节读fis.read()每次读1个byte约26秒不建议用于文本读取字节数组批量读fis.read(byte[])8KB缓冲约180毫秒字节层面效率很高InputStreamReader BufferedReader按行读br.readLine()循环约190毫秒和字节数组批量读基本持平BufferReader按char[]读br.read(char[])约170毫秒和readLine几乎无差别结论很明显纯逐字节读取比缓冲区读取慢了两个数量级而加了BufferedReader的组合性能基本不输给手动字节数组批量读同时还白送了你readLine()的便利性。所以对于文本处理BufferedReaderInputStreamReader组合在性能和可读性上都是最优解。我自己第一次跑这个对比时也被这个差距吓到了。所以后来在代码评审里只要看到有人用FileReader或者裸FileInputStream.read()循环读文本我都会建议换成标准组合。性能问题不是靠调缓冲区大小解决的而是靠减少无效系统调用解决的。6.2 高频翻车点一编码错乱为什么经常只出现在线上组里之前遇到过一起线上事故本地跑批量任务处理一批十几万行的文本规则一切正常发到Linux服务器上跑出来的规则文件从第100行开始出现中文乱码。排查了半天根因就一句话本地Windows默认GBK服务器默认UTF-8。而代码里有一处用了new FileReader(path)还有一处用了new String(byteArr)没指定编码。这俩API的默认字符集都被平台环境影响所以环境一变就炸。这类问题有几个非常典型的特征本地单测和联调环境一切正常发到服务器或者容器里才暴露。只影响中文或者其他非ASCII字符英文数字完全正常。乱码不是全部乱而是部分乱比如第一行正常后面乱常见于文件是混合编码或者BOM头被错误消费。修复思路全员规范——项目里禁止裸FileReader、裸new String(bytes)、裸getBytes()。统一封装一个TextFileReader工具内部强制StandardCharsets.UTF_8。代码评审在CI规则里加一条扫描发现Charset.defaultCharset()直接标记为问题。这套组合拳下来因为编码导致的线上bug基本绝迹。6.3 高频翻车点二readLine()读到一半数据去哪了还有一个特别容易踩的坑来自readLine()的阻塞语义。它在网络流中的应用尤其危险。假设你从Socket输入流读数据服务端约定一条消息以换行符结尾。你的代码BufferedReader reader new BufferedReader( new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)); String line reader.readLine();如果服务端迟迟不发换行符或者发送的数据中间有半个消息TCP粘包/半包readLine()会一直阻塞等\n。这在同步编程里是正常的但很多新手误以为readLine()返回null就代表连接断了其实恰恰相反——如果连接保持打开但没有更多数据readLine()会无限期阻塞而不是返回null。只有对端正常关闭连接发送FIN包或发生RST时readLine()才会返回null或抛出异常。处理这类场景的常见方案用超时控制设置socket.setSoTimeout(3000)让readLine()在超过3秒没数据时抛出SocketTimeoutException。改用read(char[])配合状态机解析半包而不是依赖按行读取。消息协议里显式带上长度字段比如前4字节表示长度不要依赖换行符分隔。6.4 高频翻车点三BOM头与压缩编码的特殊情况UTF-8编码的文本文件如果开头有BOM\uFEFFreadLine()读第一行时这仨字节会被当作一个不可见字符一起读进来。最常见的影响是解析第一行开头的字段时多了一个\uFEFF前缀导致startsWith、JSON解析第一层键名匹配等操作莫名其妙失败。处理方式通常在工具类里做一次BOM剥离public static BufferedReader openUtf8WithBomSkip(Path file) throws IOException { InputStream in new FileInputStream(file.toFile()); PushbackInputStream pbin new PushbackInputStream(in, 3); byte[] bom new byte[3]; int len pbin.read(bom); if (!(len 3 (bom[0] 0xFF) 0xEF (bom[1] 0xFF) 0xBB (bom[2] 0xFF) 0xBF)) { if (len 0) pbin.unread(bom, 0, len); } return new BufferedReader(new InputStreamReader(pbin, StandardCharsets.UTF_8)); }另外和编码相关的还有压缩场景GZIPInputStream包裹后在外部再套InputStreamReader和BufferedReader顺序不能乱。一定是BufferedReader最外、InputStreamReader中间、GZIPInputStream最里反了就会被解码后的字符喂给压缩流直接报错。6.5 为什么异常日志里经常看到Stream closed用了try-with-resources后还偶尔看到IOException: Stream closed这是怎么回事通常是代码里把BufferedReader传给了别的组件那个组件在自己close()的时候顺手把你这个reader也关了。或者你对同一个BufferedReader同时在两个线程里调用readLine()。BufferedReader不是线程安全的它内部没有锁保护多线程同时读会互相竞争内部缓冲区轻则丢数据重则抛Stream closed。我见过的最离谱的案例是一个BufferedReader被放进了全局静态变量然后一个Web服务的每个请求线程都来readLine()。当时的代码能跑纯粹是运气好——多个线程恰好每次都读到同一条缓存后来流量一上来就彻底乱了。对于共享的reader请在每次使用时创建局部实例用完立刻关闭。如果你确实需要多线程共享读取同一个文件为每个线程各自创建一个独立reader每个reader从文件的独立偏移量开始读。7. 现代Java的替代选择与我的取舍建议Java 8之后Files工具类和String方法让文本读取有了更多选择。这部分聊聊面对这些新写法我应该用谁。7.1 Files.readAllLines和Files.readStringJava 8引入Files.readAllLines(path, charset)Java 11又给出Files.readString(path, charset)。这两个方法非常适合一次性把整个小文件读进内存的场合。// Java 11 一次性读取整个文件 String content Files.readString(Paths.get(data.txt), StandardCharsets.UTF_8); // Java 8 按行读取并返回List ListString lines Files.readAllLines(Paths.get(data.txt), StandardCharsets.UTF_8);它们处理的场景是文件不大内存放得下。注意readAllLines底层其实会把整个文件读入内存再按行拆分一份字节副本一份行列表每行一个String对象内存占用远大于文件本身大小。用来读配置文件、小数据文件没什么问题但拿去读几百MB的日志内存直接原地起飞。我的经验阈值是文件大小在10MB以内且你需要全部内容时用 readString/readAllLines超过这个量或者你想逐行流式处理老老实实用BufferedReader.readLine()循环。7.2 Scanner是备胎还是优选Scanner也可以读文本文件和控制台还提供了nextInt()、nextDouble()这类便捷方法。但它自身没有高性能缓冲内部使用的是InputStreamReader 字符缓冲的组合解析耗时偏长而且默认分隔符是空白字符处理中英文混排文本时容易踩坑。我的看法是Scanner适合教学和快速写工具脚本不适合做正式的文件批处理或者网络流解析。你自己掂量一下如果只是写个一次性脚本扫几行输入选谁都行但要处理几十万行的业务数据务必回到BufferedReader。7.3 这些新API里依然存在的编码坑需要注意的是Files.readAllLines(path)这个重载方法如果不传Charset同样会用UTF-8Java 18之前其实是UTF-8Java 18之后Files相关方法默认编码统一为UTF-8但没有全部API都改。说白了新API只是把默认行为统一了些但老APIFileReader等依然深陷平台默认字符集的泥潭。团队内依然要立规矩凡是文本处理要么显式传Charset要么只用明确文档说明默认是UTF-8的新API。7.4 什么时候我依然会回到InputStreamReaderBufferedReader虽然Files.readString方便但我个人遇到以下三种情况还是会默认写BufferedReader流式处理大文件必须逐行执行某些有状态操作比如聚合统计、逐行校验。从网络、管道、标准输入读取字符流此时只有InputStreamReader能接住字节流的实时性readAllLines这类方法是没法操作Stream的。需要精细控制读取进度和异常恢复BufferedReader的read(char[], off, len)能精确控制读取量方便断点续读。如果你也是写批处理、中间件、爬虫这类经常和IO打交道的代码建议把BufferedReader InputStreamReader组合练成条件反射。它不是最花哨的写法但它是Java文本I/O里最能打的基础底座。8. 最后分享两个实用的小习惯第一在封装工具类时永远别只提供便捷方法而不暴露编码参数。我见过很多工具类的readText(Path path)签名只有一个参数内部默默使用默认编码使用的人完全感知不到。后来我在团队里定了个小规则凡是文本读写相关的工具方法至少提供一个显式传Charset的重载。哪怕90%的调用方永远只传StandardCharsets.UTF_8也一定要留下这个口子。第二在私有协议或日志打印里最好别依赖readLine()返回null作为结束的唯一标志。尤其是从 Socket 流读取时尽量设置soTimeout避免服务端异常迟迟不关闭连接导致线程永久阻塞。这个习惯在写长连接服务时能救你一命。这两个类用好了Java文本处理的基本功就算扎实了。剩下的各种编码细节和性能陷阱多踩几次、多测几次自然就能形成肌肉记忆。
