Java中BufferedReader与BufferedWriter使用解析

本文深入剖析了Java中BufferedReader与BufferedWriter的核心价值与实战陷阱：它们并非简单“套层流”，而是通过内部缓冲机制显著减少底层I/O调用、提升性能；但必须显式指定字符编码（摒弃有平台依赖的FileReader，改用InputStreamReader+StandardCharsets）、主动管理刷新与关闭（强烈推荐try-with-resources确保flush和资源释放），并正确理解readLine()返回null仅表示EOF而非错误或空行；同时提醒开发者关注默认缓冲区大小限制及异常场景下的鲁棒性——如文件被意外截断时不能盲目信任null，需结合available()或长度校验增强容错能力。

Java里用 BufferedReader 和 BufferedWriter 的核心目的不是“多加一层流”，而是避免每次读写都触发底层I/O——它们靠内部字符数组缓存批量操作，性能提升明显，但必须手动管理关闭和换行细节。

为什么不能直接 new BufferedReader(new FileReader(...)) 而不考虑编码？

因为 FileReader 默认使用平台编码（Windows是GBK，Linux/macOS通常是UTF-8），一旦文件实际编码与之不匹配，readLine() 就会读出乱码甚至抛 MalformedInputException。正确做法是绕过 FileReader，用带编码的构造链：

BufferedReader reader = new BufferedReader(
    new InputStreamReader(new FileInputStream("data.txt"), StandardCharsets.UTF_8)
);

• 永远优先用 InputStreamReader + StandardCharsets 显式指定编码
• FileReader 仅适合读纯ASCII或明确知道平台编码的场景
• 如果文件来自网络或用户上传，编码几乎一定得由外部传入，不能硬编码

BufferedWriter.write() 后内容没写到文件？

缓冲区未刷新（flush）是常见原因——write() 只把数据塞进内部字符数组，不立即落盘。尤其在程序异常退出或未调用 close() 时，最后一段内容会丢失。

• 显式调用 flush() 确保缓冲区清空：writer.flush()
• close() 会自动调用 flush()，但仅限于正常执行到该语句；若中间抛异常，close() 可能不被执行
• 推荐用 try-with-resources，它保证无论是否异常都会调用 close()：

try (BufferedWriter writer = new BufferedWriter(
        new OutputStreamWriter(new FileOutputStream("out.txt"), StandardCharsets.UTF_8))) {
    writer.write("hello");
    writer.newLine(); // 注意：不是 \n，是平台相关换行符
}

readLine() 返回 null 是文件结束还是出错了？

readLine() 返回 null 仅代表已到达流末尾（EOF），不是错误。它不会抛异常来表示“读完了”，所以典型循环结构是：

String line;
while ((line = reader.readLine()) != null) {
    System.out.println(line);
}

• 如果 readLine() 抛异常（如 IOException），才是真实I/O问题，比如磁盘满、文件被占用
• null 不代表空行——空行返回的是空字符串 ""
• 注意：readLine() 自动剥离换行符（\r\n 或 \n），所以无法区分 Windows 和 Unix 换行风格

真正容易被忽略的是缓冲区大小和异常恢复能力：BufferedReader 默认8192字符，BufferedWriter 默认8192字节，对超大文本或高吞吐日志可能不够；而一旦底层流（如 FileInputStream）在读取中途被其他进程删除或截断，readLine() 可能静默返回 null 或抛异常——这时需要结合 available() 或文件长度校验做兜底，不能只信 null。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。