聊 Java IO绕不开一个问题到底什么是流我在刚接触 Java 的时候被 InputStream、OutputStream、Reader、Writer 这一堆抽象类搞得晕头转向后来真正写了一段时间代码回过头去看才发现 IO 流其实就那么几件事——读、写、转换、缓冲。这个体系设计得并不复杂只是教科书和面试题把它讲碎了导致很多初学者一直处在“背了又忘忘了又背”的状态。这篇博文我打算用实际开发和面试相结合的视角把 Java IO 流彻底掰开揉碎讲清楚。内容会覆盖 IO 的底层模型、四大抽象父类、字节流和字符流怎么选、缓冲流的作用原理、对象序列化以及面试里那些高频题。不管你是刚学 Java 基础还是在准备 Java 面试八股文又或者是工作中经常被 IO 性能坑到的开发者这篇文章都能给你一个比较完整的参考。我尽量把每一步的设计思路、底层原理和踩过的坑都讲明白让读者不只是会用还能说出“为什么”。1. IO流到底是什么——先搞清楚底层模型1.1 数据输入输出模型的本质IO 的全称是 Input/Output在 Java 里的实现思路其实和操作系统管理设备的方式一脉相承。任何程序只要想和外部交换数据就必然经过 IO 通道。文件读写、网络通信、控制台输入、进程间通信本质上都是数据的流入流出。数据是怎么流动的呢我从开始学的时候就觉得把 IO 想象成水管最合适。数据像水一样从源头流向目的地。Java 抽象出来的“流”其实就是一个有方向的数据序列程序可以从流里读取数据也可以把数据写入到流里。流本身不存数据它只是数据在程序和其他介质之间的通道。在 Java 中最顶层的抽象就是四个类InputStream、OutputStream、Reader、Writer。前两个处理字节数据后两个处理字符数据。它们都不是接口而是抽象类。这一点很关键因为它们不仅定义了一套标准的读写规范底层还维护了原生资源引用比如文件描述符也就是说流的创建会牵扯到底层系统资源。1.2 为什么面试喜欢问 IO 流的分类我在准备面试和做技术精进的时候发现一个规律面试官特别喜欢让你“说一下 Java IO 流的分类”。刚开始我以为是面试官在搞形式主义后来自己带人、做项目复盘才发现这个问题特别能考察一个人对 Java 整体体系的理解程度。IO 流分类考的不是记忆而是看你能不能从不同维度去描述同一个体系。从数据单位维度分有字节流和字符流。字节流适用于任何类型的文件比如图片、视频、压缩包字符流则是为了处理文本数据而设计的内部会做编码解码转换。从功能职责维度分有节点流和处理流。节点流也叫低级流直接连接数据源处理流也叫高级流包在节点流外面负责增强功能比如缓冲、转换、序列化等。从流向维度分有输入流和输出流方向必须记住——凡是带 Reader 或 Input 的类都是往里读的凡是带 Writer 或 Output 的类都是往外写的。这三个维度本身是交叉的。比如 BufferedInputStream按功能维度是处理流按数据单位维度是字节流而且它是输入流。所以面试时如果只知道背“字节流字符流”两层是很单薄的。最好的回答方式是先说自己按三个维度理解然后每个维度举几个典型类顺带说一句它们能组合使用。这个回答方式能直接体现功底。2. 四大抽象父类与子类体系2.1 InputStream一切字节输入的源头InputStream 抽象类是所有字节输入流的父类。它定义了一个最核心的方法public abstract int read() throws IOException;注意这个方法它每次只读取一个字节返回的是 0~255 范围内的 int也就是读取的那个字节的二进制值。当读到流的末尾时返回 -1。很多初学者不理解为什么“读一个字节”返回 int 而不是 byte原因是 byte 是有符号的范围是 -128~127如果用 byte 来接收就无法区分正常的字节值和 EOF。返回 int 之后就可以用负数和正数把“有效数据”和“到达流末尾”分开。InputStream 还提供了几个常用方法read(byte[] b)一次读取多个字节返回实际读到的字节数。read(byte[] b, int off, int len)从某个偏移量开始读入指定长度。available()返回在不阻塞的情况下估计可以读取的字节数。skip(long n)跳过并丢弃指定字节数。close()关闭流释放底层资源。继承 InputStream 的类非常多。FileInputStream 用于读取文件ByteArrayInputStream 把字节数组包装成输入流ObjectInputStream 用于反序列化对象FilterInputStream 是所有装饰流处理流的父类它的子类包括 BufferedInputStream、DataInputStream、PushbackInputStream 等。这个继承体系是理解 Java IO 设计模式的关键。2.2 OutputStream数据写出到目标的规范定义OutputStream 是所有字节输出流的共同抽象父类它规定了一个核心方法public abstract void write(int b) throws IOException;这个 write 方法接收一个 int 类型的参数但实际写入时会截断为低 8 位也就是说 int 的高 24 位会被丢弃只保留最后一个字节。这和 read() 返回 int 的设计形成了对称。OutputSteam 常用的方法还有write(byte[] b)将整个字节数组写出。write(byte[] b, int off, int len)从字节数组指定区间写出。flush()刷新输出流强制将缓冲区数据写入底层目标。close()关闭流释放资源。FileOutputStream 是最典型的节点流它有两个构造参数值得注意。一个是 File 或 String 路径另一个是 boolean append控制是追加写还是覆盖写。默认情况下 append 为 false意味着如果目标文件已存在会被清空后写入。如果想保留原文件内容并在末尾追加就必须显式传入 true。2.3 Reader 与 Writer面向文本的字符流抽象为什么有了字节流还不够还要设计字符流因为字节流操作的是二进制字节它不关心字符编码。而现实中的文本数据是字符一个字符在 UTF-8 里可能是 1 到 4 个字节在 GBK 里可能是 2 个字节。如果直接用字节流去读文本文件再自己去拼字节、做编码解码那代码会又繁琐又容易出错。Reader 和 Writer 就是专门为文本处理设计的。它们的 API 看起来和 InputStream、OutputStream 很像但单位从 byte 换成了 char。Reader 的核心方法是public int read(char[] cbuf, int off, int len) throws IOException;Writer 的核心方法是public void write(char[] cbuf, int off, int len) throws IOException;注意Reader 的 read 方法虽然也是返回 int但这个 int 表示的是字符的编码值而不是字节。读一个 char 返回的范围是 0~65535EOF 依然返回 -1。字符流的好处是直接帮你处理了字符和字节之间的转换。FileReader 内部默认使用平台默认字符集解码文本文件FileWriter 内部默认使用平台默认字符集编码文本数据。这里就要提到一个很多老项目踩过的坑平台默认字符集在不同操作系统上不一致。在 Windows 中文系统上默认是 GBK在 Linux 上一般是 UTF-8。所以如果代码里直接用 FileReader 读文件然后在另一台机器上跑很可能会出现乱码。Java 11 以后可以通过 Charset 参数显式指定字符集之前的老代码需要自己指定或自己写转换逻辑。2.4 为什么说类似的是设计而不是代码仔细对比 InputStream 和 Reader 的方法签名会发现它们高度相似。这其实是 JDK 设计上的一处“遗憾”——如果早一点有泛型和更好的抽象这四套体系完全可以合并成一套。但是为了向后兼容JDK 只能保留四套平行体系。在开发中我们不需要刻意去记每个子类的方法只要掌握了父类的方法规范子类基本就是换实现方式。比如你看懂了 InputStream 的抽象行为那么 FileInputStream 的本地方法读取文件、BufferedInputStream 的内存缓冲读取对你来说都是透明的。重点在于知道每个子类改变了什么、增加了什么这才是掌握 IO 体系的核心方法。3. 字节流和字符流到底怎么选3.1 三种常见场景的类型选择我们写代码时经常会问我这个需求到底应该用字节流还是字符流这个问题没有绝对统一的公式但我总结了一个相对可靠的经验法则如果源数据是图片、音频、视频、压缩包、PDF 这类二进制文件统一用字节流。如果源数据是纯文本文件、日志文件、XML/JSON 文件优先用字符流。如果拿不准文件格式或者需要保证数据无修改的复制最好还是用字节流。理由很简单。字符流会做编码解码如果你对一个二进制文件做字符流的读取那很可能会遇到不认识的字节序列把某些字节错误地转成“乱码字符”导致数据损坏。而字节流本质上是原样传递数据不经过任何转换能保证一个字节进、一个字节出分毫不差。3.2 文件复制的经典示例字节流 vs 字符流来看一个最经典的例子复制文件。用字节流实现的代码try (InputStream in new FileInputStream(source.bin); OutputStream out new FileOutputStream(target.bin)) { byte[] buffer new byte[8192]; int length; while ((length in.read(buffer)) ! -1) { out.write(buffer, 0, length); } }这个代码有一个关键点read(byte[] buffer)不一定每次都能读满 buffer。如果文件只有 1000 字节buffer 大小是 8192第一次 read 可能只返回 1000。所以在 write 的时候必须用write(buffer, 0, length)只写出实际读到的长度而不是把整个 buffer 写出去。如果写的是write(buffer)那么会把后面 8192 个字节都写入目标文件其中大部分是上轮遗留的无意义数据。这是初学 IO 时最容易犯的错。再用字符流实现同样的复制try (Reader reader new FileReader(source.txt); Writer writer new FileWriter(target.txt)) { char[] buffer new char[1024]; int length; while ((length reader.read(buffer)) ! -1) { writer.write(buffer, 0, length); } }看着结构一样但内部机制不同。字符流每读一个字符或一批字符实际上是先按字符集编码解码字节再返回 char 数组。写出的过程也要经历 char 到 byte 的编码转换。从这里能看出一个经验如果你只是做文件复制、不关心内容本身用字节流是最稳妥的如果你需要读取文本内容再做一些字符串处理那字符流省去了手动转换的麻烦。3.3 中文不乱码的核心注意点乱码问题在字符流里非常突出。我举一个现实中的例子有一次开发环境是 macOSUTF-8生产环境是 CentOS初始设置为 UTF-8但交付的数据文件是从某个 Windows 老系统导出的 GBK 文件。直接用 FileReader 读控制台打印出来全是 “锟斤拷” 和 “烫烫烫” 这类经典乱码。解决方式不能靠猜。用 InputStreamReader 显式指定字符集是最可靠的方式Reader reader new InputStreamReader( new FileInputStream(gbk.txt), StandardCharsets.UTF_8 );或者如果你确定文件是 GBKReader reader new InputStreamReader( new FileInputStream(gbk.txt), Charset.forName(GBK) );同理写文件时用 OutputStreamWriter 指定编码即可Writer writer new OutputStreamWriter( new FileOutputStream(output.txt), StandardCharsets.UTF_8 );这里有一个非常重要的原则读写时指定的字符集必须一致否则必然乱码。这个“一致”不只是 Java 代码内部的一致还要考虑文本编辑器或其他系统在保存文件时使用的字符集。所以我现在的习惯是代码里凡是涉及文本文件处理的一律显式指定字符集杜绝依赖平台默认值。这样才能保证代码在换机器、换环境、换团队的时候行为依旧稳定。4. 缓冲流为何能把性能拉满4.1 缓冲流的设计原理每次调用底层 OS 的文件读写系统调用成本都极为可观尤其是频繁的小数据量操作。一次系统调用涉及到用户态和内核态的切换如果每读一个字节就切一次性能基本上是灾难级别的。所以 JDK 提供了缓冲流BufferedInputStream、BufferedOutputStream、BufferedReader、BufferedWriter。它们内部维护了一个固定大小的缓冲区比如 BufferedInputStream 默认缓冲区 8192 字节。程序从流中读取数据时缓冲流会一次性从底层源加载一批数据到内存缓冲区后续的 read 操作直接从缓冲区拿只有当缓冲区空了才再次触发底层系统调用。写入流程同理。程序先把数据写到内存缓冲区缓冲区满了才实际刷到磁盘或网络等目标设备。这样系统调用次数从“读写一个字节一次”降低到“每 8192 字节一次”效率自然大幅提升。4.2 BufferedReader.readLine() 和字符缓冲的实际体验BufferedReader 有一个非常经典的增强方法readLine()。它一次读取一整行文本自动处理行结束符的差异。很多人在做文本处理时比如读取一堆日志按行分析都会选择用这个try (BufferedReader reader new BufferedReader( new InputStreamReader(new FileInputStream(log.txt), StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { // 处理每一行 } }用 readLine() 省去了手写字节判断和拼接字符串的繁琐过程。但要注意readLine() 返回值不包含行结束符而且当流结束时返回 null。用 while 循环判断 null 是标准写法。BufferedWriter 对应的增强方法是 newLine()它按照系统默认行分隔符写入换行符避免了不同操作系统中 \r\n 和 \n 的差异。如果在 Windows 上写文件用 \n 生成的文本用老旧的记事本打开会显示成一行没有换行用 newLine() 就没这个问题。4.3 用 BufferedOutputStream 手动 flush 的时机使用缓冲流时有个细节必须说透如果不关闭流也不做 flush那么数据可能不会立刻写入目标文件。原因是缓冲流内部积压了数据还没达到缓冲区上限底层 write 方法不会执行。有些业务场景下程序崩溃或突然断电内存缓冲区的数据就丢失了。所以在关流前或者每次写完一批需要立刻落盘的数据后都应该调用 flush() 强制刷新。典型场景是写日志。日志系统通常会在写完一条日志后调用 flush()以便日志马上可见而不是积压在内存里。另一种场景是把数据分批写入文件每写完一批flush 一次避免程序异常退出时丢失大段数据。flush() 本身也有性能开销所以不能频繁调用每调一次就可能触发一次真实的底层写入。用一句话概括缓冲是手段落盘是目的业务要求什么时候数据必须可见就什么时候 flush。4.4 缓冲流和普通流怎么组合很多新手会写出这样的代码BufferedInputStream bis new BufferedInputStream(new FileInputStream(a.txt));这是标准且推荐的组合方式处理流包在节点流外面。但我要提醒一个反例new FileOutputStream(new BufferedOutputStream(...))这种组合是反的把缓冲流当参数传给文件流实际上是没意义的因为 BufferedOutputStream 本身不是文件目标。正确方向永远是节点流做底层处理流层层包裹在外层就像套娃。最外层调用者面对的是增强后的能力最底层才是数据真正的目的地。还有一个实际开发中的细节如果用 try-with-resources 声明多个流关闭顺序是逆序的也就是先关闭外层的处理流再关闭内层的节点流。外层流关闭时通常会顺带把内层流也关闭所以手写代码时可以只关闭最外层但为了可读性和有些特殊包装流的场景还是建议在 try-with-resources 里把所有需要管理的流都写上它的自动关闭顺序能保证正确释放资源。5. 对象序列化与反序列化的底层逻辑5.1 Serializable 到底做了什么把对象变成字节流的过程叫序列化反过来从字节流恢复对象叫反序列化。Java 里定义一个对象可序列化最简单的方式就是实现 Serializable 接口public class User implements Serializable { private static final long serialVersionUID 1L; private String name; private int age; // getter / setter }Serializable 接口里面什么方法都没有它是标记接口作用就是告诉 JVM “这个类的对象可以序列化”。JVM 在序列化时会检查这个标记如果一个类没实现 Serializable 而试图序列化会抛出 java.io.NotSerializableException。这里有个关键的细节是 serialVersionUID。类文件结构里有一个序列化版本号用来验证序列化和反序列化的对象是不是同一个版本。如果没显式定义JVM 会根据类结构自动生成。但如果类结构变了比如新增一个字段自动生成的版本号就会变化导致反序列化时抛 InvalidClassException。所以规范要求显式声明 serialVersionUID并且在修改类结构时保持版本号稳定这样才能向前兼容。5.2 ObjectOutputStream 和 ObjectInputStream 的用法序列化写出的实现User user new User(张三, 25); try (ObjectOutputStream oos new ObjectOutputStream( new FileOutputStream(user.dat))) { oos.writeObject(user); }反序列化恢复对象的实现try (ObjectInputStream ois new ObjectInputStream( new FileInputStream(user.dat))) { User user (User) ois.readObject(); }writeObject 会把对象的类名、字段名、字段类型、字段值、 serialVersionUID 等信息都写入字节流中。readObject 则根据这些元数据重建对象。但是要注意一个安全陷阱readObject 的反序列化过程是可以被恶意构造的字节流攻击的。如果一个程序从不受信任的来源读取序列化数据攻击者可以构造特定的恶意对象触发任意代码执行。所以在实际项目中如果数据来源不可信不要轻易用 Java 原生序列化优先考虑 JSON、Protocol Buffers 这类安全的文本或二进制格式。5.3 transient 关键字的作用在序列化时通常希望把某些敏感字段排除掉比如密码、Token。还有一种情况是某个字段依赖运行时上下文无法被序列化。这时给字段加上 transient 修饰符即可public class User implements Serializable { private static final long serialVersionUID 1L; private String name; private transient String password; }加了 transient 的字段不会被序列化进字节流。反序列化回来时它会被赋为默认值引用类型为 null基本类型如 int 为 0。这个机制最容易让人忽略的点是它和 static 字段的关系。static 字段也不参与序列化因为 static 字段属于类而不是对象序列化只保存对象的实例状态。所以如果你遇到序列化后某个 static 值没被保存不用担心那是设计如此。6. 面试高频 IO 题梳理与避坑6.1 常见的 IO 流面试题总结结合我在面试和被面试过程中的经历我把 IO 面试题分成三类第一类是分类题第二类是原理题第三类是实战题。分类题的核心就是 InputStream、OutputStream、Reader、Writer 四大体系字节流和字符流的区别、节点流和处理流的区别这些前面已经讲过了。原理题考得最多的是“缓冲流为什么快”“字符流怎么解决乱码”“序列化时 serialVersionUID 有什么用”。这些题本质上是考察底层机制理解。答题时建议从系统调用次数、编码转换、类版本校验三个角度分别组织语言。实战题一般是“如何复制一个大文件”“如何处理 GBK 编码的文件”“try-with-resources 为什么能自动关闭资源”。这类题要现场写代码更容易暴露基本功。6.2 一个容易被问倒的细节try-with-resources 的资源关闭顺序try-with-resources 是 Java 7 推出的语法糖。它要求资源类实现 AutoCloseable 或 Closeable 接口。最终编译时会生成固定的关闭代码在 try 块结束后按声明顺序的逆序依次调用 close()。举个例子try (FileInputStream in new FileInputStream(a.txt); BufferedInputStream inBuffer new BufferedInputStream(in)) { // 使用 inBuffer }实际关闭时先关闭 inBuffer再关闭 in。因为外层处理流 close 时通常需要先刷出数据如果先关闭底层流外层刷出时就会失败。这个顺序是 JDK 设计时考虑过的所以我们在写组合流时尽量让外层声明在后面内层声明在前面也就是先创建底层再包装上层。如果手写 finally 关流一定注意判空和反向关闭代码很容易变得冗长。这也是我推荐 try-with-resources 的核心理由它让代码简洁也天然规避了关闭顺序错误和遗漏关闭的问题。6.3 项目中必须避免的 IO 代码坏味道我这里总结了几种最常见的 IO 代码坏味道如果你发现自己代码里有这些模式建议赶紧改。第一种是不关闭流。在旧代码里只写 new FileInputStream 不赋值给变量或者只关闭了最外层却忘了内层流构造失败时的资源泄漏。Java 7 以后统一用 try-with-resources 能从根本上解决。第二种是在循环里反复开关流。每次创建流都是一次系统资源申请频率高了不仅慢还可能把文件句柄耗尽。正确做法是尽量在循环外创建流在循环内复用。第三种是读取文件时只用 Scanner因为它读起来方便但遇到大文件或者对性能敏感的场景它会很吃力。Scanner 的底层是正则表达式解析开销比 BufferedReader 大得多。如果只是按行读取文本BufferedReader.readLine() 是明显更优的选择。第四种是不加说明的字符集默认依赖。代码里不指定 Charset直接 new FileReader。这在一台机器上没事换台机器就出事。所有文本 IO 操作标准做法都是显式指定字符集。6.4 大文件读取的超简单优雅方案大文件读取是一个高频需求。很多人的第一反应是把整个文件读入内存比如 Files.readAllBytes(Path)。如果文件只有几 MB这样做很舒服。但如果是几百 MB 甚至几个 GB一次全部读入内存就会导致 OutOfMemoryError因为这个错误本身就是堆内存不够的典型信号对应热词里的 “Java: OutOfMemoryError: insufficient memory”。标准的大文件读取方案是逐行处理用 BufferedReader 配 FileInputStream 和 InputStreamReadertry (BufferedReader reader new BufferedReader( new InputStreamReader( new FileInputStream(bigfile.log), StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { process(line); } }这样内存里始终只存在一行数据所以内存占用是可控的。如果想进一步提高吞吐可以考虑分批读取并用多线程处理。但要注意如果需要保证行的处理顺序那么多线程方案会复杂很多需要引入队列和排序不建议一上来就上多线程。先看单线程能不能满足性能需求再考虑扩展。还有一个经验数据量过大时不要用 String 拼接所有行再一次性写入。比如拼接 10 万行日志到一个大字符串再输出内存会瞬间暴涨。正确做法是每处理一行就写入输出流配合缓冲流既稳又快。写在最后的实际操作心得我在实际项目中用 IO 流踩过不少坑最后养成了几个习惯在这里分享给读者。第一所有流相关的代码无论多短我都会用 try-with-resources 语法第二所有文本读写字符集一定用常量指定绝不依赖默认值第三凡是有可能处理大文件的场景一律按流式处理绝不用 readAllBytes 一把梭第四二进制复制操作不要为了偷懒用字符流要用字节流加缓冲这是保证数据完整性的底线。另外在准备面试时不要只背结论要能自己把缓冲流的原理、字符集转换的过程、序列化版本号的作用讲出来。面试官不是要听标准答案是要看你对这个体系有没有真正的理解和判断力。如果你刚开始接触 Java IO建议按这样的顺序学习先字节流再字符流再转换流再缓冲流最后序列化。从最简单的文件复制开始写写完再看源码把 InputStream 和 OutputStream 的继承关系画一遍。等你能默写出每个类的位置和典型用法Java IO 这块基本就通了。