bufferedreader 缓冲区默认8kb，大文件或ssd场景建议64kb～256kb；readline()因逐字节扫描和动态扩容比read(char[],int,int)慢；应直连inputstream避免filereader双重缓冲；bufferedreader非线程安全，需多实例隔离。
BufferedReader 的缓冲区大小设多少才合适
默认 BufferedReader 使用 8192 字节（8KB）缓冲区，对小文件够用，但读大文件或 SSD 上的高频 IO 场景，这个值常成瓶颈。实测发现：在千兆网挂载的 NFS 或本地 NVMe 盘上，把缓冲区提到 64KB～256KB，readLine() 吞吐能提升 1.3～1.8 倍。
关键不是“越大越好”——JVM 堆内分配过大的缓冲数组会增加 GC 压力，尤其在多线程批量读场景下。建议按如下方式权衡：
- 普通日志解析（单行 ≤ 2KB）、磁盘 I/O 较慢：保持默认
8192或略调至16384 - 结构化文本（CSV/TSV）、SSD/NVMe、单行较短：用
65536（64KB） - 内存充足且单次读取量极大（如导出报表流），可试
262144（256KB），但需监控java.lang.OutOfMemoryError: Java heap space
readLine() 为什么比 read(char[], int, int) 慢一截
readLine() 内部做了额外工作：逐字节扫描 \n、\r\n，还要动态扩容 StringBuilder 存每行内容，每次调用都有对象创建和边界检查开销。而 read(char[], off, len) 是纯字节数组搬运，零分配、无解析。
如果你不需要“按行处理”，只是做流式清洗或二进制前缀检测，直接用后者更高效：
立即学习“Java免费学习笔记（深入）”；
char[] buf = new char[65536];
int n;
while ((n = reader.read(buf, 0, buf.length)) != -1) {
// 处理 buf[0] 到 buf[n-1]，不关心换行
}
注意：read(char[]) 不跳过 BOM，也不自动处理 Windows/Linux 行结束符差异，得自己判 buf[i] == '\r' 或 '\n'。
BufferedReader 套在 FileReader 上反而变慢？
常见错误是这样写：
new BufferedReader(new FileReader("data.txt"))
问题在于 FileReader 本身是基于 InputStreamReader + FileInputStream，它默认用平台编码（如 Windows-1252）解码，且内部还有自己的小缓冲（通常 1024 字节）。两层缓冲叠加，不仅浪费内存，还因编码转换时机错位导致部分字符被截断重解，触发额外系统调用。
正确做法是跳过 FileReader，直连字节流：
- 确定编码（如 UTF-8）→ 用
Files.newBufferedReader(Paths.get("data.txt"), StandardCharsets.UTF_8) - 需要复用
InputStream（如从 HTTP 响应体读）→new BufferedReader(new InputStreamReader(in, StandardCharsets.UTF_8))
这样编码解码只发生一次，缓冲区由 BufferedReader 统一管理，吞吐更稳。
多线程共用一个 BufferedReader 会出什么错
BufferedReader 不是线程安全的。多个线程同时调用 readLine()，可能造成：
- 同一行被两个线程分别读走一部分（
pos和readAheadLimit状态错乱） - 缓冲区数组被并发修改，抛
ArrayIndexOutOfBoundsException或静默丢数据 - 内部
cb（字符缓冲数组）被覆盖，后续读到乱码
别试图加锁包装——锁粒度难控，性能反不如每个线程独占一个实例。真实场景中，更推荐：
- 用
Files.lines(Paths.get(...), StandardCharsets.UTF_8)得到并行 Stream（底层自动分块） - 若必须手动分片，按字节偏移切分文件，每个线程构造独立
BufferedReader（配合RandomAccessFile定位）
缓冲区大小、编码绑定、线程隔离——这三点漏掉任一，都可能让本想优化的读取变成性能陷阱。
