如何通过 BufferedReader 缓冲流优化大型文本按行读取效率？

本文共计756个文字，预计阅读时间需要4分钟。

核心是让 Buffe a+style=color:

显式指定 UTF-8 编码，杜绝乱码与隐式解码开销

不指定编码时，BufferedReader 会依赖平台默认 Charset（Windows 是 GBK，Linux/macOS 多为 UTF-8），不仅易导致中文乱码，还会在每次字符转换时多一层不确定的解码逻辑，拖慢吞吐。尤其大文件中频繁跨字节边界时，错误编码会引发额外异常处理或静默截断。

• ✅ 正确写法：用 Files.newBufferedReader(Paths.get("data.log"), StandardCharsets.UTF_8)
• ✅ 或手动构造：用 InputStreamReader 显式套 FileInputStream + UTF_8，再包 BufferedReader
• ❌ 避免：new FileReader("data.log") —— 它隐式使用平台默认编码，不可控

按场景调整缓冲区大小，避开默认 8KB 的“一刀切”

默认 8192 字节（约 8KB）是通用经验值，但对超长行（如单行 JSON、base64 内容、宽字段 CSV）容易触发多次缓冲填充，增加系统调用次数；而对高频小行（如每行仅几十字节的日志），又可能浪费内存且无实质收益。

• ✅ 行平均长度 > 2KB：可设为 65536（64KB），减少 fill() 调用频次，提升吞吐
• ✅ 实时性要求高（如监控流式输入）：保持默认或设为 4096，降低延迟敏感度
• ❌ 不要盲目设成 1MB+：堆内存占用陡增，GC 压力大，高并发下易 OOM

坚持用 readLine()，禁用逐字符/逐字节读取模式

BufferedReader 的性能优势几乎全部来自 readLine() 对内部 char[] cb 缓冲区的批量扫描能力。一旦改用 read() 或 read(char[]) 手动解析换行，就退化为“带一层 char 中转的 InputStream”，失去核心加速逻辑。

• ✅ 每次循环只调 reader.readLine()，判 null 即可终止
• ✅ 若需跳过空行或过滤，用 line != null && !line.trim().isEmpty()，别拆成 char 数组遍历
• ❌ 禁止：while ((c = reader.read()) != -1) —— CPU 使用率飙升，速度可能只有 readLine() 的 1/10

用 try-with-resources 确保资源及时释放，避免句柄泄漏

大文件读取常伴随长时间运行或高频启停，若未正确关闭，底层 FileInputStream 句柄会持续占用，系统级文件描述符耗尽后，后续任何 IO 都会失败（抛 IOException: Too many open files）。

• ✅ 写法：try (BufferedReader r = Files.newBufferedReader(...)) { ... }
• ✅ 关闭 BufferedReader 会自动递归关闭其包装的 InputStreamReader 和 FileInputStream
• ❌ 不要只关外层还手动关内层，也不要在 finally 块里重复 close（可能 NPE）