排查了半天的线上问题结果发现是一个日志文件的读写把整个线程池都拖垮了熬夜上线的导出功能第二天一早就被投诉中文乱码开发环境明明能读到的文件部署到服务器上却一直FileNotFoundException……这类场景我估计大多数Java开发都经历过。IO流这个知识点平时确实不起眼可一旦出了问题往往就是事故级别。我这些年带团队、做面试官发现很多人的Java IO流知识停留在会用FileInputStream和FileOutputStream的层面稍微问深一点——为什么要有缓冲流、字节流和字符流到底怎么选、serialVersionUID不写会有什么后果——就开始含糊了。这篇文章就把IO流做个完整的梳理先拆体系再讲细节给几段可以直接抄的代码最后把我在生产环境踩过的坑挨个列出来。1. 整体思路与IO流体系拆解1.1 先从四大抽象类说起要理解IO流别急着钻进那一大堆子类的命名里先把java.io包下的四个抽象类记牢InputStream、OutputStream、Reader、Writer。前两个是字节流后两个是字符流。所谓输入输出都是站在程序内存的角度说的——把数据从外部读进内存就是输入把内存里的数据写到外部就是输出。很多新人经常把方向搞反我给你一个记忆方法看方法名带read的是往程序里读带write的是从程序往外写记住这一点方向就不会错。这四个抽象类基本定义了IO流的通用行为。InputStream和Reader负责读OutputStream和Writer负责写各自的实现类通过名字里的前缀就能看出数据源或目的地。我用一张表帮你把常见的对照关系理清楚抽象类方向读写单元典型实现InputStream输入字节FileInputStreamOutputStream输出字节FileOutputStreamReader输入字符FileReaderWriter输出字符FileWriter很多人在这一步容易犯的毛病是上来就背类名背完就忘。但一旦你意识到四个抽象类就是四扇门read和write就是门上的把手后面所有类都不过是给这扇门加了不同的装饰理解起来就顺了。1.2 装饰器模式IO流强大的关键很多初学者第一次看到嵌套构造方法时直接崩溃“这包得跟俄罗斯套娃一样到底谁是谁”其实这正是Java IO流设计的精髓——装饰器模式。以文件读取为例FileInputStream负责从文件拿原始字节它本身没有缓冲能力BufferedInputStream接过这些字节在内存里开一块缓冲区减少底层系统调用次数。每一层流只关心自己这一件事组合起来就是一套完整的能力。这种设计最大的好处是可插拔。你今天想从文件读明天想从网络读只需要换最内层的数据源后面的缓冲、转换逻辑可以原封不动地复用。如果当初Java把每种能力都做成一个独立类类数量会爆炸而且每个类都要重复实现一遍底层调用。理解了这层设计你就不需要硬记每一个类只需要想清楚当前要哪几个能力然后用嵌套构造把流一层层包起来就好。在实际编码里我看到大量人混淆“继承实现”和“组合包装”就是因为没理解装饰器模式你可以把外层流当成给内层流加装备装备可以叠加但核心始终是最内层的数据源。1.3 不同数据源对应的流类型速览同样叫输入输出但数据从哪来、到哪去对应的类完全不同。我整理了一份速查面试前拿来过一遍也管用数据源/目标字节流处理二进制字符流处理文本文件FileInputStream / FileOutputStreamFileReader / FileWriter字节数组ByteArrayInputStream / ByteArrayOutputStream通过转换流配合字符串不常用StringReader / StringWriter管道PipedInputStream / PipedOutputStreamPipedReader / PipedWriter缓冲包装BufferedInputStream / BufferedOutputStreamBufferedReader / BufferedWriter对象ObjectInputStream / ObjectOutputStream不常用这类映射不用死记重点是你先判断数据形态图片、视频、压缩包这类二进制走字节流正常文本、日志、JSON走字符流。字符流本质还是字节流只不过在内部完成了字节到字符的转换所以文本场景直接用字符流能少写很多转换代码。反过来如果你用字节流处理文本就要自己处理编码问题这就是后面要讲的乱码来源之一。2. 核心细节解析与实操要点2.1 字节流和字符流选择依据与底层关系字节流按字节读取二进制数据对它来说就是一个一个字节不会做任何特殊解释所以处理图片、音视频、压缩包等二进制文件时是安全的。字符流则按字符读取内部会根据指定的字符集把字节解码成char所以处理纯文本时更友好代码里可以直接拿到字符串。如果你用字节流去读中文文本read()一次只返回一个字节一个中文用UTF-8编码可能占三个字节直接输出必然是一堆乱码或数字。正确做法是自己拼接字节后指定字符集解码比如FileInputStream in new FileInputStream(hello.txt); byte[] buf new byte[in.available()]; int len in.read(buf); System.out.println(new String(buf, 0, len, StandardCharsets.UTF_8));这里available()并不是一个可靠的分配依据对于文件它通常能拿到文件大小但对于网络流它只是“当前可读字节数”的估计后面还会讲到。总之选择依据可以简化成一句话处理的是文本优先字符流处理的是二进制必须字节流特殊情况需要按字节读再用编码转换就用字节流加显式字符集。我见过不少人在导出Excel时用FileWriter写结果把xlsx文件结构写坏了就是因为没有意识到Excel的底层是二进制结构不是纯文本。2.2 缓冲流到底快在哪里很多人知道加BufferedInputStream会快但说不清快在哪儿。操作系统读文件不是按你每次read的字节长度去磁盘取数而是有固定的磁盘块、页缓存。如果程序每read一次就发生一次系统调用代价会非常大。缓冲流做的事情就是向系统申请一块内存默认大小是8192字节先把一大块数据装进来你的程序每次read只跟这块内存打交道只有缓冲区空了才再次触发系统调用。用一个生活类比没有缓冲时相当于你每次去超市只买一瓶水来回跑腿有缓冲时是一趟拉回一车水后续喝水都在家里拿。所以即便你代码里写的是循环读一个字节只要外面包了BufferedInputStream底层实际也不会每次都读磁盘。这个思路同时也解释了为什么在读取大文件时不要急着用available()开一个刚好大小的数组——一次性把整个文件读进内存对大文件来说基本就是自杀。使用缓冲写流时还要注意flush()因为BufferedWriter或OutputStreamWriter在缓冲区没满时不会立刻写入目标程序正常结束时close()会兜底清理但如果写完后要立刻被另一个进程读取或者程序长期运行就必须主动flush()。2.3 转换流是乱码的“解药”乱码的根源几乎都是编码和解码用的字符集不一致。Java里的char在内存中是UTF-16编码但文件可能存成UTF-8、GBK、ISO-8859-1等。FileReader之所以容易出问题是因为它内部直接使用平台的默认字符集而且不给你指定的机会不同环境的默认字符集可能不同在开发环境正常、到服务器就乱码的情况经常发生。遇到明确编码的文件建议用InputStreamReader和OutputStreamWriter包一层显式指定字符集InputStreamReader reader new InputStreamReader(new FileInputStream(data.txt), StandardCharsets.UTF_8); OutputStreamWriter writer new OutputStreamWriter(new FileOutputStream(out.txt), StandardCharsets.UTF_8);很多老系统的文本文件是GBK编码你用UTF-8的流去读自然就出现乱码反过来你把一个UTF-8文件用GBK去写入也会出现问号或乱码。所以我排查乱码问题时先问用户两件事文件本身是什么编码代码希望它按什么编码处理两个答案不一致就是乱码的来源。记住一个原则读入时指定编码写出时也指定同样的编码中间不要依赖任何平台的“默认值”。2.4 对象流与序列化的隐藏坑ObjectOutputStream可以把一个对象直接变成字节存到文件里用起来确实省事但很多新手只记得实现Serializable接口结果改过字段后反序列化直接崩。原因就在serialVersionUID上。如果不显式声明JVM会根据类结构自动生成一个ID你一旦改了字段名、加了一个字段、或者改了类型生成的ID就变了。反序列化时新旧版本的ID对不上立刻抛InvalidClassException。解决办法有两个方向第一显式声明一个固定的serialVersionUID比如private static final long serialVersionUID 1L;。这样只要字段本身还兼容类结构变化后反序列化不会直接崩。第二想清楚哪些字段需要被序列化。static修饰的字段属于类级别不会被序列化transient字段也会被跳过。如果你在对象里放了数据库连接、Socket这类无法序列化的东西要么加transient跳过要么自定义writeObject和readObject方法做特殊处理。这一点在缓存落地、消息队列传输对象时特别重要因为生产环境里类结构是会演进的你不想因为一次发布就把历史数据全部作废。3. 实操过程与核心环节实现3.1 先定场景文件复制、日志读取、配置保存只有理论没有代码的进阶就是空中楼阁。下面我挑三个日常开发里出现频率最高的场景来演示文件复制、按行读日志、保存配置对象。这三个场景几乎覆盖了80%的IO流使用需求代码都验证过可以直接参考。文件复制是理解流读写最经典的入门题能考察你对read方法返回值、缓冲区、关闭顺序的掌握按行读日志是大数据量文本处理的基础保存配置对象则把序列化知识串起来。我建议你先不看代码自己想一遍实现方案再对照下面的写法会发现很多细节是之前没有注意到的。3.2 用字节流完成基础文件复制先用最传统的方式写一版不用任何高级特性便于理解流的本质FileInputStream in null; FileOutputStream out null; try { in new FileInputStream(source.zip); out new FileOutputStream(target.zip); byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } } finally { if (in ! null) in.close(); if (out ! null) out.close(); }这里buffer为什么选8192因为和BufferedInputStream的默认缓冲大小一致是一次性价比很高的块大小。read(buffer)的返回值是实际读到的字节数最后一次读不满缓冲区时write必须用buffer, 0, len来限定写入范围否则就会把上一次残留的无效数据一起写进去。这个细节是很多人的丢分点。外层finally里关闭流也是精心控制过的先关闭输出流再关闭输入流因为输出流的close()可能会触发最后一次flush这时候输入流还没关数据链路是完整的。其次close()本身会抛IOException这里为了示例没有继续处理实际代码里要么继续向上抛要么再包一层try-catch。尽管如此这种写法依然啰嗦还容易遗漏所以下面看升级版。3.3 用缓冲流加try-with-resources做升级版从Java 7开始try-with-resources语法可以让我们不用再手写finally关闭逻辑只要资源实现了AutoCloseable程序执行完try块后会自动调用close()。升级版代码如下try (BufferedInputStream bis new BufferedInputStream(new FileInputStream(source.zip)); BufferedOutputStream bos new BufferedOutputStream(new FileOutputStream(target.zip))) { byte[] buffer new byte[8192]; int len; while ((len bis.read(buffer)) ! -1) { bos.write(buffer, 0, len); } }这段代码和上一版效果一样但简洁得多。加了缓冲流后内部自带8KB缓冲区外部再放一个8192字节的数组意义在于减少应用层循环次数在read和write之间搬运的数据块更大。try-with-resources关闭顺序也有讲究资源声明语句中最后声明的会先关闭所以这里会先关bos再关bis符合先写后读的资源释放顺序。如果你用的是Java 7以下的旧版本没法用这个语法那就坚持finally里统一封装一个closeQuietly工具方法别让每个方法的finally都重复写一遍关闭逻辑否则代码会很丑而且容易漏。3.4 用对象流保存业务对象状态假设我们要缓存一份用户配置到本地文件对象定义为public class UserConfig implements Serializable { private static final long serialVersionUID 1L; private String userName; private String theme; private transient String password; // getter和setter省略 }为什么要加transient String password因为密码这类敏感信息最好不落盘加了transient序列化时它会自动被跳过反序列化回来是null。这种设计不是麻烦而是安全习惯。写入和读取的代码分别是try (ObjectOutputStream oos new ObjectOutputStream(new FileOutputStream(config.dat))) { UserConfig config new UserConfig(); config.setUserName(tester); config.setTheme(dark); config.setPassword(123456); oos.writeObject(config); } try (ObjectInputStream ois new ObjectInputStream(new FileInputStream(config.dat))) { UserConfig config (UserConfig) ois.readObject(); System.out.println(config.getUserName()); }注意readObject()的返回值需要强转并且它会抛出ClassNotFoundException因为反序列化要还原类信息所以签名里要处理或往上抛。这里还有一个很容易被忽略的点用Java原生序列化保存的文件对类结构变化非常敏感。如果你在后续迭代里把theme字段改个名即使serialVersionUID没变反序列化也可能出现字段缺失或类型不兼容。所以我的个人建议是如果是长周期持久化或跨系统数据交换优先考虑JSON、ProtoBuf这类可读性好、兼容性可控的方案Java序列化更适合短期的缓存和进程间通信。3.5 大文件处理按行读而不是一次性读文件上百MB甚至几个GB时千万别用Files.readAllBytes()。这个接口在JDK里确实提供了“读一个文件到字节数组”的便利但代价是文件多大内存就要多大。虚拟机默认堆可能就几百MB一个1GB的文件读一次就OOM了。正确做法是按行读只保留当前处理需要的行try (BufferedReader reader Files.newBufferedReader(Paths.get(big.log), StandardCharsets.UTF_8)) { String line; while ((line reader.readLine()) ! null) { // 处理这一行比如统计关键词、过滤异常日志 } }Files.newBufferedReader内部已经帮你包装了缓冲流所以不需要再额外套一层BufferedReader。如果还要更快可以继续深入NIO的FileChannel或内存映射文件那是另一个深度但先把按行读这个习惯养成足够避开90%的大文件OOM事故。还要提醒一点如果处理后需要把结果写回文件同样建议用BufferedWriter一行行写入不要攒一个超大字符串再一次性写。4. 常见问题与排查技巧实录4.1 流没关闭最容易被忽视的生产事故Windows上删除一个文件时提示“文件正在被另一个进程占用”排查了半天发现是代码里打开FileInputStream后没有关闭。Linux上更可怕长时间运行的服务不断打开流却不关闭最终会报Too many open files导致整个Java进程失去响应。这属于典型的资源泄漏问题看起来是系统层面的根源却在最基础的IO习惯上。解决思路永远是把关闭和打开放在同一个作用域里。现代Java直接无脑用try-with-resources就行它保证代码执行完自动关闭。如果是老代码改造优先把FileInputStream、FileOutputStream、Connection、Socket这些都纳入统一管理。我在代码评审时看到手写finally然后里面又是一个if (in ! null)就会提醒对方你不如直接改写成try-with-resources既少三行代码又不容易出错。4.2 中文乱码编码不一致造成的连锁反应乱码问题的经典场景是导出CSV文件给客户用Excel打开中文全乱。我查过一次发现代码里文件写入时用的默认编码是UTF-8而客户用的Excel老版本默认按ANSI也就是GBK解码两边对不上于是满屏都是问号。解决办法是在写入CSV时在文件开头加上BOM头或者明确约定编码为GBK再写。技术角度没有“哪种编码最好”只有“读和写两边必须保持一致”。排查的时候先用十六进制工具看文件字节再用确定的字符集解码基本能定位。还有一类情况是IDE或服务器环境的默认字符集不同。file.encoding这个系统属性在JDK 18之前默认为平台编码意味着你的代码在Windows中文版上跑可能是GBK在Linux容器里跑可能是UTF-8同样的代码换环境就乱。所以老话重提所有涉及文本的IO显式指定StandardCharsets.UTF_8不依赖默认值是成本最低的防护手段。4.3 序列化版本号不匹配InvalidClassException线上经常能看到这种异常java.io.InvalidClassException: com.example.User; local class incompatible: stream classdesc serialVersionUID 631869512346, local class serialVersionUID -756893345原因是某天你给User类加了一个字段没有声明serialVersionUID于是JVM重新算出一个新的ID。而线上还有旧的序列化数据反序列化时拿旧ID去比对新类发现不一致直接拒绝。解决办法就是给所有Serializable类都显式声明一个private static final long serialVersionUID 1L;。虽然不是万能药但至少能避免因为无关紧要的字段变化导致整体反序列化失败。如果字段被删除或类型变了即使ID一致也可能会因为数据类型不匹配而继续报错这时候就需要考虑兼容性设计不要轻易修改序列化类的结构尽量新增字段并给默认值删除字段前做好数据迁移。4.4 写了一半或读不到数据flush与读取位置我遇到过一个场景程序写日志进程没退出但日志文件里最后几条数据迟迟不出现排查发现用的是BufferedWriter缓冲区还没满数据一直留在内存里没有真正落到磁盘。解决这类问题的关键就是flush()。在使用缓冲流、转换流时凡是写入后需要立即被其他进程读取或者短时间内程序不会结束都要主动调用flush()。close()确实会帮你刷一次但你不能总指望关闭的那一刻才落盘。读取位置的问题也很容易踩文件流内部维护了一个指针read()一次就向前移动一次。如果你先读了文件一部分然后直接写写的位置是从当前指针开始的而不是从文件末尾。往现有文件追加内容时必须用FileOutputStream(file, true)第二个参数是append开关设为true才能在文件末尾追加。想灵活控制读写位置就得用RandomAccessFile它可以seek()到任意位置但操作时务必要处理好指针否则就容易出现覆盖正常数据的惨案。4.5 大文件读取导致内存溢出有同事把线上一个日志文件直接用Files.readAllBytes()读进来做字符串截取文件才80MB堆却给他炸了。表面上看是堆内存不够本质上是读取方式不适合这个量级。readAllBytes、FileUtils.readFileToString这类工具适合的是小文件不是生产日志。处理大文件要养成流式读取的习惯不要试图把整个文件同时塞进内存。我把常见故障快速整理成一张表方便你排查时对照现象可能原因解决思路文件被占用或句柄泄露流未关闭使用try-with-resources中文乱码读写编码不一致显式指定CharsetInvalidClassExceptionserialVersionUID不匹配显式声明固定ID写入数据缺失缓冲未flush或覆盖写主动flush、追加方式打开内存溢出一次性读取大文件按行读或流式处理文件内容为空写入后未close/flush调用close或flush如果让我给刚接触IO流的同学一个建议我会说别急着背API先判断数据是字节还是字符、是文件还是内存、需不需要缓冲再用装饰器一层层包上去。我在实际项目里一般会封装一个统一的FileIOUtils工具类把编码、缓冲、关闭全部收敛到工具方法里主业务代码绝不直接裸露InputStream这样既好维护也少踩很多坑。IO流的底层还有NIO、零拷贝这些更硬核的方向但把这一篇的基础打牢后面学那些内容无非就是换一批API的事。 
长河君 · 2026/10/4 14:53:16 · 阅读 1.2k Java IO流完全梳理：从体系原理到生产环境避坑指南
排查了半天的线上问题结果发现是一个日志文件的读写把整个线程池都拖垮了熬夜上线的导出功能第二天一早就被投诉中文乱码开发环境明明能读到的文件部署到服务器上却一直FileNotFoundException……这类场景我估计大多数Java开发都经历过。IO流这个知识点平时确实不起眼可一旦出了问题往往就是事故级别。我这些年带团队、做面试官发现很多人的Java IO流知识停留在会用FileInputStream和FileOutputStream的层面稍微问深一点——为什么要有缓冲流、字节流和字符流到底怎么选、serialVersionUID不写会有什么后果——就开始含糊了。这篇文章就把IO流做个完整的梳理先拆体系再讲细节给几段可以直接抄的代码最后把我在生产环境踩过的坑挨个列出来。1. 整体思路与IO流体系拆解1.1 先从四大抽象类说起要理解IO流别急着钻进那一大堆子类的命名里先把java.io包下的四个抽象类记牢InputStream、OutputStream、Reader、Writer。前两个是字节流后两个是字符流。所谓输入输出都是站在程序内存的角度说的——把数据从外部读进内存就是输入把内存里的数据写到外部就是输出。很多新人经常把方向搞反我给你一个记忆方法看方法名带read的是往程序里读带write的是从程序往外写记住这一点方向就不会错。这四个抽象类基本定义了IO流的通用行为。InputStream和Reader负责读OutputStream和Writer负责写各自的实现类通过名字里的前缀就能看出数据源或目的地。我用一张表帮你把常见的对照关系理清楚抽象类方向读写单元典型实现InputStream输入字节FileInputStreamOutputStream输出字节FileOutputStreamReader输入字符FileReaderWriter输出字符FileWriter很多人在这一步容易犯的毛病是上来就背类名背完就忘。但一旦你意识到四个抽象类就是四扇门read和write就是门上的把手后面所有类都不过是给这扇门加了不同的装饰理解起来就顺了。1.2 装饰器模式IO流强大的关键很多初学者第一次看到嵌套构造方法时直接崩溃“这包得跟俄罗斯套娃一样到底谁是谁”其实这正是Java IO流设计的精髓——装饰器模式。以文件读取为例FileInputStream负责从文件拿原始字节它本身没有缓冲能力BufferedInputStream接过这些字节在内存里开一块缓冲区减少底层系统调用次数。每一层流只关心自己这一件事组合起来就是一套完整的能力。这种设计最大的好处是可插拔。你今天想从文件读明天想从网络读只需要换最内层的数据源后面的缓冲、转换逻辑可以原封不动地复用。如果当初Java把每种能力都做成一个独立类类数量会爆炸而且每个类都要重复实现一遍底层调用。理解了这层设计你就不需要硬记每一个类只需要想清楚当前要哪几个能力然后用嵌套构造把流一层层包起来就好。在实际编码里我看到大量人混淆“继承实现”和“组合包装”就是因为没理解装饰器模式你可以把外层流当成给内层流加装备装备可以叠加但核心始终是最内层的数据源。1.3 不同数据源对应的流类型速览同样叫输入输出但数据从哪来、到哪去对应的类完全不同。我整理了一份速查面试前拿来过一遍也管用数据源/目标字节流处理二进制字符流处理文本文件FileInputStream / FileOutputStreamFileReader / FileWriter字节数组ByteArrayInputStream / ByteArrayOutputStream通过转换流配合字符串不常用StringReader / StringWriter管道PipedInputStream / PipedOutputStreamPipedReader / PipedWriter缓冲包装BufferedInputStream / BufferedOutputStreamBufferedReader / BufferedWriter对象ObjectInputStream / ObjectOutputStream不常用这类映射不用死记重点是你先判断数据形态图片、视频、压缩包这类二进制走字节流正常文本、日志、JSON走字符流。字符流本质还是字节流只不过在内部完成了字节到字符的转换所以文本场景直接用字符流能少写很多转换代码。反过来如果你用字节流处理文本就要自己处理编码问题这就是后面要讲的乱码来源之一。2. 核心细节解析与实操要点2.1 字节流和字符流选择依据与底层关系字节流按字节读取二进制数据对它来说就是一个一个字节不会做任何特殊解释所以处理图片、音视频、压缩包等二进制文件时是安全的。字符流则按字符读取内部会根据指定的字符集把字节解码成char所以处理纯文本时更友好代码里可以直接拿到字符串。如果你用字节流去读中文文本read()一次只返回一个字节一个中文用UTF-8编码可能占三个字节直接输出必然是一堆乱码或数字。正确做法是自己拼接字节后指定字符集解码比如FileInputStream in new FileInputStream(hello.txt); byte[] buf new byte[in.available()]; int len in.read(buf); System.out.println(new String(buf, 0, len, StandardCharsets.UTF_8));这里available()并不是一个可靠的分配依据对于文件它通常能拿到文件大小但对于网络流它只是“当前可读字节数”的估计后面还会讲到。总之选择依据可以简化成一句话处理的是文本优先字符流处理的是二进制必须字节流特殊情况需要按字节读再用编码转换就用字节流加显式字符集。我见过不少人在导出Excel时用FileWriter写结果把xlsx文件结构写坏了就是因为没有意识到Excel的底层是二进制结构不是纯文本。2.2 缓冲流到底快在哪里很多人知道加BufferedInputStream会快但说不清快在哪儿。操作系统读文件不是按你每次read的字节长度去磁盘取数而是有固定的磁盘块、页缓存。如果程序每read一次就发生一次系统调用代价会非常大。缓冲流做的事情就是向系统申请一块内存默认大小是8192字节先把一大块数据装进来你的程序每次read只跟这块内存打交道只有缓冲区空了才再次触发系统调用。用一个生活类比没有缓冲时相当于你每次去超市只买一瓶水来回跑腿有缓冲时是一趟拉回一车水后续喝水都在家里拿。所以即便你代码里写的是循环读一个字节只要外面包了BufferedInputStream底层实际也不会每次都读磁盘。这个思路同时也解释了为什么在读取大文件时不要急着用available()开一个刚好大小的数组——一次性把整个文件读进内存对大文件来说基本就是自杀。使用缓冲写流时还要注意flush()因为BufferedWriter或OutputStreamWriter在缓冲区没满时不会立刻写入目标程序正常结束时close()会兜底清理但如果写完后要立刻被另一个进程读取或者程序长期运行就必须主动flush()。2.3 转换流是乱码的“解药”乱码的根源几乎都是编码和解码用的字符集不一致。Java里的char在内存中是UTF-16编码但文件可能存成UTF-8、GBK、ISO-8859-1等。FileReader之所以容易出问题是因为它内部直接使用平台的默认字符集而且不给你指定的机会不同环境的默认字符集可能不同在开发环境正常、到服务器就乱码的情况经常发生。遇到明确编码的文件建议用InputStreamReader和OutputStreamWriter包一层显式指定字符集InputStreamReader reader new InputStreamReader(new FileInputStream(data.txt), StandardCharsets.UTF_8); OutputStreamWriter writer new OutputStreamWriter(new FileOutputStream(out.txt), StandardCharsets.UTF_8);很多老系统的文本文件是GBK编码你用UTF-8的流去读自然就出现乱码反过来你把一个UTF-8文件用GBK去写入也会出现问号或乱码。所以我排查乱码问题时先问用户两件事文件本身是什么编码代码希望它按什么编码处理两个答案不一致就是乱码的来源。记住一个原则读入时指定编码写出时也指定同样的编码中间不要依赖任何平台的“默认值”。2.4 对象流与序列化的隐藏坑ObjectOutputStream可以把一个对象直接变成字节存到文件里用起来确实省事但很多新手只记得实现Serializable接口结果改过字段后反序列化直接崩。原因就在serialVersionUID上。如果不显式声明JVM会根据类结构自动生成一个ID你一旦改了字段名、加了一个字段、或者改了类型生成的ID就变了。反序列化时新旧版本的ID对不上立刻抛InvalidClassException。解决办法有两个方向第一显式声明一个固定的serialVersionUID比如private static final long serialVersionUID 1L;。这样只要字段本身还兼容类结构变化后反序列化不会直接崩。第二想清楚哪些字段需要被序列化。static修饰的字段属于类级别不会被序列化transient字段也会被跳过。如果你在对象里放了数据库连接、Socket这类无法序列化的东西要么加transient跳过要么自定义writeObject和readObject方法做特殊处理。这一点在缓存落地、消息队列传输对象时特别重要因为生产环境里类结构是会演进的你不想因为一次发布就把历史数据全部作废。3. 实操过程与核心环节实现3.1 先定场景文件复制、日志读取、配置保存只有理论没有代码的进阶就是空中楼阁。下面我挑三个日常开发里出现频率最高的场景来演示文件复制、按行读日志、保存配置对象。这三个场景几乎覆盖了80%的IO流使用需求代码都验证过可以直接参考。文件复制是理解流读写最经典的入门题能考察你对read方法返回值、缓冲区、关闭顺序的掌握按行读日志是大数据量文本处理的基础保存配置对象则把序列化知识串起来。我建议你先不看代码自己想一遍实现方案再对照下面的写法会发现很多细节是之前没有注意到的。3.2 用字节流完成基础文件复制先用最传统的方式写一版不用任何高级特性便于理解流的本质FileInputStream in null; FileOutputStream out null; try { in new FileInputStream(source.zip); out new FileOutputStream(target.zip); byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } } finally { if (in ! null) in.close(); if (out ! null) out.close(); }这里buffer为什么选8192因为和BufferedInputStream的默认缓冲大小一致是一次性价比很高的块大小。read(buffer)的返回值是实际读到的字节数最后一次读不满缓冲区时write必须用buffer, 0, len来限定写入范围否则就会把上一次残留的无效数据一起写进去。这个细节是很多人的丢分点。外层finally里关闭流也是精心控制过的先关闭输出流再关闭输入流因为输出流的close()可能会触发最后一次flush这时候输入流还没关数据链路是完整的。其次close()本身会抛IOException这里为了示例没有继续处理实际代码里要么继续向上抛要么再包一层try-catch。尽管如此这种写法依然啰嗦还容易遗漏所以下面看升级版。3.3 用缓冲流加try-with-resources做升级版从Java 7开始try-with-resources语法可以让我们不用再手写finally关闭逻辑只要资源实现了AutoCloseable程序执行完try块后会自动调用close()。升级版代码如下try (BufferedInputStream bis new BufferedInputStream(new FileInputStream(source.zip)); BufferedOutputStream bos new BufferedOutputStream(new FileOutputStream(target.zip))) { byte[] buffer new byte[8192]; int len; while ((len bis.read(buffer)) ! -1) { bos.write(buffer, 0, len); } }这段代码和上一版效果一样但简洁得多。加了缓冲流后内部自带8KB缓冲区外部再放一个8192字节的数组意义在于减少应用层循环次数在read和write之间搬运的数据块更大。try-with-resources关闭顺序也有讲究资源声明语句中最后声明的会先关闭所以这里会先关bos再关bis符合先写后读的资源释放顺序。如果你用的是Java 7以下的旧版本没法用这个语法那就坚持finally里统一封装一个closeQuietly工具方法别让每个方法的finally都重复写一遍关闭逻辑否则代码会很丑而且容易漏。3.4 用对象流保存业务对象状态假设我们要缓存一份用户配置到本地文件对象定义为public class UserConfig implements Serializable { private static final long serialVersionUID 1L; private String userName; private String theme; private transient String password; // getter和setter省略 }为什么要加transient String password因为密码这类敏感信息最好不落盘加了transient序列化时它会自动被跳过反序列化回来是null。这种设计不是麻烦而是安全习惯。写入和读取的代码分别是try (ObjectOutputStream oos new ObjectOutputStream(new FileOutputStream(config.dat))) { UserConfig config new UserConfig(); config.setUserName(tester); config.setTheme(dark); config.setPassword(123456); oos.writeObject(config); } try (ObjectInputStream ois new ObjectInputStream(new FileInputStream(config.dat))) { UserConfig config (UserConfig) ois.readObject(); System.out.println(config.getUserName()); }注意readObject()的返回值需要强转并且它会抛出ClassNotFoundException因为反序列化要还原类信息所以签名里要处理或往上抛。这里还有一个很容易被忽略的点用Java原生序列化保存的文件对类结构变化非常敏感。如果你在后续迭代里把theme字段改个名即使serialVersionUID没变反序列化也可能出现字段缺失或类型不兼容。所以我的个人建议是如果是长周期持久化或跨系统数据交换优先考虑JSON、ProtoBuf这类可读性好、兼容性可控的方案Java序列化更适合短期的缓存和进程间通信。3.5 大文件处理按行读而不是一次性读文件上百MB甚至几个GB时千万别用Files.readAllBytes()。这个接口在JDK里确实提供了“读一个文件到字节数组”的便利但代价是文件多大内存就要多大。虚拟机默认堆可能就几百MB一个1GB的文件读一次就OOM了。正确做法是按行读只保留当前处理需要的行try (BufferedReader reader Files.newBufferedReader(Paths.get(big.log), StandardCharsets.UTF_8)) { String line; while ((line reader.readLine()) ! null) { // 处理这一行比如统计关键词、过滤异常日志 } }Files.newBufferedReader内部已经帮你包装了缓冲流所以不需要再额外套一层BufferedReader。如果还要更快可以继续深入NIO的FileChannel或内存映射文件那是另一个深度但先把按行读这个习惯养成足够避开90%的大文件OOM事故。还要提醒一点如果处理后需要把结果写回文件同样建议用BufferedWriter一行行写入不要攒一个超大字符串再一次性写。4. 常见问题与排查技巧实录4.1 流没关闭最容易被忽视的生产事故Windows上删除一个文件时提示“文件正在被另一个进程占用”排查了半天发现是代码里打开FileInputStream后没有关闭。Linux上更可怕长时间运行的服务不断打开流却不关闭最终会报Too many open files导致整个Java进程失去响应。这属于典型的资源泄漏问题看起来是系统层面的根源却在最基础的IO习惯上。解决思路永远是把关闭和打开放在同一个作用域里。现代Java直接无脑用try-with-resources就行它保证代码执行完自动关闭。如果是老代码改造优先把FileInputStream、FileOutputStream、Connection、Socket这些都纳入统一管理。我在代码评审时看到手写finally然后里面又是一个if (in ! null)就会提醒对方你不如直接改写成try-with-resources既少三行代码又不容易出错。4.2 中文乱码编码不一致造成的连锁反应乱码问题的经典场景是导出CSV文件给客户用Excel打开中文全乱。我查过一次发现代码里文件写入时用的默认编码是UTF-8而客户用的Excel老版本默认按ANSI也就是GBK解码两边对不上于是满屏都是问号。解决办法是在写入CSV时在文件开头加上BOM头或者明确约定编码为GBK再写。技术角度没有“哪种编码最好”只有“读和写两边必须保持一致”。排查的时候先用十六进制工具看文件字节再用确定的字符集解码基本能定位。还有一类情况是IDE或服务器环境的默认字符集不同。file.encoding这个系统属性在JDK 18之前默认为平台编码意味着你的代码在Windows中文版上跑可能是GBK在Linux容器里跑可能是UTF-8同样的代码换环境就乱。所以老话重提所有涉及文本的IO显式指定StandardCharsets.UTF_8不依赖默认值是成本最低的防护手段。4.3 序列化版本号不匹配InvalidClassException线上经常能看到这种异常java.io.InvalidClassException: com.example.User; local class incompatible: stream classdesc serialVersionUID 631869512346, local class serialVersionUID -756893345原因是某天你给User类加了一个字段没有声明serialVersionUID于是JVM重新算出一个新的ID。而线上还有旧的序列化数据反序列化时拿旧ID去比对新类发现不一致直接拒绝。解决办法就是给所有Serializable类都显式声明一个private static final long serialVersionUID 1L;。虽然不是万能药但至少能避免因为无关紧要的字段变化导致整体反序列化失败。如果字段被删除或类型变了即使ID一致也可能会因为数据类型不匹配而继续报错这时候就需要考虑兼容性设计不要轻易修改序列化类的结构尽量新增字段并给默认值删除字段前做好数据迁移。4.4 写了一半或读不到数据flush与读取位置我遇到过一个场景程序写日志进程没退出但日志文件里最后几条数据迟迟不出现排查发现用的是BufferedWriter缓冲区还没满数据一直留在内存里没有真正落到磁盘。解决这类问题的关键就是flush()。在使用缓冲流、转换流时凡是写入后需要立即被其他进程读取或者短时间内程序不会结束都要主动调用flush()。close()确实会帮你刷一次但你不能总指望关闭的那一刻才落盘。读取位置的问题也很容易踩文件流内部维护了一个指针read()一次就向前移动一次。如果你先读了文件一部分然后直接写写的位置是从当前指针开始的而不是从文件末尾。往现有文件追加内容时必须用FileOutputStream(file, true)第二个参数是append开关设为true才能在文件末尾追加。想灵活控制读写位置就得用RandomAccessFile它可以seek()到任意位置但操作时务必要处理好指针否则就容易出现覆盖正常数据的惨案。4.5 大文件读取导致内存溢出有同事把线上一个日志文件直接用Files.readAllBytes()读进来做字符串截取文件才80MB堆却给他炸了。表面上看是堆内存不够本质上是读取方式不适合这个量级。readAllBytes、FileUtils.readFileToString这类工具适合的是小文件不是生产日志。处理大文件要养成流式读取的习惯不要试图把整个文件同时塞进内存。我把常见故障快速整理成一张表方便你排查时对照现象可能原因解决思路文件被占用或句柄泄露流未关闭使用try-with-resources中文乱码读写编码不一致显式指定CharsetInvalidClassExceptionserialVersionUID不匹配显式声明固定ID写入数据缺失缓冲未flush或覆盖写主动flush、追加方式打开内存溢出一次性读取大文件按行读或流式处理文件内容为空写入后未close/flush调用close或flush如果让我给刚接触IO流的同学一个建议我会说别急着背API先判断数据是字节还是字符、是文件还是内存、需不需要缓冲再用装饰器一层层包上去。我在实际项目里一般会封装一个统一的FileIOUtils工具类把编码、缓冲、关闭全部收敛到工具方法里主业务代码绝不直接裸露InputStream这样既好维护也少踩很多坑。IO流的底层还有NIO、零拷贝这些更硬核的方向但把这一篇的基础打牢后面学那些内容无非就是换一批API的事。