BufferedReader 比 FileReader 快的根本原因是减少系统调用次数：它用内存缓冲区（默认8192字节）批量读取，避免每次read()都触发磁盘I/O。
BufferedReader 为什么比 FileReader 快？
根本原因不是它“更聪明”，而是它**减少了系统调用次数**。FileReader 每次 read() 都可能触发一次底层 I/O（比如从磁盘读一个字节），而 BufferedReader 在构造时就申请一块内存缓冲区（默认 8192 字节），先一次性把数据“捞上来”存着，后续读取都从内存拿——内存访问比磁盘快几个数量级。
这就像去仓库搬货：FileReader 是每次只搬 1 箱；BufferedReader 是先派辆卡车拉一车回来堆在门口，你再慢慢从门口搬——省掉了反复跑路的开销。
如何正确设置缓冲区大小提升性能？
默认大小够用，但不万能。对大文件或高吞吐场景，手动调大缓冲区往往立竿见影，前提是别贪多占满堆内存。
-
BufferedReader构造器支持指定缓冲区大小：new BufferedReader(reader, 65536)（64KB）常用于日志批量解析 - 过小（如
1024）会导致频繁填缓冲区，抵消缓冲收益 - 过大（如 >1MB）可能引发 GC 压力，且单次 read 耗时变长，反而影响响应性
- 真实瓶颈不在缓冲区本身，而在数据源——如果文件在机械硬盘或网络挂载盘上，再大的缓冲区也救不了 IO 延迟
readLine() 看似方便，为何有时反而拖慢速度？
readLine() 内部要逐字符扫描换行符（\n、\r\n），遇到超长行或二进制混入时，会白耗 CPU 做无效匹配。它本质是“按行语义”封装，不是“按性能”设计。
立即学习“Java免费学习笔记（深入）”；
- 纯文本处理（如配置、CSV）用
readLine()安全又清晰 - 处理大日志或已知固定长度记录，改用
read(char[] cbuf)批量读更稳，避免行边界解析开销 - 千万别在循环里写
while (reader.readLine() != null)两次——第二次调用直接跳过一行，这是新手高频漏读 bug - 注意：空行返回
""，不是null；含空白的行不会被自动 trim
为什么 try-with-resources 不只是“好习惯”，而是必须？
没关 BufferedReader 不仅泄漏文件句柄（Linux 下最多打开 1024 个，很快报 IOException: Too many open files），更关键的是——**缓冲区里还没刷出去的数据会丢**。哪怕你已经调用过 readLine()，最后几 KB 可能还卡在内存缓冲区里。
正确写法只有一种：
try (BufferedReader reader = new BufferedReader(
new InputStreamReader(new FileInputStream("data.txt"), StandardCharsets.UTF_8))) {
String line;
while ((line = reader.readLine()) != null) {
// 处理
}
} catch (IOException e) {
// 异常处理
}
Java 8+ 的 Files.lines() 看似简洁，但它返回的 Stream 也必须显式关闭（或用 try-with-resources 包裹），否则底层 BufferedReader 同样不释放。
真正容易被忽略的，是编码问题：不显式传 StandardCharsets.UTF_8，在 Windows 上读 UTF-8 文件大概率中文变乱码——这不是效率问题，是功能失效。
