1. 为什么一个字符流读取类值得单独写一篇刚入行那会儿我对BufferedReader的认知就停留在“读文件用的套在FileReader外面”。直到有一次做一个日志分析的小工具需要按行读取一个几百兆的文本文件我图省事直接用了FileReader.read()一个字符一个字符地读结果跑了快两分钟才处理完CPU 风扇呼呼转。后来换成BufferedReader包一层同样的文件十几秒就搞定了。那次之后我才认真去翻了这个类的源码发现它远不止“套一层”这么简单。BufferedReader是 Java IO 体系里字符输入流的一个缓冲包装类位于java.io包下继承自Reader。它的核心价值有两个一是通过内置字符缓冲区减少对底层流的频繁调用二是提供了readLine()这个极其顺手的按行读取方法。别看它只有这么点功能实际项目里凡是涉及文本读取的场景——配置文件解析、日志处理、CSV 导入、HTTP 响应体读取——几乎都绕不开它。这篇文章适合谁看如果你写过 Java 但对 IO 流总是“能用就行、报错就懵”那这篇能帮你把BufferedReader的里里外外理清楚如果你已经用了很久但没深究过它的缓冲机制、编码陷阱和关闭顺序那这篇里关于缓冲区大小选择、字符编码配合、异常处理的内容应该能让你少踩几个坑。我会从设计思路讲到源码细节再给出一套可以直接抄的实操模板最后把常见的坑一个个列出来。2. 拆开看设计BufferedReader 到底解决了什么问题2.1 没有缓冲时一次读取有多“贵”要理解BufferedReader的价值得先知道没有它的时候发生了什么。假设你用FileReader去读文件每次调用read()方法最终都会触发一次操作系统的系统调用从磁盘或者操作系统的页缓存里取数据。系统调用意味着用户态和内核态的切换这个开销相对于纯粹的内存操作来说是非常大的。打个比方你要从图书馆借 100 本书如果每借一本就跑一趟图书馆来回 100 趟大部分时间都花在路上了而BufferedReader的做法是先一次性借回来一批比如 8192 本对应默认缓冲区大小放在你手边需要的时候直接从手边拿拿完了再去借下一批。这就是缓冲的本质——用空间换时间把多次小开销的远程操作合并成少数几次大开销的操作。具体到数字上默认缓冲区大小是 8192 个字符。也就是说每调用一次底层流的read实际上会填充 8192 个字符到缓冲区之后 8192 次read()调用都直接从内存缓冲区取不再触碰底层流。这个比例带来的性能提升在读取大文件时是数量级的。2.2 缓冲区的内部结构一个字符数组加两个指针BufferedReader的内部其实不复杂核心就几个字段private char cb[]; // 字符缓冲区 private int nChars; // 缓冲区中的有效字符总数 private int nextChar; // 下一个要读取的字符在缓冲区中的位置cb就是那个字符数组默认长度 8192。nextChar指向下一个待读取的位置nChars表示当前缓冲区里实际有多少个有效字符。每次调用read()如果nextChar nChars说明缓冲区里的数据读完了就调用fill()方法去底层流再读一批进来重置nextChar为 0更新nChars。如果底层流也读完了返回 -1就返回 -1 表示流结束。这个设计有个细节值得注意fill()方法在填充缓冲区时会先处理一种特殊情况——如果缓冲区里还有没被读取的字符nextChar nChars它会先把这些剩余字符挪到数组开头然后再从底层流读取新数据填充剩余空间。这个逻辑保证了不会因为填充操作而丢失还没被消费的数据。2.3 readLine() 的实现逻辑它并不是魔法很多人用readLine()用得很爽但没想过它是怎么实现的。其实它的逻辑很朴素从缓冲区里一个字符一个字符地读遇到\n、\r或者\r\n就认为一行结束把之前读到的字符拼成一个字符串返回。如果读到流末尾还没遇到换行符就把已读到的内容作为最后一行返回如果流末尾且一个字符都没读到返回null。这里有个容易忽略的点readLine()返回的字符串不包含行终止符。也就是说如果你读的是hello\n返回的是hello那个\n被吃掉了。这个行为在大多数场景下是我们想要的但如果你需要保留原始的行终止符比如做文件内容的精确比对就得自己用read()逐字符处理或者用 Java 11 引入的lines()方法配合其他手段。另外readLine()对行终止符的识别是跨平台的\nUnix/Linux、\r老 Mac、\r\nWindows都能正确识别。这意味着你用readLine()读一个 Windows 上创建的文件不会在每行末尾多出一个\r。这个兼容性在跨平台项目里非常实用。3. 从零到一BufferedReader 的完整实操流程3.1 最基础的用法包装 FileReader 读文本文件先看一个最简版本这是几乎所有教程都会给的写法try (BufferedReader br new BufferedReader(new FileReader(data.txt))) { String line; while ((line br.readLine()) ! null) { System.out.println(line); } } catch (IOException e) { e.printStackTrace(); }这段代码有几个点值得展开说。第一用了 try-with-resources 语法BufferedReader会在 try 块结束时自动关闭不需要手动写finally里的close()。第二while ((line br.readLine()) ! null)这个写法把赋值和判断合在一起是读取流的经典模式但要注意readLine()返回null只表示流结束不表示出错出错会抛IOException。第三FileReader使用的是平台默认字符集这在跨平台场景下可能出问题后面会专门讲。3.2 指定字符编码避免乱码的关键一步FileReader的构造函数不接受字符集参数它永远使用平台默认编码。在 Windows 中文环境下默认可能是 GBK在 Linux 上通常是 UTF-8这就导致同一个文件在不同机器上读出来可能乱码。正确的做法是用InputStreamReader包一层FileInputStream显式指定编码try (BufferedReader br new BufferedReader( new InputStreamReader(new FileInputStream(data.txt), StandardCharsets.UTF_8))) { String line; while ((line br.readLine()) ! null) { // 处理每一行 } } catch (IOException e) { e.printStackTrace(); }从 Java 11 开始FileReader也提供了接受Charset的构造函数可以简化为new FileReader(data.txt, StandardCharsets.UTF_8)。但如果你的项目还在 Java 8那就老老实实用InputStreamReader的写法。我个人的习惯是无论什么版本都显式指定编码因为“平台默认”这个东西在团队协作和部署时就是个定时炸弹。3.3 缓冲区大小的选择默认 8192 够不够用BufferedReader提供了带缓冲区大小参数的构造函数BufferedReader br new BufferedReader(reader, 16384);那到底该用多大默认的 8192 字符对于大多数场景已经足够了。缓冲区太小比如 128会导致频繁调用底层流的read失去缓冲的意义缓冲区太大比如 1MB会占用过多内存而且在读取小文件时反而浪费。一般来说8192 到 65536 之间是比较合理的范围。有一个经验性的判断方法如果你的应用需要同时打开大量BufferedReader比如并发处理上千个文件那就用默认值或者更小避免内存膨胀如果是单线程处理大文件可以适当调大到 32768 或 65536减少底层读取次数。但说实话在绝大多数业务场景下默认值和你手动调优的差距小到可以忽略除非你做过 profiling 发现这里确实是瓶颈。3.4 嵌套流的关闭顺序谁先谁后用 try-with-resources 的时候多个资源可以写在一个 try 里关闭顺序是声明的逆序try (FileInputStream fis new FileInputStream(data.txt); InputStreamReader isr new InputStreamReader(fis, StandardCharsets.UTF_8); BufferedReader br new BufferedReader(isr)) { // 使用 br }关闭时会先关br再关isr最后关fis。这个顺序是对的因为br.close()内部会调用isr.close()而isr.close()又会调用fis.close()。实际上你只写最外层的br也能正确关闭所有底层流因为BufferedReader的close()方法会级联调用被包装流的close()。但显式写出所有资源更清晰也避免了某些特殊流不级联关闭的隐患。注意如果你手动管理资源而不用 try-with-resources一定要在finally块里关闭并且要处理close()本身可能抛出的IOException。我见过太多代码在finally里直接br.close()不捕获异常导致编译不过或者异常被吞掉。4. 进阶技巧与性能优化实战4.1 用 mark() 和 reset() 做回溯读取BufferedReader支持标记和重置这在需要“看一眼后面的内容再决定怎么处理”的场景下很有用try (BufferedReader br new BufferedReader(new FileReader(data.txt))) { br.mark(1024); // 标记当前位置参数表示后续最多能读多少个字符还能 reset String firstLine br.readLine(); if (firstLine ! null firstLine.startsWith(#)) { // 是注释行跳过 } else { br.reset(); // 回到标记位置重新读 firstLine br.readLine(); } }mark(int readAheadLimit)的参数表示在标记失效之前最多可以读取的字符数。如果超过这个限制还没有调用reset()reset()会抛IOException。默认的readAheadLimit如果不够大缓冲区会扩容来容纳但扩容有上限。实际使用中如果你不确定要回溯多远给一个足够大的值比如 8192 或更大但别给Integer.MAX_VALUE那会导致缓冲区无限增长。4.2 用 lines() 方法配合 Stream 做函数式处理Java 8 给BufferedReader加了lines()方法返回一个StreamString可以直接用 Stream API 处理try (BufferedReader br new BufferedReader( new InputStreamReader(new FileInputStream(data.txt), StandardCharsets.UTF_8))) { long count br.lines() .filter(line - !line.isBlank()) .filter(line - !line.startsWith(#)) .count(); System.out.println(有效行数: count); }这个写法很简洁但有个坑lines()返回的 Stream 必须在BufferedReader关闭之前消费完。如果你把 Stream 返回出去在 try 块外面用流已经关了会抛UncheckedIOException。另外lines()底层还是用的readLine()所以性能特征和手动循环差不多不会因为用了 Stream 就变快。4.3 大文件读取的内存控制用readLine()读大文件时内存占用主要取决于单行的最大长度。如果文件里有一行特别长比如一个没有换行的超大 JSONreadLine()会一直往StringBuilder里拼直到遇到换行或流结束这可能导致内存溢出。处理这种文件时可以考虑用read()配合固定大小的char[]手动分块读取或者用Scanner配合自定义分隔符。但更常见的做法是如果知道文件里可能有超长行先做一次预处理把超长行截断或者拆分。我在处理日志文件时遇到过单行几十兆的情况最后是用read(char[] cbuf, int off, int len)手动控制每次读取的字符数来解决的。4.4 性能对比BufferedReader vs 其他读取方式读取方式10MB 文本文件耗时参考值适用场景FileReader 逐字符 read()约 8000ms几乎不用仅作对比BufferedReader 默认缓冲约 120ms通用文本读取BufferedReader 32KB 缓冲约 110ms大文件单线程读取Files.readAllLines()约 150ms小文件一次性读入内存Files.lines() Stream约 130ms函数式处理需注意流关闭这个表格里的数字是基于我本地环境SSD、JDK 17的粗略测试不同机器会有差异但数量级关系是稳定的。可以看到BufferedReader相比无缓冲的逐字符读取有几十倍的提升而调整缓冲区大小带来的边际收益很小。Files.readAllLines()适合小文件因为它一次性把所有行读进ListString文件大了会吃内存。5. 常见问题与排查技巧实录5.1 中文乱码编码不匹配的典型表现乱码是BufferedReader使用中最常见的问题。表现是读出来的中文变成“锟斤拷”或者“测试”这样的字符。根本原因就是写入文件时用的编码和读取时用的编码不一致。排查步骤很简单先用十六进制工具看一下文件开头的字节判断实际编码。UTF-8 的中文通常以E4到E9开头GBK 的中文以B0到F7开头。然后确保读取时用对应的Charset。如果文件是别人给的且编码未知可以尝试用juniversalchardet这类库做编码探测但最稳妥的还是从源头统一用 UTF-8。实操心得我习惯在项目里定义一个常量StandardCharsets.UTF_8所有涉及文本读写的地方都显式引用它绝不依赖平台默认编码。这个习惯帮我省掉了至少几十次跨平台部署时的乱码排查。5.2 readLine() 返回 null 的两种情况readLine()返回null只有一种情况流已经读到末尾了。但很多人会把它和“读到了空行”搞混。空行返回的是空字符串不是null。所以判断循环结束时必须用! null不能用!line.isEmpty()否则遇到空行就会提前退出。另一个容易混淆的是如果文件最后一行没有换行符readLine()仍然会返回那一行的内容下一次调用才返回null。这个行为是符合预期的但如果你在做行数统计要注意最后一行没有换行符的情况。5.3 流未关闭导致的资源泄漏忘记关闭BufferedReader会导致文件句柄泄漏在 Linux 上表现为“Too many open files”错误。用 try-with-resources 可以彻底避免这个问题。但如果你的代码结构比较复杂比如在循环里打开流一定要确保每次迭代都正确关闭。有一个隐蔽的场景在 try 块里 return 或者抛异常try-with-resources 仍然会关闭资源这是它比手动 finally 更安全的地方。我见过有人在 finally 里关闭流但 finally 里又抛了异常把原始异常覆盖了导致排查困难。try-with-resources 会保留原始异常把关闭时的异常作为 suppressed 异常附加信息更完整。5.4 常见问题速查表问题现象可能原因解决方法中文乱码读写编码不一致显式指定 Charset统一用 UTF-8读到空行就退出用 isEmpty() 判断结束改用 ! null 判断reset() 抛 IOExceptionmark 后读取超过 readAheadLimit增大 mark 参数或重新设计逻辑文件句柄泄漏未关闭流使用 try-with-resources大文件 OOM单行过长或一次性读入内存分块读取或预处理截断超长行lines() 抛 UncheckedIOExceptionStream 在流关闭后消费确保在 try 块内消费完 Stream5.5 一个容易忽略的坑BufferedReader 包装 System.in用BufferedReader包装System.in做控制台输入是常见操作BufferedReader br new BufferedReader(new InputStreamReader(System.in)); String input br.readLine();这里有个坑System.in是字节流InputStreamReader默认用平台编码转换。在 Windows 控制台默认 GBK 的环境下如果用户输入了 UTF-8 字符可能会乱码。解决办法是显式指定编码或者用Console类Java 6来读取控制台输入它会自动处理编码问题。但Console在 IDE 里运行可能返回null所以实际项目中还是BufferedReader更通用。6. 写在最后的一些个人习惯用了这么多年BufferedReader我总结下来最核心的就三条第一永远显式指定字符编码别信平台默认第二永远用 try-with-resources别手动关流第三读大文件时留意单行长度别让readLine()把内存吃爆。这三条看起来简单但每一条背后都是真实踩过的坑。另外分享一个小技巧如果你需要同时读多个文件并且做行级别的合并处理可以给每个文件创建一个BufferedReader然后用一个ListBufferedReader管理每次从每个流里读一行做处理。这种模式在处理分片日志或者多路输入时很好用但要注意所有流都要正确关闭最好用 try-with-resources 把它们都声明在一起。BufferedReader这个类本身不复杂但它的使用场景太广了几乎每个 Java 项目都会用到。把它的缓冲机制、编码处理、异常和资源管理这几个点吃透以后遇到任何文本读取的需求都能心里有底。