BufferedReader 默认缓冲区大小是8192字节;该值可按需显式调整,但需权衡内存与性能;readLine()因批量扫描复用内部缓冲区而远快于逐字节read();close()会递归关闭底层InputStream,但嵌套BufferedInputStream时需额外处理。
默认是 8192 字节(即 8KB),由 BufferedReader(InputStreamReader) 构造

super(in, 8192) 设定。这个值在多数场景下够用,但并非最优——比如读取超大日志文件或网络响应流时,频繁触发底层 read() 系统调用仍会造成性能瓶颈。
实操建议:
new BufferedReader(new InputStreamReader(inputStream), 65536)
OutOfMemoryError
readLine() 和 read(char[]),对 ready() 或 mark()/reset() 无加速作用根本区别不在“是否缓冲”,而在于 readLine() 复用了内部 char[] cb 缓冲区做批量扫描,避免反复创建临时字符串和频繁调用底层 InputStream.read();而裸调 read() 每次只取一个 int,Java 层几乎不做聚合。
常见错误现象:
while ((c = reader.read()) != -1) 读文本 → CPU 使用率飙升,吞吐量可能只有 readLine() 的 1/10read() 仍走单字节路径,仅比 FileInputStream.read() 略快(因多了一层 char 数组中转)正确姿势:
readLine()
read(char[] cbuf, int off, int len) 批量填充数组,再手动解析会,但仅限于你没额外包装其他流。BufferedReader.close() 会递归调用其 Reader 成员的 close(),而 InputStreamReader.close() 又会关闭持有的 InputStream。
容易踩的坑:
BufferedInputStream:例如 new BufferedReader(new InputStreamReader(new BufferedInputStream(is)))→ 关闭
BufferedReader 不会关掉最外层 BufferedInputStream,必须确保它也被关闭(或改用 Files.newBufferedReader(Paths.get(...)) 自动管理)BufferedReader),但前提是构造链中没有跳过 close 的自定义 ReaderInputStream,此时显式关闭反而导致后续读取失败 —— 这类场景应避免封装成 BufferedReader,或确认容器生命周期纯 NIO(如 FileChannel + ByteBuffer)本身已具备高效缓冲能力,此时再套 BufferedReader 反而引入额外对象开销和字符编码转换延迟。但现实开发中,绝大多数文本解析逻辑仍基于 String 和行语义,直接操作 ByteBuffer 写法复杂、易出错。
权衡建议:
Files.lines(path)(返回 Stream,底层仍用 BufferedReader,但做了 lazy-split 和资源自动管理)BufferedReader,改用 CharsetDecoder + ByteBuffer 手动解码,但要注意换行符跨 buffer 边界的问题最常被忽略的一点:无论用哪种方式,只要涉及字符编码(尤其是 UTF-8),BufferedReader 的缓冲区大小必须能容纳至少一个完整多字节字符 —— 否则可能在中间截断 UTF-8 序列,导致 MalformedInputException。