做Java开发这些年IO流是绕不开的一座山。你刚接触时觉得它抽象学了一段时间又觉得它琐碎什么字节流、字符流、InputStream、Reader名目繁多。但你真正吃透这套体系之后会发现它不过就那几根柱子数据从哪里来到哪里去中间如何编码如何缓冲。这篇总结我会从实战层面把Java IO流的骨架拆开重点讲字节流和字符流的读写艺术覆盖从底层FileInputStream到上层BufferedReader的完整链路也把面试里常见的高频考点串一遍。适合正在准备Java面试的人也适合写业务代码时总和文件读写较劲的朋友。1. 重新认识流字节与字符背后的两种世界观1.1 把数据想象成水流一切就通顺了流Stream这个概念刚接触的人总觉得不太好理解。我常用的教学方法是把它想象成水管数据传输就像水流从源头流到目的地水管本身是管道数据就是里面的水。InputStream/Reader负责把水从水管里接出来OutputStream/Writer负责把水灌进去方向永远是单向的。这个类比能解释很多问题。为什么流用完必须关你水管不关阀门水就会一直流或者存起来占用资源。为什么流不能回头读已经读过的位置因为你接走的那部分水已经进了你的杯子没法倒回水管里。如果想要来回随机读写得用RandomAccessFile那一类支持指针跳转的接口普通流是不支持的。流的另外两个基础特性也很重要数据和磁盘/网络交互时底层永远按块传输不会一个字节一个字节地慢慢挪而Java API暴露给我们的read/write方法其实是对底层设备的一次抽象封装你每次调用都可能触及一次系统调用。正是这一点引发了后文要重点讨论的性能问题。1.2 四个抽象基类撑起整个IO江山Java IO体系的根是四个抽象类InputStream、OutputStream、Reader、Writer。这四位一出场就把IO世界分成了两派字节派和字符派。家族抽象基类读写最小单位典型场景核心方法字节流InputStream / OutputStream1个字节8位图片、音频、视频、压缩包、任意二进制文件int read() / void write(int b)字符流Reader / Writer1个字符Java内部以UTF-16编码单元为主文本文件、日志文件、配置文件、报文处理int read() / void write(int c)能把这个表背下来至少能应付面试中的第一层问题。但光背表不够你还要理解为什么read()返回的是int而不是byte。这里有个很关键的设计InputStream需要返回-1来表示“流已经读到底了”如果API设计成返回byte范围是-128到127没法天然表达“结束”这个语义。所以设计者把读取结果放宽到int低8位是真正的数据高24位补零读到结尾时返回-1。这个细节很多人写了很多年代码都没留意但面试官最喜欢考。1.3 为什么要拆成字节流和字符流两套API一句话回答因为文本有编码问题。同一个字符在不同的字符集里占用的字节数不一样。比如英文字母’A’在UTF-8下占1个字节中文的’你’在UTF-8下占3个字节在GBK下占2个字节。如果让你直接用字节流去读文本文件你得自己处理“哪些字节拼成一个完整字符”的边界问题稍不留神就把一个多字节字符切成两半出来的就是乱码。字符流则把这一层复杂度封装掉了。你只管调用read()拿到一个个字符内部解码器会按指定字符集把字节正确地拼装成字符。换句话说字符流不是另一种独立的数据通道而是在字节流之上加了一个“翻译层”。这个翻译层就包括InputStreamReader和OutputStreamWriter它俩是字节世界和字符世界之间的桥梁后文会专门展开。2. 从最基础的文件读写下手四个类的实战拆解2.1 FileInputStream和FileOutputStream全文件类型通吃的底层选手文件读写最朴实的方式就是建立在FileInputStream和FileOutputStream上的。FileInputStream从文件里读字节适合处理图片、视频、压缩包这类完全不需要转换成字符的内容原样读、原样写最安全。下面这段代码是拷贝文件的典型写法try (InputStream in new FileInputStream(source.bin); OutputStream out new FileOutputStream(dest.bin)) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } }这里有三个地方值得展开说。第一缓冲区为什么选8192因为8KB是个非常流行的折中值既不会导致太多次系统调用又不会占用太多内存。我实测过用1KB缓冲区比8KB明显慢一截继续升到64KB收益反而不大属于边际递减。很多开源框架和JDK内部实现也常用8KB这样一个块大小说明这个数字经得起实践考验。第二write(buffer, 0, len)里这个len很关键。最后一次读取时缓冲区很可能没装满如果直接out.write(buffer)会把buffer尾部残留的旧数据也写进文件导致文件末尾出现脏字节。正确做法是只写出这一次实际读取的长度。第三try-with-resources的写法会让关闭资源的代码极度简洁。Java 7以前这种代码要写嵌套的try-finally麻烦且容易漏关现在靠一个带资源的try块就全部搞定了。如果项目还在用老旧写法强烈建议顺手重构。2.2 FileReader和FileWriter写文本时最省心的入门APIFileReader和FileWriter是字符流里最直接的入口。FileReader内部把FileInputStream和InputStreamReader组合起来默认按平台字符编码去解码FileWriter同理按平台默认编码去编码。这一段看起来很省事但暗藏一个非常经典的天坑平台默认编码。在中文版Windows上JVM默认字符编码通常是GBK在Linux服务器上通常是UTF-8。如果你用FileReader读一个UTF-8编码的文件Windows上就会乱码。如果你用FileWriter写文件在当前机器上一切正常文件拿到别的机器打开或者提交到Git后再拉下来构建中文就变成问号。所以我的个人铁律是项目里写文本文件绝不直接用FileWriter也不会依赖“默认编码”干活而是组合InputStreamReader/OutputStreamWriter并显式指定StandardCharsets.UTF_8或者直接用后文讲到的Files工具类。只把FileReader/FileWriter当成学习阶段的入门例子不带上生产环境。2.3 资源关闭释放得漂亮才是生产级代码很多入门教程会写这种代码FileInputStream in new FileInputStream(data.txt); // 读文件... in.close();看起来没毛病但实际上问题很大。如果读取过程中抛出IOException代码会直接退出close()根本执行不到文件句柄就泄漏了。频繁触发这种问题最终会出现“Too many open files”之类的错误。老练的写法是这样的InputStream in null; try { in new FileInputStream(data.txt); // 读文件... } catch (IOException e) { log.error(读取失败, e); } finally { if (in ! null) { try { in.close(); } catch (IOException e) { log.error(关闭失败, e); } } }多了一层finally保证“无论正常还是异常都会尝试关闭”。这个模式本身是对的但代码啰嗦程度肉眼可见。我在第6节会详细讲try-with-resources怎么把这个样板代码压缩成一行同时还能保证关闭顺序正确。3. 字节转字符的桥梁InputStreamReader与OutputStreamWriter3.1 为什么必须要有桥现实很直接磁盘上存的是字节网络传输的是字节图片是字节串文本文件本质上也是字节串。但业务处理文本时我们希望按字符来理解一个’你’一个’我’而不是三个字节加一个字节。中间这个从字节到字符的“翻译官”就是InputStreamReader和OutputStreamWriter。看这段代码InputStream fileIn new FileInputStream(article.txt); Reader reader new InputStreamReader(fileIn, StandardCharsets.UTF_8);这就是字节流与字符流的“握手”。我给了它一个FileInputStream同时告诉它“按UTF-8来翻译”。之后每次调用reader.read()得到的就是已经解码好的字符。同理写出方向用OutputStreamWriter把字符按编码规则编码成字节再交给底层字节流写走。有趣的是FileReader其实就是把上面这个组合简化了。它等于“FileInputStream InputStreamReader且使用JVM默认编码”。所以看字节码或源码时你会发现FileReader并没有做很多额外的事情它只是个“方便但不推荐指定编码”的便捷入口。3.2 编码参数选错等着你的就是乱码乱码的本质一句话可以概括写入时用的字符集和读取时用的字符集不一致。举个我在实际项目中遇到的例子线上有个Excel导出功能开发在Windows本地用默认编码GBK写出了csv文件上传到Linux服务器后由另一个模块读取。结果那个模块用UTF-8解析中文标题全部成了“???”。定位过程掰扯了很久最后发现根本不是解析逻辑的问题就是编码中途被默认值绑架了。所以生产环境的文本IO必须显式指定字符集不能信任任何默认值。Java 8以后有现成的StandardCharsets.UTF_8常量直接传这个常量比写字符串UTF-8更安全因为字符串拼写错误会在运行时才暴露。Java 8之前的项目可以用Charset.forName(UTF-8)效果一样。3.3 组装一条全链路文件 → 字节流 → 桥 → 字符流 → 缓冲流生产环境里读文本文件最经典的一条链是这样try (BufferedReader reader new BufferedReader( new InputStreamReader( new FileInputStream(log.txt), StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { System.out.println(line); } }从里往外看FileInputStream负责把文件打开并读取字节InputStreamReader负责把字节按UTF-8解码成字符BufferedReader负责提供缓冲并支持按行读取。每层只干一件事职责非常清楚。这种套娃结构后来很多人第一次接触时会觉得繁琐但你把它拆开看就是“底层字节流被翻译层包住再被性能增强层包住”一层层叠上去而已。有人会问直接用Files.newBufferedReader(Path, Charset)不是更短吗确实更短那是JDK后来提供的快捷方法内部干的也是这么一件组合的事。理解底层之后工具类在眼里就透明了。4. 缓冲流JDK的装饰器模式让IO性能翻倍4.1 装饰器模式流上套流的设计玄机Java IO从早期Java 1.0到今天BufferedInputStream这种类一直存在核心思想就是装饰器模式。所谓装饰器就是构造时包住另一个同族对象然后在方法调用上做增强。看这行代码InputStream in new BufferedInputStream(new FileInputStream(data.bin));BufferedInputStream包住了FileInputStream。当你调用in.read()时它不会直接把这次请求交给FileInputStream去读磁盘而是先检查自己的内部缓冲区。缓冲区里有数据就直接从内存返回缓冲区空了才一次性把一大块字节从磁盘灌进缓冲区。这样你的应用代码每次read()都很快真正的磁盘IO被攒成次数很少的大块操作。为什么装饰器模式在这里如此合适因为它避免了“为每种场景创建专属类”的灾难。假如没有这种组合设计你想“带缓冲的文件读取”要写一个BufferedFileInputStream想“带缓冲的数组读取”要写一个BufferedByteArrayInputStream想“带缓冲的网络读取”又要写一个BufferedSocketInputStream类爆炸就来了。而组合设计让你任意搭配想缓冲就套一层想加个“按行读”能力就再套一层灵活得可怕。4.2 BufferedWriter和BufferedReader的实战价值BufferedReader身上有一项几乎人人每天在用的能力readLine()。按行处理日志、解析CSV、读取SQL脚本用readLine()比手动处理单个字符舒服得多。搭配上面那条链路读一个典型的多行文本文件就是两三行代码的事。try (BufferedReader reader Files.newBufferedReader(Paths.get(app.log), StandardCharsets.UTF_8)) { String line; while ((line reader.readLine()) ! null) { // 逐行处理 } }BufferedWriter也是同样的道理。你先写几个字符进去它不会立刻把每个字符都刷新到磁盘而是攒在内存缓冲区里到一定大小再统一写出。这样连续几百行write()实际磁盘IO次数非常少。但要注意两个坑第一close()会先执行flush()把缓冲区内容全部写出所以程序结束前一定要关闭缓冲流否则可能丢数据。如果不想关闭流但想把数据先送到下游就调用flush()这在长连接场景尤其常见。第二newLine()方法写的是当前系统默认换行符Windows是\r\nLinux是\n。如果生成的日志或文件要跨平台阅读最好明确指定你所期望的换行风格否则不要假设Windows上生成的文本在Linux上看起来永远一样规矩。4.3 性能实测对比别再说Java IO慢很多人有“Java IO慢”的刻板印象。我拿一个约200MB的文件做过复制实验用不同写法记录大致耗时结果如下写法大致耗时说明单字节FileInputStream.read()循环15~20秒每次读都触发系统调用最差手动byte[8192]循环0.2~0.4秒性能优秀成本低BufferedInputStream包一层0.3~0.5秒和字节数组方案接近代码直观Files.copy()0.1~0.3秒封装完善简单场景首选我没有追求精确的数显因为不同硬件差异很大但这个量级对比基本稳定。核心结论非常明确IO性能瓶颈往往不是Java本身而是你调用了多少次底层IO。一次读一个字节等于每次都向操作系统索取一次读8KB等于把索取次数缩小了八千倍。理解这一点以后你再看网上那些“Java IO慢”的抱怨多半都是一次读一个字节或者没用缓冲流的锅。5. 序列化与数据流把对象和基础类型写进磁盘5.1 ObjectOutputStream和ObjectInputStream对象也有存档时刻有时候我们需要把Java对象保存到磁盘或网络传给对方这就要用到序列化。ObjectOutputStream可以把一个实现了Serializable接口的对象转换成字节序列ObjectInputStream则负责反序列化还原对象。// 对象写到文件 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(); }这里有个经典考点Serializable接口里面一个方法都没有它凭什么起作用它是Java的一个标记接口作用相当于告诉JVM“这个类的对象允许被序列化机制处理”。真正干活的ObjectOutputStream会去检查这个标记如果没有实现SerializablewriteObject()会直接抛NotSerializableException。另外serialVersionUID这个字段经常被问到。如果你不显式声明JVM会根据类的结构计算一个默认值。一旦类的代码发生变化比如新增一个字段重新编译后这个默认UID就可能变化旧文件反序列化时会报InvalidClassException。所以我们声明的serialVersionUID等于是一个稳定版本号控制了“什么版本之间互相兼容”的边界。5.2 DataInputStream和DataOutputStream按Java原生格式读写DataInputStream和DataOutputStream是字节流家族的另一组玩家专门按Java原始数据类型来读写。你写入一个int它就按4字节固定格式写写入一个UTF字符串它先写2字节长度再写内容字节。这样写出来的二进制文件可以被Java程序精确无歧义地读回。try (DataOutputStream dos new DataOutputStream(new FileOutputStream(score.dat))) { dos.writeInt(100); dos.writeUTF(张三); } try (DataInputStream dis new DataInputStream(new FileInputStream(score.dat))) { int score dis.readInt(); String name dis.readUTF(); }这套机制在需要自定义轻量级文件格式时很管用比如游戏存档、设备通信协议里的基础数据层。但要留意它和外部系统的兼容性DataOutput写入的数据不属于通用文本格式Java以外的语言读取时需要手动拆分不像JSON那样到处都能解析。所以跨语言场景不建议用这个只有两边都是Java生态或者协议明确约定时才好使。5.3 序列化过程的注意事项与坑第一序列化对象里不能有不可序列化的字段如果某个成员变量没实现Serializable序列化会失败。解决办法是给该字段加transient关键字表示“序列化时忽略我”。这个关键字面试里出现频率也很高答案就是“防止这个字段被序列化”。第二序列化版本兼容很微妙。你在旧版本里写出的文件新版本想直接反序列化成新对象只要类名和serialVersionUID没变Java允许新增字段新字段会得到默认值。但如果你删除了字段、改变字段类型、把非静态字段改成静态都不安全最好通过实际测试确认哪些改动会影响历史数据。第三千万别把密码、密钥等敏感字段放进序列化对象因为序列化后的二进制文件可以被反编译工具还原字段内容transient只能帮你跳过序列化不能帮你做加密。真正需要保密的数据要经过加密后再写入。6. 紧跟时代的IO写法NIO、Files与try-with-resources6.1 try-with-resources资源关闭的优雅实践Java 7开始引入try-with-resources配合AutoCloseable接口让“自动关闭”成为一种语言级的能力。它的写法就是把资源创建放在try后的括号里代码块结束时无论成功失败所有声明过的资源都会按逆序调用close()。try (InputStream in new FileInputStream(a.txt); OutputStream out new FileOutputStream(b.txt)) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } }这个写法的好处显而易见不用自己写finally不用嵌套try-catch代码短到接近go语言风格。它还专门处理了“try块里抛异常时close()又抛异常”的叠加问题会以主异常为主关闭时的异常会被附加到 suppressed 列表里这个细节很多人不知道。如果项目中还有大量手写finally关流的代码强烈建议顺手改成try-with-resources。它不只是代码风格问题更是减少资源泄漏事故的实用手段。6.2 Files工具类读文件也可以如此简洁Java 7的NIO.2带来了一大堆关于路径和文件的工具方法其中Files类对日常读写的简化非常明显。以前写个“读整个文件内容”要循环半天现在一句话byte[] allBytes Files.readAllBytes(Paths.get(data.txt)); String content new String(allBytes, StandardCharsets.UTF_8);或者按行读ListString lines Files.readAllLines(Paths.get(config.txt), StandardCharsets.UTF_8);再或者复制文件Files.copy(Paths.get(source.log), Paths.get(target.log), StandardCopyOption.REPLACE_EXISTING);很明显这些方法是面向简单场景的“一键工具”极大减少了样板代码。但有一点要警醒readAllBytes会把整个文件一口气读进内存小配置文件无所谓几百MB的大文件千万别这么写会直接OOM。大文件要逐块处理或用缓冲流按行消费而不是图省事一把梭。6.3 NIO快速认知Channel、Buffer和SelectorJava NIONew IO是另一套并行体系和传统IO家族不是替换关系而是不同场景的选择。NIO三件套是Channel、Buffer、Selector。Channel是双向通道可以同时读写Buffer是数据容器读写时先装满Buffer再处理Selector让一个线程能同时管理多个通道适合网络高并发场景。FileChannel channel FileChannel.open(Paths.get(data.txt), StandardOption.READ); ByteBuffer buffer ByteBuffer.allocate(1024); int bytesRead channel.read(buffer);日常文件读写其实不一定要用NIO传统IO配合缓冲流已经很高效。NIO的价值更多体现在网络编程、Reactor模型、代理、中间件这类需要支撑大量连接的高并发系统里。面试中对NIO的理解至少要知道Channel/Selector的历史定位以及什么时候才需要引入它。7. 高频面试题与避坑清单7.1 面试题速答Q1字节流和字符流有什么区别底层都是操作字节。字符流是在字节流之上增加了编码/解码层专门处理文本。字节流适合任何格式的二进制内容字符流适合文本内容并且在底层自动处理多字节字符的边界问题。Q2字节流可以读取中文文本吗可以但读出来的是字节不会自动把多字节字符拼成一个完整的Char。你要自己按字符集规则解码容易踩到半个中文的坑。专业做法是用字符流。Q3为什么InputStream的read()返回int而不是byte因为要返回-1表示EOF文件结束。如果返回byte永远无法在取值范围内表达“数据已经读完”这个状态。int的低8位才是真正读到的字节。Q4FileReader为什么可能乱码因为它默认使用JVM平台编码在Windows上可能是GBK在Linux上可能是UTF-8。要稳定不乱码就要显式指定StandardCharsets.UTF_8组合InputStreamReader或Files.newBufferedReader。Q5Serializable接口是空的为什么实现它就能序列化它是标记接口作用是声明“这个类的对象可以被序列化机制处理”。真正干活的是ObjectOutputStream它会检查这个标记没有实现就抛NotSerializableException。我们在类里声明的serialVersionUID用于控制反序列化的版本兼容性。7.2 实战避坑清单第一不要用FileWriter写中文。你的开发机可能是GBK线上机器可能是UTF-8环境一变日志全乱。凡涉及文本写出请显式指定字符集。第二文件名和路径不要硬编码成反斜杠\。Windows用反斜杠Linux用斜杠。建议用Paths.get()或者直接写相对路径让它自动适应当前系统。第三大文件不要用readAllBytes()。文件如果几百MB一次全读进内存GC压力巨大甚至还可能OOM。用带缓冲的Reader逐行处理或自己分块读。第四避免一次read()一个字节。性能差异能从十几秒拉到零点几秒这一点值得写进团队代码规范。第五流一定要关但请用try-with-resources而不是手动finally避免有人忘了写内层try或者关流的代码又抛异常。7.3 踩过几次坑之后我的总结在我经手的多个项目的维护中IO相关的线上问题往往不是复杂的技术难题而是最简单的基础疏忽默认编码没指定、大文件一次性读入内存、关流语句放在了异常分支之后等等。每次复盘原因都觉得很“低级”但发生在现场就是真实的故障。我个人现在的习惯是文本IO一律显式UTF_8文件读写优先考虑Files工具类做简洁方案大文件一律BufferedReader配InputStreamReader逐行处理二进制数据统一BufferedInputStream配合固定大小byte[]。这套组合既简单又不容易踩坑还被很多代码评审接受了。你如果从今天开始按照这个套路来写Java IO相信能少熬很多个因乱码和文件占用而生的夜。