1. 读不完的文件，写不完的坑：Java IO流到底在解决什么问题
很多人学Java IO时会有一个直观感受：类太多、继承关系太乱、记不住。FileInputStream、FileReader、BufferedReader、InputStreamReader……光看名字已经头大。但如果你真正在项目里写过文件导出、上报日志、解析上传文件的逻辑，就会知道IO流从来不是"背几个类名"就能搞定的东西。它会以各种姿势在线上折磨你——比如导出报表时内存爆掉、解析CSV时中文乱码、批量读取大文件时整个接口卡死。Java IO流作为所有数据读写的基础设施，其核心价值其实就一句话：用统一且分层的方式，解决外部数据与程序内存之间的双向搬运问题。
所谓"流"，本质就是一组有序的数据序列。就像水管里的水一样，数据从一个源头流进程序，或从程序流向某个目的地。Java把这种模型抽象为四个基类：InputStream、OutputStream、Reader、Writer，然后通过装饰器模式层层叠加功能。这种设计让IO体系具备了极强的扩展性，但代价是初学者很容易迷路。这篇文章我会结合自己写文件处理模块的实战经历，把Java IO的核心分类、高频用法、性能陷阱、NIO与经典IO的分水岭都梳理一遍。适合正在准备Java面试的人，也适合写代码时对IO操作始终心里没底的开发同学。
我个人建议，千万别把IO当成"会用几个流就行"的小知识点。它是所有读写逻辑的地基，地基不牢，后面处理大数据、搞网络编程、写中间件，全都会还债。
2. 字节流与字符流的分野：为什么FileReader读二进制一定会出事
2.1 四个抽象基类，撑起整个IO家族
Java IO把所有数据读写抽象成四个顶层角色，这是入门第一课，也是很多人后面混淆概念的根源。
- InputStream：字节输入流，负责把外部字节数据读入程序。
- OutputStream：字节输出流，负责把程序中的数据以字节形式写出去。
- Reader：字符输入流，负责以字符为单位读取文本数据。
- Writer：字符输出流，负责以字符为单位写出文本数据。
字节流和字符流的本质区别在于数据单元：字节流一次处理一个字节（8位），字符流一次处理一个字符（Java中char是16位）。你可以这样理解：字节流是"原封不动搬砖"，字符流是"先解码再搬字符串"。
所有文件的底层存储都是字节，所以字节流是IO体系的基石。任何IO操作最终都要落到字节层面，字符流只是在这个基础上额外做了一层"字节到字符"的编码转换。这就是为什么FileInputStream可以读一切文件，而FileReader只适合读文本文件——如果你用FileReader去读一张图片或一个PDF，得到的一定是乱码或者流中断的异常。
2.2 FileInputStream与FileReader的取舍
下面用一段最基础的代码演示两者的差异。假设有一个GBK编码的文本文件test.txt，内容是"你好，Java"。
// 用FileInputStream读取：拿到的是原始字节 try (FileInputStream fis = new FileInputStream("test.txt")) { byte[] buffer = new byte[1024]; int len; while ((len = fis.read(buffer)) != -1) { System.out.print(new String(buffer, 0, len, "GBK")); } }这里手动指定了GBK解码，才能正确显示中文。如果不指定，会用平台默认编码（通常是UTF-8），就会乱码。
再看FileReader：
try (FileReader fr = new FileReader("test.txt")) { char[] buffer = new char[1024]; int len; while ((len = fr.read(buffer)) != -1) { System.out.print(new String(buffer, 0, len)); } }FileReader内部做的是平台默认编码的解码。如果文件编码和平台默认编码不一致，读出来就是乱码。更关键的是，FileReader的编码行为在构造时就被锁死了，你无法动态指定字符集，这是它最让人诟病的一点。
所以我自己在项目里几乎不用FileReader直接读文件，而是用InputStreamReader配合FileInputStream，因为后者可以在构造时显式传入字符集：
try (InputStreamReader isr = new InputStreamReader(new FileInputStream("test.txt"), StandardCharsets.UTF_8)) { char[] buffer = new char[1024]; int len; while ((len = isr.read(buffer)) != -1) { System.out.print(new String(buffer, 0, len)); } }这看起来多包了一层，但换来的是对编码的完全掌控。项目中凡是涉及跨平台文件读取，我都建议用这个组合，而不是直接用FileReader。
2.3 为什么JDK设计者还要保留FileReader
既然FileReader这么不灵活，为什么不去掉？因为对"文件编码和平台默认编码一致"的场景，它确实更简洁，而且很多老代码就是这么写的。JDK要保证向下兼容，所以FileReader继续存在。但从新项目最佳实践出发，我强烈建议绕过它。
在处理IO流选型时，记住一条最基本的判断准则：要处理文本且关心编码，就用字符流（或转换流）；要处理图片、视频、压缩包、序列化数据，就老老实实用字节流。
3. Buffered流和转换流：不只为了性能，还改变了读写习惯
3.1 为什么裸用FileOutputStream写文件会这么慢
从FileInputStream直接read到byte[]，这种写法性能并不理想。每次read都会触发一次系统调用，好比每喝一口水都要走到河边。系统调用是有用户态到内核态切换开销的，频繁调用代价很大。
BufferedInputStream/ BufferedOutputStream的作用就是在内存里开一块缓冲区，缓冲区的默认大小是8192字节（JDK实现里是8KB）。当缓冲区满了才真正触发一次系统调用，这样能把几十次甚至几百次底层IO合并成一次，大幅减少内核态切换次数。下面用代码直观对比：
不加缓冲：
try (FileInputStream fis = new FileInputStream("bigfile.bin"); FileOutputStream fos = new FileOutputStream("copy.bin")) { byte[] buffer = new byte[1024]; int len; while ((len = fis.read(buffer)) != -1) { fos.write(buffer, 0, len); } }这段代码的性能瓶颈在于write方法每次写一个1024字节的小块，虽然比单字节读写好很多，但依然有很多次系统调用。而加上缓冲流之后：
try (BufferedInputStream bis = new BufferedInputStream(new FileInputStream("bigfile.bin")); BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream("copy.bin"))) { byte[] buffer = new byte[8192]; int len; while ((len = bis.read(buffer)) != -1) { bos.write(buffer, 0, len); } }实测复制一个几百MB的文件，不加缓冲和加缓冲的耗时差距可能是两三倍以上，文件越大差距越明显。原因就在系统调用次数上：缓冲区让底层IO的批量性大大增强。
我把这两种写法的差异总结成一个表，方便对比：
| 对比维度 | 无缓冲流直接读写 | 使用缓冲流 | 使用自定义大byte[] |
|---|---|---|---|
| 系统调用触发频率 | 每次read/write都触发 | 缓冲区满才触发 | 取决于byte[]大小 |
| 常见场景耗时 | 较慢 | 最快 | 接近缓冲流 |
| 代码复杂度 | 最低 | 低，只需多包一层 | 中等 |
| 读文本是否方便 | 不方便 | 有readLine | 需手动处理换行 |
所以，写IO代码时第一个习惯就是：涉及到频繁小数据量读写，默认包一层缓冲流。这不是优化技巧，而是基本素养。
3.2 readLine真的好用，但要小心跨平台换行
BufferedReader提供了readLine()方法，按行读取文本，这在解析日志、读取配置文件、处理CSV时非常好用。但这里有个我踩过的坑：不同操作系统的换行符不一样。Windows是"\r\n"，Linux和macOS是"\n"，老Mac则是"\r"。readLine()会把行尾的换行符自动去掉，但如果你用split或者手动处理字符串时假设了固定换行符，跨平台就会出现数据错位。
处理办法是：读文件时不要自己判断换行符，直接依赖readLine()；写文件时如果需要拼接多行，统一用System.lineSeparator()，它会根据操作系统返回对应的换行符。
try (BufferedWriter writer = new BufferedWriter(new OutputStreamWriter( new FileOutputStream("output.txt"), StandardCharsets.UTF_8))) { writer.write("第一行"); writer.newLine(); writer.write("第二行"); writer.newLine(); }BufferedWriter的newLine()方法底层用的就是System.lineSeparator()，写多行文本最好用这个方法而不是手动写"\n"。这样生成的日志文件在Windows和Linux之间传送时不会因为换行符格式被工具误判。
3.3 转换流本质是"编码适配器"
InputStreamReader和OutputStreamWriter常被称为转换流，因为它们完成字节与字符之间的双向转换。我理解它们就是编码适配器：字节流不懂字符编码，字符流不懂字节传输，转换流在中间做翻译。
实际项目中最常见的运行场景是：从某个接口或MQ拿到一批字节数据，需要按指定编码解析成文本。这时候用InputStreamReader指定编码就非常顺手。
// 从网络输入流读取UTF-8文本 InputStream wireInput = socket.getInputStream(); BufferedReader reader = new BufferedReader( new InputStreamReader(wireInput, StandardCharsets.UTF_8)); String line = reader.readLine();转换流的价值在于：它让"字节流"与"字符流"两套体系可以自由组合。这也就解释了为什么IO的装饰器模式这么强大——BufferedInputStream可以叠加在FileInputStream上，InputStreamReader又可以叠加在BufferedInputStream上，能力逐层加强。
4. 序列化与数据流：对象落盘的艺术与陷阱
4.1 ObjectInputStream和ObjectOutputStream：对象持久化的门槛
Java原生的对象序列化使用ObjectOutputStream将对象写成字节流，再用ObjectInputStream读回来。需求场景很常见：缓存对象到本地、网络传输对象、Session持久化等。
基本用法如下：
// 序列化对象到文件 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(); }要求被序列化的类必须实现java.io.Serializable接口，否则会抛NotSerializableException。
这里有几个容易踩的坑。第一个坑是serialVersionUID。如果一个类在序列化后修改了结构（比如加了字段、删了方法但没改字段），反序列化时会因为版本不一致抛出InvalidClassException。最佳实践是：每个实现Serializable的类都显式声明一个serialVersionUID，并且修改类结构时如果有兼容性需求就保持该值不变。
第二个坑是transient关键字。被transient修饰的字段不会被序列化。比如缓存了某个对象，但不想把密码字段写进磁盘，就可以用transient。
public class User implements Serializable { private static final long serialVersionUID = 1L; private String name; private transient String password; // 不参与序列化 }第三个坑是静态字段不参与序列化。static字段属于类级别，不属于实例，所以序列化时默认忽略。如果反序列化后静态字段的值变了，那一定不是你序列化进去的值。
4.2 DataInputStream与DataOutputStream：处理基础类型的原生方式
如果需要往文件里写入多种基础类型数据（int、double、boolean、UTF字符串），DataOutputStream会按Java规范固定顺序和长度写入，保证跨平台可读。DataInputStream按同样规则读回来。
try (DataOutputStream dos = new DataOutputStream(new FileOutputStream("data.bin"))) { dos.writeInt(100); dos.writeUTF("你好，Data Stream"); dos.writeDouble(3.14159); } try (DataInputStream dis = new DataInputStream(new FileInputStream("data.bin"))) { int i = dis.readInt(); String s = dis.readUTF(); double d = dis.readDouble(); }需要特别注意的是读写顺序必须一致。writeUTF写入的字符串有一个两字节的前缀表示长度，readUTF会根据这个长度读取。如果顺序写反了，读到的就是垃圾数据或者EOFException。
DataOutputStream读UTF用的是JDK改良过的UTF-8编码，与标准的UTF-8略有差异。如果你要和其他非Java程序交换数据，尽量别用writeUTF，直接设定字符集写入更安全。
4.3 序列化框架选型的个人看法
Java原生序列化有一个绕不开的问题：性能差、体积大、安全性存在隐患（反序列化时可能执行恶意类的构造逻辑）。所以现代项目里，尤其是各系统间做RPC调用时，我很少直接用Java原生序列化，而是选Jackson、Fastjson、Protobuf这类方案。
但如果只是本地简单落盘缓存对象，Java原生序列化的简单性依然无法替代：不需要引入额外依赖，代码只需两三行。我的建议是：搞清原生序列化的机制和坑，然后在真正需要高性能传输时再切换到更专业的序列化框架。
5. 资源关闭与try-with-resources：为什么你写的finally块可能是错的
5.1 IO流资源泄漏是怎么产生的
IO流底层持有操作系统资源，比如文件句柄。如果流没关闭，文件句柄会一直被占用。在Windows上，最明显的表现是文件被锁定，删除或重命名时会报"文件正在使用"。在Linux上，文件句柄耗尽则会导致"Too many open files"异常，服务直接不可用。
早期的正确做法是在finally块中关闭流：
FileInputStream fis = null; try { fis = new FileInputStream("test.txt"); // 读取操作 } catch (IOException e) { e.printStackTrace(); } finally { if (fis != null) { try { fis.close(); } catch (IOException e) { e.printStackTrace(); } } }这种代码不仅啰嗦，还非常容易出错。很多人会在finally里忘记处理close方法的IOException，或者在close之前自己的try块就抛了异常，导致finally里的close成了新的异常源头。最尴尬的是，当try块和finally块同时抛异常时，finally的异常会覆盖try里的异常，导致原始错误信息被吞掉。
5.2 try-with-resources：JDK7之后的标准答案
从JDK7开始，凡是实现了AutoCloseable接口的资源都支持try-with-resources语法，IO流的所有实现类天然满足这一条件。用法如下：
try (FileInputStream fis = new FileInputStream("test.txt"); BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) { String line; while ((line = reader.readLine()) != null) { System.out.println(line); } } catch (IOException e) { // 统一处理 }多个资源按创建顺序依次关闭，并且如果try块抛异常，关闭资源时抛出的异常会被抑制，原始异常不会被覆盖。JDK为Throwable增加了addSuppressed方法，专门记录被抑制的异常。
我见过很多老项目还在用传统finally写法，其实完全可以在新代码里全面切换到try-with-resources。它不是一种"新特性"，而是Java IO代码的默认标准。如果你还在手写close，那真的是在用绳子上吊还嫌绳子不够结实。
5.3 关闭顺序：先内后外还是先外后内
try-with-resources中资源是逆序关闭的，也就是后创建的先关闭。对于IO流的嵌套包装，这个顺序是对的：先关外层（BufferedReader），再关内层（FileInputStream）。因为外层关闭时可能会flush缓冲数据，如果先关内层，外层flush就会报错或丢失数据。
但如果你还在用老的finally手动关闭，一定要记得：先关外层，再关内层。这个顺序和直觉相反，很多人搞反了。之前就有一个同事，用自定义包装流在finally里先关内层FileOutputStream，再关外层BufferedOutputStream，结果缓冲区里最后一段数据没写完，生成的文件不完整，排查了半天才找到原因。
6. 性能与编码之外，你还需要懂的NIO世界观
6.1 阻塞IO的致命短板
经典IO（OIO）最大的问题是阻塞。当线程执行一个read操作时，如果数据还没准备好，线程会一直卡在那里，什么都不干。这种模型处理少量连接没问题，但面对成千上万的并发连接，每个连接一个线程，线程数量和上下文切换开销会直接把服务拖垮。
BIO在《Java网络编程》时代是主流，但现代高并发场景下已经很难扛住大规模连接。网上很多文章会说"BIO已死，NIO当立"，这个表述有些极端，但对多数互联网后端来说，NIO确实是更合理的方向。
6.2 NIO三大件：Channel、Buffer、Selector
NIO（Non-blocking IO，JDK 1.4引入）的核心由三个组件支撑：
- Channel（通道）：双向的IO传输通道，既可以读也可以写，不像InputStream和OutputStream那样单向。
- Buffer（缓冲区）：数据读写的中转站，所有Channel的读写都必须经过Buffer。
- Selector（多路复用器）：允许一个线程同时管理多个Channel，只有当某个Channel有数据可读写时，线程才去处理，避免空转阻塞。
用生活类比的话，Channel是高速公路，Buffer是服务区，Selector是路口交警。高速公路四面八方都通，交警只需要盯着哪条路上有车要进出，就去指挥一下，而不是每条路派一个人蹲着。
一个经典的NIO读文件示例：
try (FileChannel channel = FileChannel.open(Paths.get("test.txt"), StandardOpenOption.READ)) { ByteBuffer buffer = ByteBuffer.allocate(1024); int bytesRead = channel.read(buffer); while (bytesRead != -1) { buffer.flip(); // 切换为读模式 while (buffer.hasRemaining()) { System.out.print((char) buffer.get()); } buffer.clear(); // 清空，准备再次写入 bytesRead = channel.read(buffer); } }注意flip和clear这两个操作，它们是Buffer指针管理的核心。flip将Buffer从写模式切换到读模式，limit被置为当前position，position归零。clear则相反，准备下一次写入。新手最容易在这两个方法上翻车，忘了flip会导致一个字都读不出来。
6.3 既然NIO这么强，为什么很多IO操作还是用经典流
NIO的优势集中在大规模连接和并发场景，但在普通文件读写场景，它并不一定比Buffered IO更快。经典IO经过了这么多年的JVM优化，在小文件、小数据量读写上已经非常高效，而且代码可读性更好。
Java 7引入了NIO.2（AIO），支持真正的异步非阻塞IO，但也存在模型复杂、调试困难的问题。在实际项目中，NIO的Selector模型用不好反而容易出隐性问题。所以选择的标准很简单：网络编程、高并发网关、中间件，用NIO或Netty；本地文件读写、数据处理，用经典流加上缓冲包装就足够了。
7. 编码问题的本质与解决方案：乱码不是玄学
7.1 为什么我的中文变成了奇怪的符号
乱码的根源是编码和解码使用的字符集不一致。一个UTF-8编码的"中"字，对应三个字节0xE4 0xB8 0xAD。如果程序用GBK去解码这三个字节，得到的就是完全不同的字符。整个过程在没有报错的情况下产生了错误数据，是最难排查的问题类型。
信息论里有一个简单的理解方式：编码是"字节序列到字符"的映射，解码是"字符到字节序列"的映射。只要写和读用的映射表不一致，数据就必然会错。
7.2 工程上的应对方案
第一，文件读写时显式指定字符集。绝不要依赖平台默认编码。
// 读文件 Reader reader = new BufferedReader( new InputStreamReader(new FileInputStream(file), StandardCharsets.UTF_8)); // 写文件 Writer writer = new BufferedWriter( new OutputStreamWriter(new FileOutputStream(file), StandardCharsets.UTF_8));第二，字符串和字节转换时同样显式指定字符集。
String text = "Java IO"; byte[] bytes = text.getBytes(StandardCharsets.UTF_8); String decoded = new String(bytes, StandardCharsets.UTF_8);第三，HTTP接口或RPC框架的编码设置。Spring Boot中可以通过server.servlet.encoding.charset=UTF-8等方式确保请求和响应的字符集统一，具体方式因框架版本而异，但原则一致：传输层、应用层、存储层各环节的编码必须一致。
7.3 读入半个字符怎么办
当一个UTF-8字符的多个字节被分到两次read调用中读取，如果直接做字符解码就会出错。比如一个"中"字三个字节，第一次read只读到了两个字节，第二次才读到第三个，如果直接new String就会得到错误字符。经典IO的Reader内部通过ByteBuffer和CharsetDecoder维持解码状态，能在一定程度上处理跨调用解码，但在自定义网络协议处理时仍然要小心分片问题。NIO中这个问题更明显，所以有专门处理半包/粘包的策略。
一个简单可靠的做法是：明确每条消息的大小或结束符，用缓冲区先把完整消息攒齐后再解码。比如按行传输的文本协议中，只有拿到完整的一行才做编码转换。
我个人在实际项目里的建议是：解析文本数据时，先把整个输入攒成字节数组（前提是数据量可控），再一次性做编码转换。这样既避免跨调用解码问题，也方便调试排查。
8. 文件复制、目录遍历与临时文件的正确姿势
8.1 别再手写复制文件的循环了
JDK 7提供了Files.copy方法，一行代码搞定文件复制：
Files.copy(Paths.get("source.txt"), Paths.get("target.txt"), StandardCopyOption.REPLACE_EXISTING);这个方法内部会根据文件大小选择合适的复制策略。对小文件可能直接在JVM堆内复制，对大文件则自动选择更高效的系统级复制方式。相比自己手写read/write循环，代码更简洁，性能也更有保障。
从Java 10开始，Files.copy(InputStream, Path, ...)还能直接把输入流写入文件，做下载文件、临时文件落盘非常方便。
8.2 目录遍历用Files.walk还是递归
处理目录遍历时，Files.walk提供了流式API，可以很方便地过滤和收集文件：
try (Stream<Path> paths = Files.walk(Paths.get("/data/logs"))) { List<Path> txtFiles = paths .filter(Files::isRegularFile) .filter(p -> p.toString().endsWith(".txt")) .collect(Collectors.toList()); }Files.walk返回的Stream必须放在try-with-resources中，否则底层目录流不关闭，依然会造成文件句柄泄漏。我见过有人在这里踩坑，遍历十万个文件的目录后，程序报Too many open files，就是因为Stream没关。
8.3 临时文件的坑：谁负责清理
Files.createTempFile生成的文件默认放在系统临时目录（如Linux的/tmp，Windows的%TEMP%）。它不会自动删除，需要自己定期清理或使用deleteOnExit机制。
Path tempFile = Files.createTempFile("app-", ".tmp"); // 使用完毕后 Files.deleteIfExists(tempFile);deleteOnExit方法在JVM正常退出时会删除文件，但如果JVM是通过kill -9强杀的话，就没有机会执行清理。所以对临时文件的清理策略，不要完全依赖deleteOnExit，最好在业务代码里显式删除，或由操作系统的定时任务兜底。曾经有个项目在生成报表时没清理临时文件，跑了几个月后把服务器磁盘塞满了，报警才知道问题出在临时文件清理上。
9. 最后分享几个IO实战里的血泪经验
写代码多年，处理过Excel导出、大日志解析、图片上传下载、多系统间文件传输等场景，Java IO看起来简单，真正用好的窍门都在细节里。这里把我最有价值的几条经验整理出来。
第一条，永远不要用read()返回的单字节去拼接数据。read()每次返回一个int，是"这一个字节"的数值，而不是通用意义上的"字符"。频繁调用read()性能极差，而且很容易在字节转字符时出错。要么用缓冲流配合readLine，要么用定长byte[]批量读取。
第二条，所有IO读写都遵循同一套原则：明确数据源头、明确数据编码、明确数据边界。源头错了，后面全错；编码错了，数据全是乱码；边界错了，读到的数据永远是错位的。
第三条，线上排查IO问题，先看错误日志的堆栈指向哪个IO类，再检查资源是否关闭、路径是否存在、权限是否足够、磁盘是否满了。大多数IO报错都不是代码逻辑本身的问题，而是外部条件没满足。FileNotFoundException不要只想着是不是文件名写错了，还要看看目录是否存在、进程是否有权限创建文件。
第四条，对于大文件处理，优先考虑分片或流式处理，而不是一次性读进内存。一个200MB的文件直接读进byte[]，堆内存可能直接OOM。正确做法是用缓冲流配合固定大小的字节数组，或者用内存映射文件等方式处理。
最后，Java IO的知识点虽然多，但成人达己的路径是清晰的：先掌握字节流和字符流的两大分类，再熟悉装饰器组合的用法，接着理解编码和资源管理的坑，最后再上升到NIO和网络编程。把这四步走扎实，你在项目中遇到任何读写需求，都能像拼乐高一样快速找到合适的配件。
这篇文章以一个实操者的视角把Java IO流的体系、陷阱、最佳实践都过了一遍。如果你准备面试，重点理解字节流与字符流的分野、IO的装饰器模式、NIO的三大组件与经典IO的区别；如果你在写代码，直接照搬上面的代码模式和资源管理方式，能帮你少踩很多坑。希望这些经验能让你的Java IO之路走得更顺畅。
