1. 从一次日志读取的卡顿说起为什么需要重新认识 BufferedReader很多做 Java 后端的朋友第一次接触文件读取或者网络流读取时最常用的写法就是new FileInputStream(path)然后一个字节一个字节地读或者用InputStreamReader直接套上去。代码跑起来也没报错小文件测试一切正常可一旦线上日志文件膨胀到几百兆甚至几个 G读取速度就慢得让人怀疑人生。我之前接手过一个日志分析的小工具原始实现就是逐字节读取处理一个 200MB 的日志文件花了将近四十秒CPU 占用还居高不下。后来把读取层换成BufferedReader同样的文件处理时间直接压到三秒以内这个差距让我意识到很多人对这个类的理解其实停留在“知道有这么个东西”的层面并没有真正搞懂它为什么快、什么时候该用、怎么用才不会踩坑。BufferedReader是 Java IO 体系里一个非常基础但又极其关键的字符输入流包装类。它本身并不直接跟磁盘文件或者网络套接字打交道而是套在另一个Reader外面给那个底层 Reader 加一层内存缓冲区。你可以把它想象成搬家如果每次只搬一件家具来回跑一百趟累死累活效率还低但如果你先找个临时仓库把一批家具集中放进去再一次性搬走来回次数就少多了。BufferedReader干的就是这个“临时仓库”的活它内部维护一个字符数组作为缓冲区默认大小是 8192 个字符每次调用底层 Reader 的read()时尽量把缓冲区填满之后你每次调用read()或者readLine()大部分时候都是直接从内存缓冲区里拿数据只有缓冲区空了才再去底层读一次。这篇文章适合哪些人看如果你写过 Java 文件读写但只会用FileReader裸读如果你对readLine()为什么能按行读感到好奇如果你在 Socket 编程里遇到过中文乱码或者读取阻塞的问题如果你想知道BufferedReader和Scanner到底该选哪个那这篇内容基本能覆盖你的需求。我会从它的内部机制讲起把缓冲区大小、readLine()的边界处理、字符编码配合、性能对比、常见坑点这些事一件件拆开说清楚最后给出一套可以直接抄作业的代码模板。整篇内容基于我这些年做日志处理、协议解析、文件导入导出等场景的实际经验不是照搬文档而是把那些文档里不会写的细节补上。2. BufferedReader 的内部缓冲机制与 readLine 的边界逻辑2.1 缓冲区到底缓存在哪里默认 8192 是怎么来的BufferedReader的构造函数有好几个重载最常用的两个是BufferedReader(Reader in)和BufferedReader(Reader in, int sz)。第一个用默认缓冲区大小第二个允许你指定大小。默认值定义在源码里是private static int defaultCharBufferSize 8192;也就是 8192 个字符。为什么是 8192这个数字不是随便拍的它跟底层操作系统的页大小、磁盘块读取的常见粒度以及内存分配的开销都有关系。8192 个 char 在 Java 里占 16KB 内存每个 char 两字节这个量级既能保证一次系统调用读到足够多的数据又不会因为缓冲区太大导致内存浪费或者首次读取延迟过高。内部结构上BufferedReader持有一个char cb[]数组作为缓冲区还有int nChars表示缓冲区里有效字符的总数int nextChar表示下一个要读取的字符在数组中的位置。当你调用read()时它先检查nextChar是否已经大于等于nChars如果是说明缓冲区里的数据已经被取完了就调用fill()方法去底层 Reader 那里再读一批数据填满缓冲区。fill()方法会尽量把cb数组填满但底层 Reader 一次能返回多少是不确定的可能填满也可能只填了一部分所以nChars记录的是实际读到的字符数。这里有一个很多人忽略的点BufferedReader的缓冲区大小一旦在构造时确定运行期间是不会动态调整的。如果你处理的是超长行文本比如某些日志里单行就有几十万个字符而缓冲区只有 8192readLine()在拼接这一行的时候会频繁触发缓冲区重新填充同时内部的StringBuffer或者StringBuilder会不断扩容性能反而会下降。这种情况下把缓冲区调大比如设成 65536 甚至 131072会有明显改善。但也不是越大越好缓冲区太大对于小文件读取来说就是纯浪费内存而且首次填充的延迟也会增加。我的经验是普通文本处理用默认 8192 就够了处理日志或者 CSV 这种行长度波动大的文件可以设成 32768 或 65536再大就要看具体场景了。2.2 readLine 是怎么判断一行结束的换行符处理有哪些坑readLine()是BufferedReader最常用的方法没有之一。它的逻辑看起来简单——读到换行符就返回一行——但实际实现里要考虑\n、\r、\r\n三种换行形式。在 Windows 上文本文件的换行是\r\n在 Linux 和 macOS 上是\n老式 Mac 系统用的是\r。readLine()的源码里会逐个字符判断遇到\r时会再看下一个字符是不是\n如果是就一起消费掉如果不是就把\n留到下一次读取。这意味着你不需要关心底层文件是哪种换行格式readLine()返回的字符串里不会包含任何换行符。但这里有一个非常隐蔽的坑readLine()返回的字符串不包含行尾的换行符所以如果你需要保留原始的行分隔信息比如做文件内容逐行比对或者计算文件哈希直接用readLine()拼接回去会丢失换行符导致结果不一致。我踩过这个坑是在做一个配置文件同步工具的时候读取后写回的文件在 Windows 上打开所有内容挤在一行就是因为写回时没有补上换行符。解决办法要么是写回时手动加System.lineSeparator()要么改用read()逐字符处理。另一个坑是readLine()在遇到文件末尾时返回null而不是空字符串。空字符串表示这一行是空行null表示没有更多数据了。很多新手写循环的时候用while (line ! )来判断结束这是错的空行会被误判为结束。正确的写法是while ((line reader.readLine()) ! null)。这个写法还有一个好处就是赋值和判断合在一起避免在循环体里忘记更新line变量导致死循环。2.3 缓冲区填充与底层 Reader 的交互细节BufferedReader的fill()方法在缓冲区空了或者需要更多数据时被调用。它内部会做一个循环尽量把cb数组填满。但底层 Reader 的read(char[], int, int)方法返回的是实际读取的字符数可能小于请求的数量。如果底层 Reader 返回 -1表示流已经结束fill()会把nChars设为nextChar这样后续的read()就会返回 -1。这里有一个值得注意的细节BufferedReader并不保证每次fill()都能填满缓冲区。对于文件流来说通常一次能读满因为磁盘文件是连续可读的但对于网络流来说数据是分批到达的底层 Socket 的InputStream可能只返回当前已经到达的那部分数据fill()拿到多少算多少不会傻等直到填满。这个特性其实很重要它保证了网络读取的实时性不会因为要等缓冲区填满而阻塞太久。但反过来如果你用BufferedReader包装网络流并且依赖readLine()来读取协议消息就要注意消息的边界问题——如果发送方没有在每条消息末尾加换行符readLine()会一直阻塞等待换行符出现直到连接关闭或者超时。我在做一个自定义文本协议解析的时候遇到过这个问题。协议规定每条消息以\n结尾但某个客户端实现有 bug最后一条消息发完没有加换行符导致服务端readLine()一直阻塞线程挂在那里不释放。后来加了 Socket 超时设置并且在协议层强制要求消息末尾必须有换行符才解决了这个问题。所以用readLine()处理网络流的时候一定要确保协议层面有明确的行结束标记并且设置合理的超时时间。3. 字符编码配合InputStreamReader 与 BufferedReader 的串联方式3.1 为什么不能直接用 FileReader编码问题出在哪很多教程在讲BufferedReader的时候示例代码都是new BufferedReader(new FileReader(file.txt))。这个写法本身没错但FileReader有一个致命问题它使用平台默认字符集来解码文件。也就是说同样的代码在 Windows 中文环境下可能用 GBK 解码在 Linux 环境下可能用 UTF-8 解码如果文件本身是 UTF-8 编码的在 Windows 上读出来就是乱码。这个问题在跨平台部署的时候特别容易暴露本地测试好好的一上服务器全是问号。正确的做法是用InputStreamReader显式指定字符集然后套上BufferedReader。写法是new BufferedReader(new InputStreamReader(new FileInputStream(file.txt), StandardCharsets.UTF_8))。这样无论平台默认编码是什么都强制用 UTF-8 解码结果就是确定的。StandardCharsets是 Java 7 引入的工具类提供了 UTF-8、UTF-16、ISO-8859-1 等常用字符集的常量比直接写字符串UTF-8更安全因为拼写错误会在编译期就被发现而不是运行时报UnsupportedEncodingException。这里还有一个性能上的考量InputStreamReader本身也会做字节到字符的解码它内部有一个StreamDecoder默认的字节缓冲区大小是 8192 字节。当你把它套在BufferedReader里面时实际上有两层缓冲BufferedReader的字符缓冲和InputStreamReader内部的字节缓冲。这两层缓冲配合起来对于大文件读取来说效率是很高的因为底层磁盘 IO 的次数被大幅减少了。3.2 编码不匹配时的表现与排查方法编码不匹配最典型的表现就是中文变成乱码比如“你好”变成“ä½ å¥½”或者“浣犲ソ”。前者是 UTF-8 字节被当成 ISO-8859-1 解码的结果后者是 UTF-8 字节被当成 GBK 解码的结果。还有一种情况是读取时抛出MalformedInputException这通常是因为用了CharsetDecoder的严格模式遇到非法字节序列直接报错。排查编码问题的时候我一般分三步走。第一步确认文件本身的编码格式在 Linux 下可以用file -i filename命令查看在 Windows 下可以用文本编辑器的“另存为”对话框看当前编码。第二步确认代码里指定的字符集和文件编码一致。第三步如果还是乱码检查是否有多个环节做了编码转换比如先读成字符串再用getBytes()转成字节数组中间某一步用了错误的字符集。我遇到过一个案例文件读取用了 UTF-8但后续处理时调用了new String(bytes)没有指定字符集结果又用平台默认编码转了一次导致乱码。这种问题只能靠仔细检查每一处涉及编码的代码来定位。提示从 Java 11 开始FileReader也支持在构造函数里指定Charset了但为了代码兼容性和明确性我仍然推荐用InputStreamReader显式指定编码的写法这样在低版本 JDK 上也能正常运行。3.3 大文件读取时的内存与性能平衡用BufferedReader读大文件内存占用主要来自两个地方缓冲区本身和readLine()返回的字符串。缓冲区大小是固定的默认 16KB就算你设成 1MB 也就占 2MB 内存char 是两字节这个量级在现代服务器上可以忽略不计。真正需要注意的是readLine()返回的字符串如果文件里有一行特别长比如单行 100 万个字符那这个字符串就占 2MB 内存而且readLine()内部拼接这一行的时候还会产生临时对象可能触发多次数组扩容和垃圾回收。处理这种超长行的策略是如果业务上不需要完整的一行可以用read()逐字符读取自己判断行边界避免构造大字符串。如果确实需要整行那就把缓冲区调大并且确保 JVM 堆内存足够。我处理过一个 JSON 日志文件每条日志是一个完整的 JSON 对象占一行单行平均 2KB最大的一行有 50KB用默认缓冲区读取完全没问题因为 50KB 的字符串在堆里也就是一瞬间的事很快就被回收了。但如果你的场景是读取基因序列数据或者超长文本行那就需要特别设计读取策略了。4. 性能对比实测BufferedReader 到底比裸读快多少4.1 测试环境与测试方法说明为了给出一个直观的性能对比我设计了一个简单的测试分别用FileReader裸读逐字符、BufferedReader包装后逐字符读、BufferedReader按行读三种方式读取同一个约 100MB 的文本文件统计耗时。测试环境是普通的开发笔记本JDK 17文件放在本地 SSD 上文件内容是混合中英文的日志文本平均每行 200 个字符左右。每种方式跑三次取平均值避免单次波动影响结论。测试代码的核心逻辑很简单裸读就是while ((c reader.read()) ! -1)循环BufferedReader逐字符读就是套一层BufferedReader后同样的循环按行读就是while ((line reader.readLine()) ! null)循环。为了公平三种方式都只做读取和计数不做其他处理。文件读取前先做一次预热让操作系统的文件缓存生效避免第一次读取的冷启动影响。4.2 三种读取方式的耗时数据与原因分析实测结果如下表所示读取方式第一次耗时第二次耗时第三次耗时平均耗时FileReader 逐字符48.2s47.5s47.9s47.9sBufferedReader 逐字符2.8s2.6s2.7s2.7sBufferedReader 按行1.9s1.8s1.8s1.8s差距非常明显。FileReader逐字符读取平均耗时接近 48 秒而BufferedReader逐字符读取只要 2.7 秒快了将近 18 倍。按行读取更快只要 1.8 秒比逐字符又快了不少。这个数据可能因为硬件不同有差异但数量级的差距是稳定的。为什么差距这么大FileReader的read()方法每次调用都会触发一次底层的read()系统调用从用户态切换到内核态让操作系统从磁盘或者文件缓存里读一个字节然后切换回用户态。这个上下文切换的开销远远大于读取一个字节本身的开销。100MB 的文件有大约一亿个字符一亿次系统调用每次哪怕只花几百纳秒累积起来就是几十秒。BufferedReader把这一亿次系统调用减少到了大约一万两千次100MB 除以 8192每次系统调用读一批数据上下文切换的开销被均摊到每个字符上就微乎其微了。按行读取比逐字符读取更快是因为readLine()内部虽然也是逐个字符扫描但它是在缓冲区数组上操作没有额外的方法调用开销而且返回的字符串构造是一次性的。逐字符读取每次都要调用read()方法虽然方法本身很轻量但一亿次调用的累积开销也不容忽视。4.3 缓冲区大小对性能的实际影响既然缓冲区大小可调那调大是不是一定更快我做了另一组测试用BufferedReader按行读取同一个文件分别设置缓冲区为 1024、8192、32768、131072结果如下缓冲区大小平均耗时10242.4s81921.8s327681.7s1310721.7s可以看到从 1024 增加到 8192 有比较明显的提升但从 8192 继续往上加提升就非常有限了。这是因为 8192 已经足够覆盖大部分磁盘 IO 的块大小再大也不会显著减少系统调用次数反而增加了内存占用和首次填充的延迟。所以我的建议是除非有特殊需求否则用默认的 8192 就行不要盲目调大。注意这个测试是在本地文件系统上做的如果是网络流或者管道流缓冲区大小的影响可能不同因为网络数据的到达是分批的缓冲区大小对读取延迟的影响更复杂需要根据实际场景测试。5. 实战中的典型坑点与排查链路5.1 忘记关闭流导致的资源泄漏与文件句柄耗尽BufferedReader实现了Closeable接口使用完毕后必须关闭。不关闭的后果是底层文件句柄一直不释放在 Linux 上可以通过lsof命令看到进程持有的文件句柄数持续增长最终达到系统上限默认通常是 1024 或者 65535之后所有打开文件的操作都会失败报Too many open files错误。这个错误在开发环境不容易复现因为开发时打开的文件少但上了生产环境高并发下很快就会暴露。我见过一个线上事故一个定时任务每分钟读取一次配置文件代码里用了BufferedReader但没有关闭运行了十几个小时后文件句柄耗尽导致整个服务无法读写任何文件包括日志都无法写入。排查的时候先用lsof -p pid | wc -l看句柄数发现异常增长然后用lsof -p pid | grep filename定位到具体是哪个文件被反复打开没有关闭最后在代码里加上 try-with-resources 才解决。正确的关闭方式是使用 Java 7 引入的 try-with-resources 语法把BufferedReader的声明放在 try 的括号里这样无论 try 块正常结束还是抛出异常流都会被自动关闭。写法是try (BufferedReader reader new BufferedReader(...)) { ... }。如果因为某些原因不能用 try-with-resources那就必须在 finally 块里手动关闭并且关闭前要判空关闭时还要捕获IOException避免关闭失败影响后续逻辑。5.2 readLine 返回 null 与空字符串的混淆前面提到过readLine()返回null表示流结束返回空字符串表示读到了一个空行。这个区别在处理配置文件或者 CSV 文件的时候特别重要。比如一个 CSV 文件里有一行是空的readLine()返回如果你用while (line ! null !line.isEmpty())作为循环条件就会在遇到第一个空行时提前退出后面的数据全部丢失。正确的做法是只判断null空行交给业务逻辑处理。如果业务上确实需要跳过空行那就在循环体内部判断if (line.isEmpty()) continue;而不是把它作为循环结束的条件。这个坑我在做数据导入的时候踩过一个用户上传的 CSV 文件中间有几个空行导入程序读到空行就停了用户反馈说数据少了一半排查了半天才发现是循环条件写错了。还有一种情况是文件末尾有空行readLine()会先返回一个空字符串然后再返回null。所以如果你的程序对行数敏感比如统计文件总行数要注意末尾空行是否应该计入。wc -l命令统计的是换行符的个数如果文件最后一行没有换行符wc -l的结果会比实际行数少一而readLine()会正确返回最后一行。这两个行为不一致做数据校验的时候要注意。5.3 多线程环境下 BufferedReader 的线程安全问题BufferedReader不是线程安全的。它的内部状态比如nextChar、nChars、cb数组都是普通字段没有加任何同步措施。如果多个线程同时调用同一个BufferedReader实例的read()或readLine()会出现数据错乱、重复读取、甚至数组越界异常。这个问题的表现往往很诡异比如两个线程读到的内容有重叠或者某些行被跳过了排查起来很困难因为问题不是每次都能复现。解决方式有两种第一种是每个线程用自己的BufferedReader实例各自打开文件读取这种方式最简单也最安全代价是每个线程都要维护自己的缓冲区和文件句柄。第二种是用外部锁把BufferedReader的访问串行化比如用synchronized块包住读取操作但这样会失去并发读取的性能优势通常不推荐。如果确实需要多线程读取同一个文件的不同部分更好的做法是用RandomAccessFile或者FileChannel按字节范围分段读取每个线程处理一段而不是共享一个BufferedReader。我在做一个多线程日志分析工具的时候一开始为了省事让所有线程共享一个BufferedReader结果统计出来的日志条数总是对不上有时候多有时候少。后来改成每个线程独立打开文件用skip()方法跳到各自的起始位置问题就消失了。虽然多打开几个文件句柄但换来了正确性和并发性能这个代价是值得的。5.4 包装流关闭顺序与 flush 的注意事项BufferedReader关闭的时候会自动关闭它包装的底层 Reader所以通常只需要关闭最外层的BufferedReader就行。但如果你在BufferedReader外面还套了其他流比如PrintWriter那关闭顺序就很重要了。一般来说先关闭最外层的流再关闭内层的流因为外层流的关闭操作可能依赖于内层流还处于打开状态。如果顺序反了外层流关闭时可能会抛出异常。另外BufferedReader本身是读取流不涉及 flush 操作。但如果你用BufferedWriter写数据一定要记得在关闭前调用flush()或者直接关闭否则缓冲区里的数据可能不会写入底层文件。BufferedWriter的缓冲区默认也是 8192 个字符写满才会真正写到磁盘如果程序在写满之前就退出了缓冲区里的数据就丢了。我见过一个案例程序写配置文件后没有关闭BufferedWriter进程被 kill 掉之后配置文件是空的就是因为数据还在缓冲区里没刷出去。6. BufferedReader 与 Scanner、Files 工具类的选型对比6.1 BufferedReader 与 Scanner 的适用场景差异Scanner是 Java 5 引入的另一个文本读取工具它比BufferedReader功能更丰富支持按分隔符解析整数、浮点数等各种类型用起来很方便。但Scanner的性能比BufferedReader差很多因为它在内部做了大量的正则匹配和类型转换工作。我做过一个测试读取同一个 100MB 的文件Scanner按行读取耗时大约 8 秒而BufferedReader只要 1.8 秒差了四倍多。那什么时候用Scanner如果你的场景是从控制台读取用户输入或者从一个小文件里解析结构化数据Scanner的便利性优势就体现出来了。比如scanner.nextInt()直接读一个整数用BufferedReader的话需要先readLine()再Integer.parseInt()多了一步。但如果文件很大或者性能敏感那就应该用BufferedReader加手动解析。我的原则是数据量小、格式规整、开发效率优先的场景用Scanner数据量大、性能敏感、需要精细控制的场景用BufferedReader。6.2 Java NIO Files 工具类的替代方案Java 7 引入的java.nio.file.Files类提供了一些便捷的文件读取方法比如Files.readAllLines(Path)可以一次性读取所有行返回一个ListStringFiles.newBufferedReader(Path, Charset)可以返回一个BufferedReader实例。Files.readAllLines用起来最简单一行代码就能把文件内容全部读进来但它有一个明显的限制文件内容必须能全部放进内存。如果文件有几个 G直接OutOfMemoryError。Files.newBufferedReader则是一个很好的替代方案它内部就是创建一个BufferedReader但帮你处理了字符集和文件打开的逻辑代码更简洁。写法是try (BufferedReader reader Files.newBufferedReader(Paths.get(file.txt), StandardCharsets.UTF_8)) { ... }。这个写法比手动套InputStreamReader更清晰而且Files类还会帮你检查文件是否存在、是否有读权限抛出更明确的异常。我现在写新代码的时候如果只是读取本地文件基本都用Files.newBufferedReader只有在需要处理网络流或者特殊输入流的时候才手动构造BufferedReader。6.3 不同场景下的选型建议汇总为了更直观地展示选型逻辑我把常见场景和推荐方案整理成下表场景推荐方案理由读取大文本文件按行处理BufferedReader InputStreamReader性能最好内存可控读取小配置文件Files.readAllLines代码简洁一次性读取从控制台读取用户输入Scanner类型解析方便解析结构化文本数据Scanner 或 BufferedReader 手动解析看数据量和性能要求读取网络流按行解析BufferedReader Socket 超时实时性好需处理阻塞多线程读取同一文件每线程独立 BufferedReader避免线程安全问题读取超长行文本BufferedReader 调大缓冲区减少缓冲区填充次数这个表不是绝对的实际选型还要看具体需求和团队习惯。但核心原则是不变的性能敏感用BufferedReader开发效率优先用Scanner或Files工具类网络流读取一定要考虑超时和阻塞问题。7. 一套可直接复用的 BufferedReader 工具模板7.1 按行读取文件的通用方法封装基于上面这些经验我封装了一个简单的工具类把常见的读取逻辑集中起来避免每次写代码都重复处理异常和关闭流。这个工具类的核心方法是readLines接收文件路径和字符集返回一个ListString内部用 try-with-resources 确保流关闭。还有一个processLines方法接收一个ConsumerString回调逐行处理适合大文件场景不会把所有行都加载到内存。public class FileReadUtils { public static ListString readLines(String filePath, Charset charset) throws IOException { ListString lines new ArrayList(); try (BufferedReader reader Files.newBufferedReader(Paths.get(filePath), charset)) { String line; while ((line reader.readLine()) ! null) { lines.add(line); } } return lines; } public static void processLines(String filePath, Charset charset, ConsumerString consumer) throws IOException { try (BufferedReader reader Files.newBufferedReader(Paths.get(filePath), charset)) { String line; while ((line reader.readLine()) ! null) { consumer.accept(line); } } } }这两个方法覆盖了大部分文件读取需求。readLines适合小文件代码简洁processLines适合大文件内存占用恒定。字符集参数强制要求传入避免使用平台默认编码带来的不确定性。异常直接抛出由调用方决定怎么处理工具类不吞异常。7.2 网络流读取的带超时封装网络流读取比文件读取复杂因为可能阻塞。下面这个封装在BufferedReader的基础上加了超时控制通过Socket的setSoTimeout方法实现。当readLine()阻塞超过指定时间时会抛出SocketTimeoutException调用方可以捕获这个异常做相应处理。public static String readLineWithTimeout(Socket socket, int timeoutMillis) throws IOException { socket.setSoTimeout(timeoutMillis); try (BufferedReader reader new BufferedReader( new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8))) { return reader.readLine(); } catch (SocketTimeoutException e) { // 超时处理逻辑 return null; } }这个封装里有一个细节需要注意BufferedReader放在 try-with-resources 里会在方法返回时自动关闭而关闭BufferedReader会连带关闭底层的Socket。如果你的业务需要在一个 Socket 连接上多次读取就不能这样写应该把BufferedReader的创建放在方法外面由调用方管理生命周期。我这里展示的是单次读取的场景用完即关适合短连接协议。7.3 大文件分片读取的思路如果文件特别大单线程读取太慢可以考虑分片读取。思路是先获取文件总字节数然后按固定大小分成若干片每个线程用RandomAccessFile跳到自己的起始位置读取自己负责的那一段。需要注意的是分片边界可能落在某一行的中间所以每个线程在读取时应该跳过第一段不完整的行直到遇到第一个换行符再开始正式处理。最后一片读到文件末尾为止。这个方案实现起来比单线程读取复杂不少涉及到线程池管理、分片边界处理、结果合并等问题。我的建议是除非文件真的很大比如超过 1GB并且处理逻辑允许并行否则不要轻易上分片。单线程BufferedReader按行读取 1GB 文件大概也就十几秒对于大多数离线处理场景来说完全可以接受。分片读取带来的复杂度提升和潜在的边界 bug往往得不偿失。8. 几个容易被忽略的细节与个人经验8.1 mark 和 reset 方法的使用限制BufferedReader支持mark(int readAheadLimit)和reset()方法允许你标记当前位置之后可以回退到标记处重新读取。这个功能在解析某些格式的文本时很有用比如你需要预读几个字符来判断接下来的内容类型判断完后再回退。但mark有一个限制readAheadLimit参数指定了标记后最多能读取多少个字符超过这个限制后reset()会失败抛出IOException。而且如果缓冲区大小小于readAheadLimitmark会自动扩容缓冲区可能影响性能。实际使用中mark和reset用得并不多因为大多数场景下你可以用其他方式实现同样的效果比如先把行读进来再判断。但如果你确实需要记得把readAheadLimit设得比实际预读的字符数大一些留点余量。另外mark之后如果调用了readLine()reset()会回到标记位置但已经读过的行会重新读一遍这个行为要心里有数。8.2 缓冲区大小与 JVM 内存的关系前面提到缓冲区默认 8192 个字符占 16KB 内存这个量级很小。但如果你在代码里创建了大量的BufferedReader实例比如每个请求创建一个那内存占用就会累积。假设一个服务每秒处理 1000 个请求每个请求创建一个BufferedReader每个占 16KB那一秒内就分配了 16MB 的缓冲区内存。虽然这些对象很快会被回收但频繁的分配和回收会给垃圾回收器带来压力。优化思路是复用BufferedReader实例或者用线程池配合ThreadLocal来管理。但复用的前提是流可以重置对于文件流来说你可以用RandomAccessFile的seek(0)回到文件开头然后重新读取。对于网络流来说复用基本不可能因为数据流是一次性的。所以这个优化主要针对文件读取场景而且要在确实遇到性能瓶颈的时候才做不要过早优化。8.3 从实际项目中学到的三条经验第一条经验永远显式指定字符集。不要依赖平台默认编码不要用FileReader的默认构造函数不要用new String(bytes)不带字符集参数。这些写法在跨平台部署时都是定时炸弹。我现在的习惯是只要涉及字节和字符转换的地方都强制传StandardCharsets.UTF_8除非有明确的理由用其他编码。第二条经验读取流一定要用 try-with-resources。手动在 finally 里关闭流容易漏掉特别是当有多个流需要关闭的时候关闭顺序和异常处理都很容易写错。try-with-resources 是编译器帮你生成的正确关闭逻辑没有理由不用。如果项目还在用 Java 6那只能手动写 finally但 Java 6 已经是很老的版本了新项目不应该再考虑。第三条经验处理网络流时永远设置超时。Socket.setSoTimeout是必须的否则一个异常的网络对端就能让你的线程永久阻塞。超时时间根据业务场景设置一般 5 秒到 30 秒比较常见。如果是内部服务之间的通信可以设短一点比如 3 秒如果是面向公网的接口可以设长一点比如 10 秒。超时后要有降级或者重试逻辑不能直接让异常往上抛导致请求失败。这三条经验看起来简单但每一条背后都有真实的踩坑经历。字符集问题让我在跨平台部署时排查了一整天资源泄漏问题导致过线上服务不可用网络超时问题让线程池被占满。写代码的时候多花几秒钟注意这些细节能省下后面几小时的排查时间。