这段时间一直在啃JDK8的IO体系发现很多写了几年Java的人对InputStream的理解还停留在“调个read()就能读文件”的层面真到了线上遇到IO瓶颈、或者要处理自定义协议数据时往往说不清楚底层到底发生了什么。这次我干脆把InputStream、FilterInputStream、BufferedInputStream这三个类的源码从头到尾过了一遍环境是Windows 10 jdk1.8.0_202对照OpenJDK8u的源码一行行捋把里边的设计思路、缓冲机制、mark/reset的实现细节全部记录下来。这篇文章适合几类人刚接触Java源码阅读的初学者可以拿它当IO源码的第一篇拆解写了好几年业务代码但没系统性看过源码的老手也能借此把IO这块知识补完整另外就是做性能优化和排查IO问题的人理解缓冲机制之后很多线上问题一眼就能定位到根因。全文不涉及任何环境配置和无关话题只讲源码本身和由源码推导出的实践结论。1. InputStream源码从抽象方法到模板方法骨架1.1 read()为何是抽象方法返回int而不是byteInputStream是一个抽象类它定义了所有字节输入流的统一契约。整个类里真正的抽象方法只有一个public abstract int read() throws IOException;这个方法是整个InputStream体系的灵魂。它做的事情很简单从输入流中读取一个字节返回值范围是0到255如果已经读到流末尾则返回-1。很多人第一次看会不理解为什么读取“一个字节”要返回int而不是byte原因在于byte是有符号的范围是-128到127如果返回byte类型那么读到0xFF十进制255时会被解析成-1和流结束的-1信号冲突根本无法区分是“读到了数据”还是“流结束了”。所以JDK设计者让read()返回int类型数据部分用0到255表示-1单独作为EOF标志。这个细节是所有字节流操作的前提后续所有read相关的逻辑都建立在它的基础上。顺着这个设计再往下想InputStream之所以只有一个抽象方法是因为read()是整个骨架的基石。它把“一次读一个字节”这个最小操作留给子类实现而其他所有方法都基于它可以有默认实现。这是非常典型的模板方法模式把不变的骨架放在父类把可变的具体操作延迟到子类。1.2 批量读取的默认实现与异常吞掉机制既然单个read()是抽象方法那么一次读取多个字节的read(byte[], int, int)就可以直接用模板方法实现。JDK8里的源码是这样的public int read(byte b[], int off, int len) throws IOException { if (b null) { throw new NullPointerException(); } else if (off 0 || len 0 || len b.length - off) { throw new IndexOutOfBoundsException(); } else if (len 0) { return 0; } int c read(); if (c -1) { return -1; } b[off] (byte)c; int i 1; try { for (; i len ; i) { c read(); if (c -1) { break; } b[off i] (byte)c; } } catch (IOException ee) { } return i; }这段代码有几个值得注意的地方。先看参数检查。b为null抛NullPointerExceptionoff、len越界抛IndexOutOfBoundsException这些都是常规操作。但注意off len的计算这里做了len b.length - off的判断而不是len off b.length是为了防止整数溢出。虽然这个场景在现实里很少发生但JDK源码这种防御性写法非常值得学习。再看核心逻辑。它先调用一次read()如果返回-1则整体返回-1表示一个字节都没读到就已经EOF了。如果读到了第一个字节就把它放进b[off]然后循环继续读取后续字节。这里有个细节很多人没注意到当i已经大于0、循环中read()抛出了IOException时这个异常被catch住并吞掉了直接返回已读到的字节数i。为什么这么设计因为调用方已经拿到部分数据与其把异常抛出去导致部分数据丢失不如让上层先处理已读到的内容通过返回值判断实际读取了多少。这是IO处理中“尽力而为”思想的体现。还有一个容易被忽略的返回值语义方法的返回值为i取值范围是1到len。如果底层流在读取过程中遇到EOF返回的i可能小于len但并不代表出错。所以调用方不能简单判断“返回值是否等于len”来确认是否读完必须循环调用直到返回-1。这个坑在后续实战部分还会反复遇到。1.3 skip、available、close、mark/reset的默认语义除了read()InputStream还提供了一批带默认实现的方法通常被称为骨架方法。这些方法的默认实现设计得很有讲究体现了JDK作者对“什么情况下应该提供默认行为”的判断。skip(long n)方法用于跳过输入流中的n个字节。JDK8的默认实现是这样做的public long skip(long n) throws IOException { long remaining n; int nr; if (n 0) { return 0; } int size (int)Math.min(MAX_SKIP_BUFFER_SIZE, remaining); byte[] skipBuffer new byte[size]; while (remaining 0) { nr read(skipBuffer, 0, (int)Math.min(size, remaining)); if (nr 0) { break; } remaining - nr; } return n - remaining; }它并不是真的“跳过去”而是重新分配一个缓冲区把要跳过的字节读出来然后丢弃。之所以这么做是为了保证即使底层流本身没有实现skip的native方法也能通过readdiscard的方式达到跳过效果。但这样做的代价是效率低所以很多具体实现比如BufferedInputStream、FileInputStream都会重写这个方法提供更高效的跳过逻辑。available()方法默认返回0。这可能会让初学者困惑觉得那有什么用JDK的注释里说得很直白有些流的实现如ByteArrayInputStream能精确知道可读字节数但大部分流如网络流无法精确预估所以默认返回0由子类按需重写。这个方法的语义是“在不阻塞的情况下至少还能读取的字节数”它只是一个估计值绝不能用它来判断整个流的总长度。后面实战部分我会再讲这个坑。close()方法的默认实现是空方法。原因很简单InputStream本身没有持有任何资源资源都在具体子类里。设计上把close()实现成空方法是为了让子类在重写时可以选择是否调用super.close()同时保证调用方可以安全地关闭任何InputStream而不需要先判断类型。mark(int readlimit)和reset()这两个方法在JDK8中配合使用用于标记流的位置并回退。默认情况下markSupported()返回falsemark()什么都不做reset()直接抛IOException(mark/reset not supported)。这个设计其实很务实mark/reset并不是所有流都支持的特性如果默认实现写了一套假逻辑还不如明确告诉调用方不支持。后面讲BufferedInputStream时你会看到这两个方法被完整实现的样子。2. FilterInputStream源码JDK里的装饰器模式教科书2.1 为什么要单独剥离出一个FilterInputStreamInputStream的子类非常多但功能类型可以大致分成两大类。一类是数据来源型比如FileInputStream负责读文件ByteArrayInputStream负责读字节数组它们的职责是“从哪里读”。另一类是功能增强型比如BufferedInputStream负责加缓冲DataInputStream负责读取基本数据类型PushbackInputStream负责推回字节它们的职责是“怎么读更好”。如果没有FilterInputStream这层抽象功能增强型子类会面临一个尴尬局面每个增强类都要重新实现一遍InputStream的所有方法或者在InputStream里堆满各种可选功能。装饰器模式的出现解决了这个问题。FilterInputStream作为所有增强流的父类持有一个被包装的InputStream并把所有方法都透传给这个被包装流。这样功能增强类只需要专注于自己关心的增强逻辑其他方法天然继承透传行为。举一个典型的组合用法new BufferedInputStream(new FileInputStream(test.txt))。FileInputStream负责从文件读原始字节BufferedInputStream负责把一次次的读操作合并成批量填充。调用方完全不需要知道内部有包装关系只管调用BufferedInputStream的方法就行。这就是装饰器模式的价值通过组合代替继承在运行期动态叠加功能。2.2 volatile in字段与protected构造方法的设计细节FilterInputStream的源码非常短核心就两样东西一个字段和一个构造方法protected volatile InputStream in; protected FilterInputStream(InputStream in) { this.in in; }先看字段。in是protected的这保证了所有子类都能直接访问和操作被包装的流。它被声明为volatile这个细节在JDK8里尤其值得注意。volatile保证了多线程环境下in字段的可见性。为什么要保证可见性因为很多流的close方法会修改这个字段的状态或者在关闭后通过检查in是否为null来判断流是否已关闭。没有volatile一个线程关闭流另一个线程可能看到的是旧值导致在已关闭的流上继续操作。再看构造方法。它是protected的意味着你无法直接实例化FilterInputStream只能通过它的子类间接创建。这非常符合抽象类的定位FilterInputStream存在的意义不是被直接使用而是作为扩展的基类。既然它的所有方法都是透传直接new一个FilterInputStream出来没有任何额外价值所以干脆把构造方法设为protected从语法层面阻止无意义的使用。下面看一下它透传方法的样子public int read() throws IOException { return in.read(); } public int read(byte b[], int off, int len) throws IOException { return in.read(b, off, len); } public long skip(long n) throws IOException { return in.skip(n); } public int available() throws IOException { return in.available(); } public void close() throws IOException { in.close(); } public synchronized void mark(int readlimit) { in.mark(readlimit); } public synchronized void reset() throws IOException { in.reset(); } public boolean markSupported() { return in.markSupported(); }注意read(byte[], int, int)并没有在FilterInputStream里重复实现一遍循环逻辑而是直接调用了in.read(b, off, len)。这保证了透传行为的正确性同时也说明如果in是某种没有重写批量读取方法的流那么批量读取会走我们前面讲的InputStream默认实现。2.3 子类如何按需覆盖从BufferedInputStream到DataInputStreamFilterInputStream的子类很多每个子类都只覆盖自己需要增强的方法其他方法继续透传。对比几个典型的子类就能看出模式的价值。BufferedInputStream重写了read()、read(byte[], int, int)、skip(long)、available()、mark(int)、reset()、close()几乎是全量覆盖因为缓冲机制会影响所有读操作的行为。DataInputStream重写了readInt()、readUTF()等数据读取方法这些方法内部本质上还是基于read(byte[], int, int)来读取原始字节再按指定格式解码成基本类型。PushbackInputStream则重写了read()和read(byte[], int, int)在读操作之前先检查推回缓冲区pushback buffer里是否有数据有则优先读取推回的数据。这套设计的精髓在于使用者只需要持有InputStream类型的引用不管底层包装了多少层装饰器调用方式始终一致。这也就是为什么你在很多框架源码里能看到类似“InputStream in new BufferedInputStream(new GZIPInputStream(new FileInputStream(...)))”这种三层甚至四层包装的写法每一层都只负责一件事组合起来完成复杂功能。3. BufferedInputStream源码缓冲区是如何工作的3.1 缓冲区五个核心字段的前世今生到了本篇文章的重头戏。BufferedInputStream继承自FilterInputStream是使用频率最高的缓冲流之一。它的源码里藏着一个设计精良的缓冲系统理解它才算真正理解了IO效率的根源。public class BufferedInputStream extends FilterInputStream { private static int DEFAULT_BUFFER_SIZE 8192; protected volatile byte buf[]; protected int count; protected int pos; protected int markpos -1; protected int marklimit;先解释每个字段的含义buf缓冲区数组默认大小8192字节。读操作会把底层流的数据成批填充到这里。count缓冲区中有效数据的末尾位置。注意它并不是缓冲区的容量而是“当前缓冲区里有意义的数据到哪为止”。pos当前位置下一个要读取的字节在buf[pos]。markpos标记位置调用mark(int)时记录为pos的位置-1表示当前没有有效标记。marklimitmark之后允许读取的最大字节数。超过这个数值后如果还没调用resetmark就会失效。buf被声明为volatile和FilterInputStream中的in字段一样也是为了多线程下的可见性。虽然大多数使用场景中BufferedInputStream并不会被多个线程共享但JDK内部同样用volatile规避了极端情况下的数据不一致问题。3.2 read()与 0xff的细节单字节读取是最核心也是最容易被细节迷惑的方法。JDK8的源码是public synchronized int read() throws IOException { if (pos count) { fill(); if (pos count) return -1; } return getBufIfOpen()[pos] 0xff; }它的执行顺序是先判断当前缓冲区是否耗尽pos count如果耗尽则调用fill()重新填充如果填充后缓冲区仍然没有数据说明底层流已到末尾返回-1。否则返回buf[pos] 0xff。这个 0xff的操作非常关键。buf是byte[]取出元素时返回的是byte类型范围是-128到127。如果不做任何处理直接返回那么读到0x80-128时会被当成负数污染上层数据。 0xff的作用是把byte当作无符号整数处理当byte是负数时通过位与运算把它转换到0到255的范围内。举个例子假设buf中有字节0x80即十进制的-128-128的二进制补码是10000000做 0xff运算后得到0000000010000000即十进制128。这样就保持了原始字节的无符号语义和InputStream.read()的契约保持一致。getBufIfOpen()方法也很值得看private byte[] getBufIfOpen() throws IOException { byte[] buffer buf; if (buffer null) throw new IOException(Stream closed); return buffer; }它在返回缓冲区之前检查buf是否为null如果为null说明流已被关闭直接抛出Stream closed错误。这也是为什么关闭流后再调用read()会得到这个异常的根本原因。3.3 fill()的四种分支与mark空间管理fill()是整个BufferedInputStream源码中最复杂的方法它负责从底层流读取数据填充缓冲区同时还要处理mark/reset带来的空间约束。JDK8中fill()的核心逻辑如下private void fill() throws IOException { byte[] buffer getBufIfOpen(); if (markpos 0) pos 0; /* no mark: throw away the buffer */ else if (pos buffer.length) if (markpos 0) { int sz pos - markpos; System.arraycopy(buffer, markpos, buffer, 0, sz); pos sz; markpos 0; } else if (buffer.length marklimit) { markpos -1; /* buffer too big, invalidate mark */ pos 0; } else { int nsz pos * 2; if (nsz marklimit) nsz marklimit; byte nbuf[] new byte[nsz]; System.arraycopy(buffer, 0, nbuf, 0, pos); buffer nbuf; buf nbuf; } count pos; int n getInIfOpen().read(buffer, pos, buffer.length - pos); if (n 0) count n pos; }我把这个逻辑拆成几个分支来理解。第一种情况没有markmarkpos 0。这是最简单的场景缓冲区里的旧数据都不需要保留直接把pos重置为0从头填充。这意味着缓冲区永远只保留最近一次填充的数据之前读过的内容会被覆盖。第二种情况有mark但缓冲区已经满了pos buffer.length并且markpos 0。这说明mark位置之后的数据仍然是需要保留的但markpos之前的数据已经没有用了因为reset只会回到markpos不会回到更早的位置。此时用System.arraycopy把markpos到pos之间的数据搬到缓冲区开头然后pos更新为数据长度szmarkpos更新为0。这样做相当于把有效数据整体前移腾出后面的空间来容纳新的数据。第三种情况有mark、缓冲区满了、markpos为0这意味着整个缓冲区里的数据都是需要保留的。这个时候再往下填就会覆盖未读的标记数据。如果缓冲区长度已经大于等于marklimit说明标记已经“超出承诺范围”JDK直接让mark失效markpos -1丢弃所有旧数据从头填充。marklimit的语义在这里体现得很清楚它并不是缓冲区大小而是“mark之后数据还能被保留的最大读取字节数”。第四种情况有mark、缓冲区满了、markpos为0但缓冲区还没有达到marklimit。此时不能丢弃数据也不能让mark失效唯一的办法是扩容。扩容策略是nsz pos * 2即当前缓冲区的两倍但不能超过marklimit。这个两倍扩容的思路和ArrayList的扩容策略很像都是为了减少扩容次数。扩容后把原有数据整体拷贝到新数组中再继续从底层流读取数据。fill()最后一步是调用底层流的read(buffer, pos, buffer.length - pos)来填充数据把实际读取的字节数n加上pos赋给count。这样新的有效数据范围就是pos到count。这里有一个面试里经常追问的点为什么扩容大小是pos * 2而不是直接扩大到marklimit因为marklimit可能非常大甚至接近Integer.MAX_VALUE如果直接扩容到marklimit等于一次性分配巨大的内存很可能触发OutOfMemoryError。采用二倍扩容逐步逼近marklimit在大多数场景下既保证了足够空间又不会过早消耗过多内存。3.4 批量读取、skip、mark/reset、close的完整实现批量读取方法read(byte[], int, int)比单字节读取复杂得多。JDK8源码的核心思路是尽可能利用缓冲区已有的数据同时在请求量很大的情况下绕过缓冲区直接从底层流读取减少一次内存拷贝。简化的逻辑是先判断目标数组是否为空如果缓冲区有数据先把缓冲区里的数据拷贝到目标数组中如果拷贝完还不够再直接从底层流读取剩余部分。其中有一个严重的细节如果底层流的read一次返回-1但之前已经拷贝了部分数据则返回已拷贝的字节数。这与InputStream默认实现的返回值语义保持一致。skip(long n)的实现值得单独拿出来看public synchronized long skip(long n) throws IOException { getBufIfOpen(); if (n 0) { return 0; } long avail count - pos; if (avail 0) { if (markpos 0) return getInIfOpen().skip(n); fill(); avail count - pos; if (avail 0) return 0; } long skipped (avail n) ? avail : n; pos skipped; return skipped; }它先计算当前缓冲区还有多少可读数据avail。如果缓冲区已经空了而且当前没有mark那就直接调用底层流的skip方法这是最高效的方式。但如果有mark就必须小心了因为跳过的数据如果未来reset还需要重新读取所以不能直接跳过尚未读入缓冲区的数据而是先fill()把新数据加载进缓冲区再只跳过缓冲区可见的部分。这种保守策略保证了reset后能正确回到mark位置。mark/reset的实现非常简洁public synchronized void mark(int readlimit) { marklimit readlimit; markpos pos; } public synchronized void reset() throws IOException { getBufIfOpen(); if (markpos 0) throw new IOException(Resetting to invalid mark); pos markpos; }mark只记录当前pos和指定的readlimit。reset检查markpos是否有效有效则把pos恢复成markpos。这里有个细节reset之后之前从markpos到reset前pos之间的数据仍然留在缓冲区里所以可以重新读取。但如果在mark和reset之间读取的数据量太大导致fill()时mark失效markpos被设为-1那么reset就会抛出Resetting to invalid mark。close()实现public void close() throws IOException { byte[] buffer; while ( (buffer buf) ! null) { if (U.compareAndSetObject(this, BUF_OFFSET, buffer, null)) { InputStream input in; in null; if (input ! null) input.close(); return; } } }这段代码是JDK8里的写法用到了Unsafe的CAS操作来原子地清空buf字段。首次进入循环时如果buf不为nullCAS尝试把它设置为null成功后才关闭底层流。如果CAS失败说明其他线程也在执行close那就自旋等待。这种写法保证了并发close时底层的close只被调用一次。不过在实际开发中我们通常不会刻意去并发关闭流但理解这个机制有助于理解为什么关闭流是线程安全的。3.5 JDK8下没有readAllBytes如何正确读完一个流JDK9之后InputStream新增了readAllBytes()方法一行代码就能把整个流读成字节数组。但在JDK8环境下这个方法是不存在的很多人会踩到“JDK8中找不到符号: readAllBytes”的编译错误。正确做法是自己写一个工具方法或者复用第三方库。一个基于批读的简单实现如下public static byte[] toByteArray(InputStream in) throws IOException { ByteArrayOutputStream out new ByteArrayOutputStream(); byte[] buffer new byte[8192]; int n; while ((n in.read(buffer)) ! -1) { out.write(buffer, 0, n); } return out.toByteArray(); }这里的关键是in.read(buffer)返回的可能是1到8192之间的任意值而不仅仅是8192所以写入out时必须指定长度否则会把上一次未填满的数据也写进去。这个初级错误很常见我在不少项目里看到过类似问题根源就是没理解read返回值语义。4. 源码背后的实战经验性能、调参与避坑4.1 单字节读的性能对比与缓冲的意义弄懂源码之后最该做的就是对照实验来验证缓冲的价值。我写了一个简单的测试分别用FileInputStream直接单字节读和BufferedInputStream包装后单字节读读取同一个约10MB的文件统计耗时。结果在一个普通配置的Windows开发机上直接用FileInputStream读需要数百毫秒甚至更久而用BufferedInputStream包装后耗时下降到几十毫秒性能提升接近数量级。为什么差距这么大关键在于FileInputStream.read()是native方法每次调用都要经过Java调用栈、JNI边界、操作系统文件系统调用等多层开销。单字节读10MB文件意味着要调用上千万次native方法这个系统调用开销是巨大的。而BufferedInputStream通过fill()一次调用底层流的read方法读取8192字节然后把数据暂存在内存中后续的read只消耗内存数组的下标移动很少再触发native调用。把千万次native调用压缩到一千多次性能自然天差地别。所以在实际编写IO代码时一个非常明确的原则是不要用单字节read()写文件读取逻辑。即使不显式使用BufferedInputStream也应该用byte[]数组配合批量read来循环读取把native调用的次数降下来。4.2 不要迷信available()循环读到-1才是王道available()是很多人容易误用的方法。它返回的是“在不阻塞情况下可读取的字节数估计值”注意是“估计值”不是“总大小”。在网络流中available()经常返回0但不代表没有数据到达只是说当前底层缓冲里没有立即可读的内容。即使对FileInputStreamavailable()返回的是文件剩余大小但套上BufferedInputStream之后它返回的是缓冲区剩余 in.available()这个值是否能代表剩余文件大小取决于底层流和缓冲区的状态不能一概而论。我曾经在一个文件上传组件的代码里看到有人用available()来估算整个文件流的大小然后提前分配byte[]数组。在小文件测试时一切正常当文件稍微变大分配到的数组长度就不够用了最终导致数组越界异常。正确做法永远是循环调用read通过返回值判断是否继续读最后用ByteArrayOutputStream或自定义容器收集数据。4.3 mark/reset典型玩法魔数探测与协议头解析BufferedInputStream支持mark/reset这意味着你可以先把流中的数据预览一段再决定后续怎么处理。典型的应用场景是魔数探测和协议头预读。以PNG图片文件举例PNG文件的前8字节是固定的签名头89 50 4E 47 0D 0A 1A 0A。当你需要判断一个输入流是不是PNG时可以直接mark(8)读取前8字节和魔数比对然后reset回到文件开头继续走正式解析流程。这样既能识别格式又不会丢失数据。再举一个自定义协议的例子。假设协议格式是“4字节魔数 4字节长度 负载数据”服务端收到消息后需要先确认魔数是否匹配再把负载数据交给下游处理。实现时可以先mark(8)用readInt()读取魔数判断不匹配则直接拒绝匹配则reset回初始位置再用正常流程解码。这个模式在实现很多网络协议解析框架时非常常见。需要注意的一点是使用前先调用markSupported()确认流是否支持mark。BufferedInputStream支持但很多其他流不一定支持。如果在一个不支持mark的流上直接调mark/resetreset会抛出IOException。4.4 关闭流的正确姿势与重复关闭问题关闭流的基本原则是只关闭最外层包装流让包装流自动级联关闭底层流。BufferedInputStream.close()最终会调用底层流的close()所以new BufferedInputStream(new FileInputStream(...))只需要关最外层即可。很多人会习惯性地在finally块中把每个流都close一遍这会导致底层流被重复关闭。大多数流的close()被实现为幂等操作重复关闭不会报错但也有例外情况。最稳妥的写法是使用Java 7引入的try-with-resources语法try (InputStream in new BufferedInputStream(new FileInputStream(test.txt))) { // 读取逻辑 }这个语法会在try块结束后自动关闭in并且不管中间是否抛异常都能正确执行。关闭顺序上JVM会按资源声明的逆序自动关闭保证最外层先关闭底层流后关闭不会出现关闭顺序颠倒的问题。对于BufferedInputStream还有一个特殊细节关闭之后buf会被CAS置为nullin也会被置为null。此后调用read()或reset()都会通过getBufIfOpen()抛Stream closed。但如果你在close之前没有读完所有数据关掉之后还想继续读是做不到的所以要确保读取完成后再关闭。4.5 Windows下阅读源码和调试的实用技巧在Windows环境下阅读JDK源码第一步是找到src.zip。典型路径是安装JDK时设定的目录下的jdk1.8.0_xxx\src.zip如果不确定可以在命令行执行java -version确认安装路径再进入对应目录查找。在IntelliJ IDEA里默认情况下按住Ctrl点击InputStream会打开反编译后的class文件内容可读但缺少注释。要关联源码可以在Project Structure的SDKs设置页面Sourcepath一栏添加src.zip的路径。添加之后源码文件会变成真正的Java源文件注释、原始代码结构都能看到调试时也能直接跳转到源码行。调试BufferedInputStream有个很实用的技巧在read()方法内部打上断点然后watch buf.length、pos、count、markpos这四个关键字段。每次fill()执行后观察这些字段的变化就能直观看到缓冲区的填充和移位过程。特别是执行mark/reset场景时观察markpos从正数变为0或稳定在某个位置比读十遍源码都管用。5. 常见问题速查表与排查实录5.1 高频问题排查表把IO开发中常见的问题整理成表格排查效率能提升一大截现象根因解决方式单字节read循环读取极慢每次read触发底层native调用使用BufferedInputStream或批量read读入byte[]read()返回-1被当成数据混淆了byte的有符号性和int读取语义用int接收read()返回值和0xFF区分-1mark/reset抛IOException底层流本身不支持mark外层包BufferedInputStream用available()预分配数组越界available只是估计值不是总长度改循环read动态收集数据关闭包装流后再关底层流报错重复关闭只关闭最外层或使用try-with-resources读文本出现乱码字节流没指定编码用InputStreamReader包装并指定字符集关闭流后read抛Stream closed内部buf/in已经置空检查关闭时机避免使用已关闭流这个表格里的每一行背后都对应着源码中的具体实现逻辑。理解了源码这些异常就不再是“玄学”而是有明确依据的行为。5.2 一个完整的文件复制实现与缓冲区调优最后分享一个结合缓冲区实现的文件复制示例它同时会验证前面讲的各个要点public static void copyFile(File source, File target) throws IOException { try (InputStream in new BufferedInputStream(new FileInputStream(source), 64 * 1024); OutputStream out new BufferedOutputStream(new FileOutputStream(target), 64 * 1024)) { byte[] buffer new byte[8192]; int n; while ((n in.read(buffer)) ! -1) { out.write(buffer, 0, n); } } }这里我把缓冲流内部缓冲区设置为64KB比默认的8KB更大目的是减少底层read调用的次数。一次read调用能搬运的数据越多系统调用次数越少整体吞吐量越高。对于大文件复制调大缓冲区通常能获得明显收益。但要注意缓冲区并不是越大越好过大的缓冲区会占用堆内存并且在大并发场景下放大内存压力。一般来说8KB到64KB之间是比较合理的范围具体取值可以通过基准测试来确认。另外注意缓冲区数组buffer和缓冲流内部buf的区别。buffer是我们自己分配的临时数组用于批量读取和写入而BufferedInputStream内部还有自己的buf两者作用不同但如果连续多次调用read(buffer)数据先从内部buf拷贝到buffer再写入输出流中间多了一次内存拷贝。如果直接使用in.transferTo()JDK9或自写的循环直接写可以减少拷贝次数不过在JDK8下这个实现已经足够高效了。5.3 一次线上问题排查文件读取突然变慢分享一个真实案例。有段时间一个批处理任务每天凌晨跑读取一批固定大小的Excel文件耗时从稳定的40秒突然变成3分钟。一开始怀疑是磁盘问题但同一台机器上其他任务没有类似波动。后来在代码里排查发现问题出在读取逻辑被改成了while (in.read() ! -1) { count; }这是在统计文件字节数的代码被误写成了单字节循环。read()每次只读一个字节通过BufferedInputStream包装后虽然不会每次都触发底层read但单字节循环本身在Java层有方法调用开销还要频繁更新缓冲区状态性能依旧很差。改成批量读统计后byte[] buffer new byte[8192]; int n; while ((n in.read(buffer)) ! -1) { count n; }耗时立刻回到40秒左右。这个案例再次说明理解read()的底层行为不只是在面试中有用在生产环境里就是实打实的收益。我在实际读JDK源码时还有一个习惯每读完一个类就尝试在白纸上画出这个类的方法调用链从抽象方法出发标记哪些方法被重写、哪些复用了父类实现、哪些是模板方法。这样一套流程下来整个IO体系就不只是零散的知识点而是一张互相连接的网。这次把InputStream、FilterInputStream、BufferedInputStream三个类串起来读完之后再看常见的IO工具类和框架代码会明显感觉理解深度不一样了。如果你也打算系统地啃一遍JDK源码建议从IO这条线入手投入产出比相当高。