高频小文件读取时应将bufferedreader缓冲区调小至1kb～4kb，推荐4092字节以对齐磁盘页并平衡gc压力；必须配合try-with-resources管控生命周期，并显式指定字符集避免乱码。
高频小文件读取时，BufferedReader 的默认 8KB 缓冲区反而可能拖慢性能——因为每次打开文件都要分配并初始化这块内存，而小文件往往几 KB 就读完了，大缓冲区既用不上，又增加 GC 压力。
缓冲区大小应调小，推荐 1KB～4KB
小文件（如配置项、JSON 片段、日志条目）通常单次读取就能完成，过大的缓冲区只是空占堆内存。实测表明，对平均大小在 1–5KB 的文件，设为 1024（1KB）、2048 或 4096（4KB）比默认 8192 更快，尤其在每秒打开几十个文件的场景下。
- 用 4096（4KB） 是较优选择：它对齐常见磁盘页大小，且足够容纳多数小文本行
- 避免设为 1024 这类“整千数”——JVM 数组分配更倾向对齐内存页，4096 比 1024 更易被高效管理
- 不要低于 512：太小会导致频繁 fill() 调用，抵消缓冲收益
必须配合 try-with-resources 复用生命周期
高频意味着频繁创建/关闭 BufferedReader 实例。若不严格管控资源，容易触发短生命周期对象激增，加重 GC 频率。
- 始终用 try (BufferedReader br = new BufferedReader(reader, 4096)) { ... }，让 close() 自动触发，避免手动 close 失误
- 不要在循环内重复 new FileReader → InputStreamReader → BufferedReader 链——可提前构建好 Reader 链再传入
- 若需反复读同一组小文件，考虑缓存 BufferedReader 实例（注意线程安全），但需确保底层流未关闭
优先用 readLine()，但避免空行或超短行开销
小文件常含大量空行或单字段行（如 key=value），此时 readLine() 内部的换行符扫描和字符串拷贝会成为瓶颈。
- 对纯键值对类文本（每行一个等号），可改用 read(char[] buf, 0, buf.length) 批量读取后手动解析，跳过行边界处理
- 若已知行尾统一为 \n（如容器内日志），无需兼容 \r\n，此时 readLine() 开销可控；若混用 Windows/Linux 换行，保留默认逻辑即可
- 空行返回 ""，不是 null，判断时别写成
line == null导致逻辑跳过
编码必须显式指定，否则乱码会伪装成“读取失败”
小文件内容少，一旦编码错误（如用平台默认 GBK 读 UTF-8 文件），可能首字节就解码失败，导致 readLine() 提前返回 null 或抛异常，被误判为文件结束。
- 构造时务必传入字符集：new InputStreamReader(new FileInputStream(f), StandardCharsets.UTF_8)
- 避免使用 FileReader —— 它隐式依赖系统默认编码，不可控
- 若源文件编码不确定，先用 Apache Tika 或 juniversalchardet 探测，再构建 Reader 链
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
