BufferedReader默认缓冲区8KB够用但需按场景调整：小文件宜小、大文件顺序读可用16KB~64KB，建议对齐磁盘页大小（4KB/8KB/16KB）；readLine()因行解析开销在极端行长时可能比read()慢；必须确保底层流未被提前关闭，推荐用try-with-resources；NIO通道应避免直接套用BufferedReader，优先使用Channels.newReader或内存映射优化。
BufferedReader的缓冲区大小设多少才合适
默认8192字节（8KB）对多数场景够用，但不是万能解。小文件或高频短读取时，过大的缓冲区反而浪费内存；大文件顺序读取时，16KB~64KB常能降低系统调用次数。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
new BufferedReader(new FileReader(file), bufferSize)显式指定，比如new BufferedReader(reader, 32 * 1024) - 避免设成
1024或65536这类“看起来整”的数——磁盘页大小通常是4KB，缓冲区最好与其对齐（如 4KB、8KB、16KB） - 不要盲目堆大：JVM堆内分配大缓冲区会增加GC压力，尤其在多线程频繁创建BufferedReader时
readLine()为什么比read()快，但有时反而更慢
readLine() 是带缓冲的行解析，底层仍走 fill() 触发批量系统读；但它内部要扫描换行符、处理回车换行兼容（\r\n）、拷贝子串——这些开销在每行极短（如CSV单字段）或超长（如日志含base64）时会被放大。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 纯二进制或定长记录读取，直接用
read(char[] cbuf, int off, int len)避免行解析开销 - 已知行尾是
\n（如Linux日志），可关掉readLine()的兼容逻辑——但JDK没暴露该开关，此时改用InputStreamReader+read()更可控 - 注意
readLine()返回null表示流末尾，不是空行；空行返回空字符串""，别混淆
关闭BufferedReader前必须确保底层流也关闭吗
必须。虽然 BufferedReader.close() 会调用底层 Reader.close()，但前提是底层Reader没被提前关闭，且你没用装饰器链（如 new BufferedReader(new InputStreamReader(new FileInputStream(...)))）。
常见错误现象：
- 手动关了
FileInputStream，再调BufferedReader.close()→ 抛IOException: Stream closed - 用
try-with-resources时只声明了BufferedReader，但底层是InputStream——只要它实现了AutoCloseable，链式关闭没问题 - 多个BufferedReader包装同一个底层流 → 关一次后其余失效，且第二次close可能静默失败
安全做法：只对最外层装饰器调 close()，或统一用 try (BufferedReader br = new BufferedReader(...)) { ... }。
BufferedReader在NIO通道上怎么用才不拖慢性能
不能直接套用。BufferedReader是面向流（Reader）的，而NIO通道（FileChannel、SocketChannel）是面向缓冲区（ByteBuffer）的。强行桥接会多一层字符解码和拷贝。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
Channels.newReader(channel, charset)包装后再传给BufferedReader——但注意这仍是同步阻塞模式，没发挥NIO非阻塞优势 - 真要高性能，绕过BufferedReader：用
FileChannel.map()内存映射 +CharsetDecoder手动解码，或用AsynchronousFileChannel配合回调 - 如果只是想把NIO的
ByteBuffer当作输入源，先转成InputStream（如Channels.newInputStream(channel)），再套InputStreamReader和BufferedReader——但这是退化方案，吞吐通常不如原生NIO处理
真正影响性能的，往往不是BufferedReader本身，而是它前面那层字符集解码是否缓存了 CharsetDecoder，以及底层是否触发了真实磁盘I/O而非page cache命中。
