很多Java开发者在刚接触IO流时都会被那一大堆InputStream、OutputStream、Reader、Writer搞得晕头转向。字节流作为整个Java IO体系的基石其实搞清楚它后面很多东西都能串起来。这篇文章我会从实际使用的角度出发把字节流掰开揉碎讲清楚覆盖原理、实操、性能优化和排坑经验希望对正在学这块的朋友有帮助。1. 字节流到底是什么——先从底层逻辑说起1.1 计算机里一切皆字节首先要建立一个直觉不管你的文件是TXT文档、图片、视频、压缩包还是Excel表格在磁盘上存储时本质上都是一连串的字节。每一个字节是8位二进制数取值范围从0到255。数据一旦进入内存或网络传输也是以字节为单位流动的。所以字节流本质上就是程序与数据源之间以字节为单位进行数据传输的通道。我用一个生活中比较容易理解的例子来说明。你网购了一个包裹快递小哥把包裹送到你手上你打开包裹取出里面的东西。字节流里的InputStream就相当于收快递的动作把数据从某个源头文件、网络、内存等搬运到程序里。OutputStream则相当于寄快递的动作把程序里的数据写到某个目标去。而搬运的最小单位就是字节。1.2 为什么需要字节流可能有人问既然有了字符流Reader/Writer处理文本挺方便的为什么还要字节流答案是字符流只能处理文本数据而字节流可以处理一切数据。图片的二进制数据你没法用Reader去读视频文件也不能用Writer去写。字节流是万能的底层方案字符流只是在字节流之上做了一层编码解码的封装。凡是涉及图片、音视频、压缩包、序列化对象或者任何不纯文本格式的数据都必须用字节流来处理。即使你只处理文本底层也是通过字节流从磁盘读入数据再交给字符流解码为字符。可以说没有字节流Java的IO体系就塌了一半。2. 核心骨架继承体系与设计思路2.1 两大抽象父类字节流的核心是四个抽象类InputStream、OutputStream、Reader、Writer。其中前两个就是字节流的顶层抽象。InputStream负责定义字节输入的行为它有几个关键方法read()读取一个字节返回0到255的int值读到末尾返回-1read(byte[] b)读取一批字节到数组中返回实际读取的字节数read(byte[] b, int off, int len)读取最多len个字节到数组指定位置close()关闭流释放底层资源OutputStream对应定义了字节输出的行为write(int b)写入一个字节write(byte[] b)写入整个字节数组write(byte[] b, int off, int len)写入字节数组的一部分flush()将缓冲区的数据强制刷新到目标close()关闭流释放底层资源注意到read()和write(int b)的参数和返回值都是int而不是byte为什么因为read()需要返回-1这个特殊值来表示流已结束而byte类型无法表示-1。write(int b)接收int参数但实际只使用低8位多余的位会被丢弃。这一点很多人刚开始容易搞混。2.2 常用的字节流实现类继承体系看起来庞大但实际工作中用到的主要就是这几个FileInputStream和FileOutputStream文件字节流最基础的磁盘读写工具。BufferedInputStream和BufferedOutputStream缓冲字节流内部维护一个缓冲区能显著减少系统调用次数提升读写性能。后面性能优化部分会展开讲。DataInputStream和DataOutputStream数据字节流允许直接读写Java基本数据类型int、double、boolean等常用于需要保存结构化二进制数据的场景。ObjectInputStream和ObjectOutputStream对象字节流用于Java对象的序列化和反序列化也就是把对象变成字节永久保存或网络传输。ByteArrayInputStream和ByteArrayOutputStream内存字节流数据源是内存中的字节数组多用于同一进程内的数据中转。它们各自的职责不同但都是围绕那一组read/write方法在做文章。理解了顶层抽象再去看任何一个实现类都能快速上手。3. 读写文件的实操演练——从低效到高效3.1 第一个版本单字节读写先用最原始的方式实现一个文件复制功能把data.bin的内容复制到copy.bin。import java.io.FileInputStream; import java.io.FileOutputStream; public class SingleByteCopy { public static void main(String[] args) throws Exception { FileInputStream input new FileInputStream(data.bin); FileOutputStream output new FileOutputStream(copy.bin); int data; while ((data input.read()) ! -1) { output.write(data); } input.close(); output.close(); } }这段代码逻辑完全正确read()每次读一个字节读到末尾返回-1退出循环write()把字节写出去。但性能极其糟糕。每读一个字节就发起一次系统调用磁盘会在用户态和内核态之间来回切换。我做过一个粗略的测试复制一个100MB的文件单字节读写需要大约好几秒而用缓冲流只需要几百毫秒差距可以达到一个数量级。3.2 第二个版本字节数组批量读写既然单字节慢那就批量读。用read(byte[])方法每次读取一整个数组的数据。import java.io.FileInputStream; import java.io.FileOutputStream; public class BufferArrayCopy { public static void main(String[] args) throws Exception { FileInputStream input new FileInputStream(data.bin); FileOutputStream output new FileOutputStream(copy.bin); byte[] buffer new byte[8192]; int len; while ((len input.read(buffer)) ! -1) { output.write(buffer, 0, len); } input.close(); output.close(); } }这一改性能立刻好上不少。为什么因为系统调用的次数大大减少了。假设文件100MB缓冲区8KB循环只需要执行大约12800次与之前的1亿次相比是天壤之别。需要注意的是write时必须带上len这个参数。如果直接写output.write(buffer)会把整个8KB数组写出去但最后一次读取可能根本填不满缓冲区导致文件尾部出现多余数据。3.3 第三个版本缓冲流的正确用法实际开发中更省心的做法是直接用BufferedInputStream和BufferedOutputStream。它们内部默认维护一个8192字节的缓冲区自动帮我们完成批量读写。import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.FileInputStream; import java.io.FileOutputStream; public class BufferedCopy { public static void main(String[] args) throws Exception { try (BufferedInputStream input new BufferedInputStream(new FileInputStream(data.bin)); BufferedOutputStream output new BufferedOutputStream(new FileOutputStream(copy.bin))) { byte[] buffer new byte[1024]; int len; while ((len input.read(buffer)) ! -1) { output.write(buffer, 0, len); } } } }注意这种写法用的是try-with-resources语法流会在try块结束后自动关闭不用手动close代码也简洁了很多。有人可能会问既然缓冲流内部已经有8KB缓冲区了我为什么还额外声明一个byte[1024]原因在于缓冲流默认的read(byte[])方法会一次性尝试填满你传入的整个数组。如果你直接不传数组用input.read()一次拿一个经过内部缓冲的数据效果也还行。但更稳妥高效的做法是配合一个大小合适的字节数组一起用。数组取1024到8192之间都是合理的再大也不会有明显提升。3.4 关于flush和close的冷门细节在写文件时输出流的write操作先写入内存缓冲区真正落到磁盘需要触发flush。缓冲流在缓冲区满了之后会自动flush但如果你在写完后立即关闭程序或读取文件可能有一部分数据还在缓冲区里没落盘。调用close()方法时JVM会先执行一次flush再释放资源所以一般情况下你不需要手动调用flush。唯一需要手动flush的场景是长连接的网络通信比如你写了一个服务端程序要向客户端发送一条消息后等待对方回应这时必须手动flush否则数据会一直堵在缓冲区里双方就此死等。我再补充一个踩过的坑如果使用try-with-resources多个流的关闭顺序是严格按照声明顺序逆序进行的。也就是说先关闭外层的缓冲流再关闭内层的文件流。这其实是好事因为关闭外层流时会先刷新缓冲区确保数据全部写入再关闭底层文件流完美避免了先关底层导致数据丢失的问题。4. 字节流与字符流的边界——什么场景该用哪个4.1 乱码问题的根源很多新手用InputStream读文本文件结果读到中文出现乱码一脸懵。原因很简单英文和数字在UTF-8编码下占1个字节中文占3个字节生僻字甚至占4个。如果你用单字节方式去读一个中文字被切成了3个片段每个片段都变成了无意义的乱码符号。字符流就是为解决这个问题而生的。它以字符为单位读取数据内部通过指定的字符集比如UTF-8、GBK将字节解码成字符。但要注意字符流只是看起来处理的是字符底层依然依赖字节流在进行实际的物理I/O操作。InputStreamReader就是连接字节流和字符流的桥梁import java.io.FileInputStream; import java.io.InputStreamReader; public class BridgeDemo { public static void main(String[] args) throws Exception { try (FileInputStream fileInput new FileInputStream(note.txt); InputStreamReader reader new InputStreamReader(fileInput, UTF-8)) { char[] buffer new char[1024]; int len; while ((len reader.read(buffer)) ! -1) { System.out.println(new String(buffer, 0, len)); } } } }4.2 选择清单我根据自己的开发经验整理一个简洁的选择清单二进制数据图片、视频、压缩包、序列化对象用字节流。这是死规矩字符流根本处理不了。纯文本数据TXT、JSON、XML、日志文件用字符流。推荐FileReader/FileWriter或者BufferedReader/BufferedWriter。如果文件较小甚至可以直接用Files.readAllLines。不确定数据到底是什么格式时先用字节流后续再探测或者解析。网络传输中Socket通信的底层也是字节流。你接收到的原始数据一定是字节数组再根据具体协议判断如何解码成文本或对象。4.3 一个小案例复制文本文件到底用什么如果只是复制一个文件不管目标是什么类型直接复制字节是最稳的。因为你不需要关心文件内容如何解析只需要原样搬运。但如果需要读取文件内容做处理比如统计某个关键词出现的次数就必须用字符流并指定正确的编码集了。举个例子用Files类几行代码就能完成文本文件的按行读取import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.util.List; public class ReadAllLines { public static void main(String[] args) throws Exception { Path path Paths.get(note.txt); ListString lines Files.readAllLines(path, java.nio.charset.StandardCharsets.UTF_8); for (String line : lines) { System.out.println(line); } } }这种方式适合中小文件。如果文件很大比如几个GB的日志一次性读入内存会直接OOM。这时候还是得回到流式读取用BufferedReader逐行处理。5. 从文件到网络——字节流在真实项目中的典型玩法5.1 文件复制之外加密与解密的字节操作字节流不只是简单地搬运数据。既然所有数据对字节流来说都只是一个个字节我们完全可以在搬运过程中加入一些逻辑实现简单的加密效果。比如用一个XOR异或运算做位级别的混淆import java.io.*; public class XorEncrypt { private static final byte KEY 0x5A; public static void process(String src, String dst) throws Exception { try (BufferedInputStream input new BufferedInputStream(new FileInputStream(src)); BufferedOutputStream output new BufferedOutputStream(new FileOutputStream(dst))) { byte[] buffer new byte[8192]; int len; while ((len input.read(buffer)) ! -1) { for (int i 0; i len; i) { buffer[i] ^ KEY; } output.write(buffer, 0, len); } } } }同一个方法执行两次第一次是加密第二次就解密了因为XOR运算具有对称性。这种处理方式展现了字节流的核心优势你可以在字节层面做任意变换而无需关心数据本身的结构。当然这只是演示真实加密算法要复杂得多。5.2 对象持久化对象流让Java对象可保存字节流还能让Java对象变成一串字节保存到磁盘或网络上传输这个过程叫序列化。看个简单例子import java.io.*; class User implements Serializable { private static final long serialVersionUID 1L; private String name; private int age; User(String name, int age) { this.name name; this.age age; } Override public String toString() { return User{name name , age age }; } } public class ObjectStreamDemo { public static void main(String[] args) throws Exception { User user new User(若川, 28); try (ObjectOutputStream oos new ObjectOutputStream(new FileOutputStream(user.obj))) { oos.writeObject(user); } try (ObjectInputStream ois new ObjectInputStream(new FileInputStream(user.obj))) { User restored (User) ois.readObject(); System.out.println(restored); } } }序列化这块有几个坑必须提一下。第一被序列化的类必须实现Serializable接口这是一个标记接口没有需要实现的方法。第二类里面有一个serialVersionUID字段如果漏写了编译器会随机生成一个。此后一旦类的结构发生了改变比如新增一个字段serialVersionUID就会变化导致反序列化时抛InvalidClassException。所以规范做法是显式声明serialVersionUID并保持它不变。第三用transient关键字标记的字段不会被序列化适合放密码、敏感信息等不需要持久化的数据。5.3 网络传输Socket里的字节流网络通信中也到处是字节流。操作系统的Socket接口只认字节Java的Socket封装后底层依然是InputStream和OutputStream。下面给出一个极简的客户端发送数据到服务端的示例import java.io.*; import java.net.Socket; public class SocketClient { public static void main(String[] args) throws Exception { try (Socket socket new Socket(127.0.0.1, 8080)) { OutputStream output socket.getOutputStream(); String message Hello, Server; output.write(message.getBytes(UTF-8)); output.flush(); } } }这里write的是byte数组由String的getBytes方法将文本编码为字节。网络传输场景下flush非常重要不写flush数据可能一直停留在客户端操作系统缓冲区迟迟发不出去。服务端接收时也需要按字节读入再解码为字符串。这里的缓冲设计、半包粘包处理等等就涉及到更高阶的Netty框架了但底层依然脱离不开字节流这个基础概念。5.4 内存中的字节流小工具里的常客ByteArrayOutputStream非常适合在内存中拼接数据它不需要操作磁盘或网络完全在内存中操作容量可以动态增长。比如想快速拼接一组字节时可以这样import java.io.ByteArrayOutputStream; public class ByteArrayDemo { public static void main(String[] args) throws Exception { ByteArrayOutputStream output new ByteArrayOutputStream(); output.write(Hello.getBytes(UTF-8)); output.write(0x20); // 空格 output.write(World.getBytes(UTF-8)); byte[] result output.toByteArray(); System.out.println(new String(result, UTF-8)); } }这个类在生成HTTP响应体、拼接协议报文等场景中经常扮演工具角色。与之对应的ByteArrayInputStream则可以把一个字节数组包成一个输入流便于统一处理逻辑。6. 经典报错与排查实录——这些坑我都替你踩过6.1 IOException: Stream Closed这个异常通常发生在流被关闭后继续调用其方法时。一个典型场景是方法内部关掉了传入的流调用方不知情后续又用同一个流去读写就抛出异常。排查思路是检查流的生命周期确保关闭操作只发生一次并且不要在关闭后继续使用。6.2 读取乱码与编码不一致遇到读文件乱码十有八九是编码不匹配。文件本身是GBK编码你用UTF-8去解码或者文件是UTF-8你用系统默认编码去读都会乱。解决方式打开文件时显式指定字符集不要依赖系统默认值。例如new InputStreamReader(fileInput, StandardCharsets.UTF_8)。6.3 最后一行数据丢失写文件时程序正常结束但最后一部分数据没写进去。原因是输出流的缓冲区未满程序就退出了而close没有被正常执行。常见的错误版本是用传统方式创建流但不写finally或者直接删掉了close调用。另外要小心如果使用write(byte[])方法传入的数组里只有部分有效数据但没有指定len会把数组中的所有内容都写进去包括上次遗留的旧数据。这个细节我在上面已经提过。6.4 常见问题速查表场景异常/现象核心原因解决方案读取图片文件FileNotFoundException路径错误或文件不存在检查文件路径使用绝对路径调试复制文件文件内容不一致write忽略len参数使用write(buffer, 0, len)读文本中文乱码字符编码不匹配显式指定编码集网络通信数据一直没到对方忘记flush写完消息后手动flush反序列化InvalidClassExceptionserialVersionUID不一致显式声明serialVersionUID流用后不关文件占用、句柄泄漏未执行close使用try-with-resources大文件读取OutOfMemoryError一次性读入内存改用流式读取6.5 一个真实的排错经历有一次我在处理大量文件上传的业务结果发现高并发时服务端频繁报错“Too many open files”。排查之后定位到是代码里有一处FileInputStream不是通过try-with-resources创建的而是一个旧版本写法的分支在异常发生时忘了close。这个问题单看逻辑看不太出来需要结合异常统计和代码审计。最终把所有流的使用统一改成try-with-resources模式后问题彻底消失。现在我的经验是代码里出现new FileInputStream的地方旁边必须紧跟try或立即存入try-with-resources。这是一条强制纪律。7. 关于字节流的几点心得7.1 用度与分寸字节流虽然功能强大但并不是万能的。文本处理该用字符流就用字符流不要钻牛角尖。判断依据很简单你要操作的是数据的内容还是数据本身如果要按行、按词、按字符处理明显是字符流领域。如果只是搬运、拼接、加密、序列化那就选字节流。7.2 NIO与字节流的关系我在文中提到的这些字节流都是传统IOBIO的范畴。Java后来推出的NIO里ByteBuffer同样是基于字节的概念。NIO优势在于非阻塞和多路复用对于高并发网络场景性能更好但它并不取代所有字节流的使用场景。老项目里传统字节流依然大量存在理解传统的继承体系能帮助你读任何代码。7.3 代码规范的红线关于IO这块请务必养成几个条件反射任何流都要用try-with-resources或finallyclose来确保释放指定编码集时不要依赖系统默认值处理代理敏感数据的对象字段用transient修饰Socket程序里写消息后加个flush。IO流的报错和坑很多看起来玄乎本质上还是对底层字节操作的理解不到位。把字节流搞明白了字符流、缓冲流、网络流、序列化都会自然串联起来后面学任何框架里的IO相关模块都会觉得似曾相识。最后再分享一个小技巧写代码遇到IO需求时先在脑子里过一遍“我要对字节做什么”再选择一个具体实现类。想清楚再动手往往能避免很多返工。
很多Java开发者在刚接触IO流时都会被那一大堆InputStream、OutputStream、Reader、Writer搞得晕头转向。字节流作为整个Java IO体系的基石其实搞清楚它后面很多东西都能串起来。这篇文章我会从实际使用的角度出发把字节流掰开揉碎讲清楚覆盖原理、实操、性能优化和排坑经验希望对正在学这块的朋友有帮助。1. 字节流到底是什么——先从底层逻辑说起1.1 计算机里一切皆字节首先要建立一个直觉不管你的文件是TXT文档、图片、视频、压缩包还是Excel表格在磁盘上存储时本质上都是一连串的字节。每一个字节是8位二进制数取值范围从0到255。数据一旦进入内存或网络传输也是以字节为单位流动的。所以字节流本质上就是程序与数据源之间以字节为单位进行数据传输的通道。我用一个生活中比较容易理解的例子来说明。你网购了一个包裹快递小哥把包裹送到你手上你打开包裹取出里面的东西。字节流里的InputStream就相当于收快递的动作把数据从某个源头文件、网络、内存等搬运到程序里。OutputStream则相当于寄快递的动作把程序里的数据写到某个目标去。而搬运的最小单位就是字节。1.2 为什么需要字节流可能有人问既然有了字符流Reader/Writer处理文本挺方便的为什么还要字节流答案是字符流只能处理文本数据而字节流可以处理一切数据。图片的二进制数据你没法用Reader去读视频文件也不能用Writer去写。字节流是万能的底层方案字符流只是在字节流之上做了一层编码解码的封装。凡是涉及图片、音视频、压缩包、序列化对象或者任何不纯文本格式的数据都必须用字节流来处理。即使你只处理文本底层也是通过字节流从磁盘读入数据再交给字符流解码为字符。可以说没有字节流Java的IO体系就塌了一半。2. 核心骨架继承体系与设计思路2.1 两大抽象父类字节流的核心是四个抽象类InputStream、OutputStream、Reader、Writer。其中前两个就是字节流的顶层抽象。InputStream负责定义字节输入的行为它有几个关键方法read()读取一个字节返回0到255的int值读到末尾返回-1read(byte[] b)读取一批字节到数组中返回实际读取的字节数read(byte[] b, int off, int len)读取最多len个字节到数组指定位置close()关闭流释放底层资源OutputStream对应定义了字节输出的行为write(int b)写入一个字节write(byte[] b)写入整个字节数组write(byte[] b, int off, int len)写入字节数组的一部分flush()将缓冲区的数据强制刷新到目标close()关闭流释放底层资源注意到read()和write(int b)的参数和返回值都是int而不是byte为什么因为read()需要返回-1这个特殊值来表示流已结束而byte类型无法表示-1。write(int b)接收int参数但实际只使用低8位多余的位会被丢弃。这一点很多人刚开始容易搞混。2.2 常用的字节流实现类继承体系看起来庞大但实际工作中用到的主要就是这几个FileInputStream和FileOutputStream文件字节流最基础的磁盘读写工具。BufferedInputStream和BufferedOutputStream缓冲字节流内部维护一个缓冲区能显著减少系统调用次数提升读写性能。后面性能优化部分会展开讲。DataInputStream和DataOutputStream数据字节流允许直接读写Java基本数据类型int、double、boolean等常用于需要保存结构化二进制数据的场景。ObjectInputStream和ObjectOutputStream对象字节流用于Java对象的序列化和反序列化也就是把对象变成字节永久保存或网络传输。ByteArrayInputStream和ByteArrayOutputStream内存字节流数据源是内存中的字节数组多用于同一进程内的数据中转。它们各自的职责不同但都是围绕那一组read/write方法在做文章。理解了顶层抽象再去看任何一个实现类都能快速上手。3. 读写文件的实操演练——从低效到高效3.1 第一个版本单字节读写先用最原始的方式实现一个文件复制功能把data.bin的内容复制到copy.bin。import java.io.FileInputStream; import java.io.FileOutputStream; public class SingleByteCopy { public static void main(String[] args) throws Exception { FileInputStream input new FileInputStream(data.bin); FileOutputStream output new FileOutputStream(copy.bin); int data; while ((data input.read()) ! -1) { output.write(data); } input.close(); output.close(); } }这段代码逻辑完全正确read()每次读一个字节读到末尾返回-1退出循环write()把字节写出去。但性能极其糟糕。每读一个字节就发起一次系统调用磁盘会在用户态和内核态之间来回切换。我做过一个粗略的测试复制一个100MB的文件单字节读写需要大约好几秒而用缓冲流只需要几百毫秒差距可以达到一个数量级。3.2 第二个版本字节数组批量读写既然单字节慢那就批量读。用read(byte[])方法每次读取一整个数组的数据。import java.io.FileInputStream; import java.io.FileOutputStream; public class BufferArrayCopy { public static void main(String[] args) throws Exception { FileInputStream input new FileInputStream(data.bin); FileOutputStream output new FileOutputStream(copy.bin); byte[] buffer new byte[8192]; int len; while ((len input.read(buffer)) ! -1) { output.write(buffer, 0, len); } input.close(); output.close(); } }这一改性能立刻好上不少。为什么因为系统调用的次数大大减少了。假设文件100MB缓冲区8KB循环只需要执行大约12800次与之前的1亿次相比是天壤之别。需要注意的是write时必须带上len这个参数。如果直接写output.write(buffer)会把整个8KB数组写出去但最后一次读取可能根本填不满缓冲区导致文件尾部出现多余数据。3.3 第三个版本缓冲流的正确用法实际开发中更省心的做法是直接用BufferedInputStream和BufferedOutputStream。它们内部默认维护一个8192字节的缓冲区自动帮我们完成批量读写。import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.FileInputStream; import java.io.FileOutputStream; public class BufferedCopy { public static void main(String[] args) throws Exception { try (BufferedInputStream input new BufferedInputStream(new FileInputStream(data.bin)); BufferedOutputStream output new BufferedOutputStream(new FileOutputStream(copy.bin))) { byte[] buffer new byte[1024]; int len; while ((len input.read(buffer)) ! -1) { output.write(buffer, 0, len); } } } }注意这种写法用的是try-with-resources语法流会在try块结束后自动关闭不用手动close代码也简洁了很多。有人可能会问既然缓冲流内部已经有8KB缓冲区了我为什么还额外声明一个byte[1024]原因在于缓冲流默认的read(byte[])方法会一次性尝试填满你传入的整个数组。如果你直接不传数组用input.read()一次拿一个经过内部缓冲的数据效果也还行。但更稳妥高效的做法是配合一个大小合适的字节数组一起用。数组取1024到8192之间都是合理的再大也不会有明显提升。3.4 关于flush和close的冷门细节在写文件时输出流的write操作先写入内存缓冲区真正落到磁盘需要触发flush。缓冲流在缓冲区满了之后会自动flush但如果你在写完后立即关闭程序或读取文件可能有一部分数据还在缓冲区里没落盘。调用close()方法时JVM会先执行一次flush再释放资源所以一般情况下你不需要手动调用flush。唯一需要手动flush的场景是长连接的网络通信比如你写了一个服务端程序要向客户端发送一条消息后等待对方回应这时必须手动flush否则数据会一直堵在缓冲区里双方就此死等。我再补充一个踩过的坑如果使用try-with-resources多个流的关闭顺序是严格按照声明顺序逆序进行的。也就是说先关闭外层的缓冲流再关闭内层的文件流。这其实是好事因为关闭外层流时会先刷新缓冲区确保数据全部写入再关闭底层文件流完美避免了先关底层导致数据丢失的问题。4. 字节流与字符流的边界——什么场景该用哪个4.1 乱码问题的根源很多新手用InputStream读文本文件结果读到中文出现乱码一脸懵。原因很简单英文和数字在UTF-8编码下占1个字节中文占3个字节生僻字甚至占4个。如果你用单字节方式去读一个中文字被切成了3个片段每个片段都变成了无意义的乱码符号。字符流就是为解决这个问题而生的。它以字符为单位读取数据内部通过指定的字符集比如UTF-8、GBK将字节解码成字符。但要注意字符流只是看起来处理的是字符底层依然依赖字节流在进行实际的物理I/O操作。InputStreamReader就是连接字节流和字符流的桥梁import java.io.FileInputStream; import java.io.InputStreamReader; public class BridgeDemo { public static void main(String[] args) throws Exception { try (FileInputStream fileInput new FileInputStream(note.txt); InputStreamReader reader new InputStreamReader(fileInput, UTF-8)) { char[] buffer new char[1024]; int len; while ((len reader.read(buffer)) ! -1) { System.out.println(new String(buffer, 0, len)); } } } }4.2 选择清单我根据自己的开发经验整理一个简洁的选择清单二进制数据图片、视频、压缩包、序列化对象用字节流。这是死规矩字符流根本处理不了。纯文本数据TXT、JSON、XML、日志文件用字符流。推荐FileReader/FileWriter或者BufferedReader/BufferedWriter。如果文件较小甚至可以直接用Files.readAllLines。不确定数据到底是什么格式时先用字节流后续再探测或者解析。网络传输中Socket通信的底层也是字节流。你接收到的原始数据一定是字节数组再根据具体协议判断如何解码成文本或对象。4.3 一个小案例复制文本文件到底用什么如果只是复制一个文件不管目标是什么类型直接复制字节是最稳的。因为你不需要关心文件内容如何解析只需要原样搬运。但如果需要读取文件内容做处理比如统计某个关键词出现的次数就必须用字符流并指定正确的编码集了。举个例子用Files类几行代码就能完成文本文件的按行读取import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.util.List; public class ReadAllLines { public static void main(String[] args) throws Exception { Path path Paths.get(note.txt); ListString lines Files.readAllLines(path, java.nio.charset.StandardCharsets.UTF_8); for (String line : lines) { System.out.println(line); } } }这种方式适合中小文件。如果文件很大比如几个GB的日志一次性读入内存会直接OOM。这时候还是得回到流式读取用BufferedReader逐行处理。5. 从文件到网络——字节流在真实项目中的典型玩法5.1 文件复制之外加密与解密的字节操作字节流不只是简单地搬运数据。既然所有数据对字节流来说都只是一个个字节我们完全可以在搬运过程中加入一些逻辑实现简单的加密效果。比如用一个XOR异或运算做位级别的混淆import java.io.*; public class XorEncrypt { private static final byte KEY 0x5A; public static void process(String src, String dst) throws Exception { try (BufferedInputStream input new BufferedInputStream(new FileInputStream(src)); BufferedOutputStream output new BufferedOutputStream(new FileOutputStream(dst))) { byte[] buffer new byte[8192]; int len; while ((len input.read(buffer)) ! -1) { for (int i 0; i len; i) { buffer[i] ^ KEY; } output.write(buffer, 0, len); } } } }同一个方法执行两次第一次是加密第二次就解密了因为XOR运算具有对称性。这种处理方式展现了字节流的核心优势你可以在字节层面做任意变换而无需关心数据本身的结构。当然这只是演示真实加密算法要复杂得多。5.2 对象持久化对象流让Java对象可保存字节流还能让Java对象变成一串字节保存到磁盘或网络上传输这个过程叫序列化。看个简单例子import java.io.*; class User implements Serializable { private static final long serialVersionUID 1L; private String name; private int age; User(String name, int age) { this.name name; this.age age; } Override public String toString() { return User{name name , age age }; } } public class ObjectStreamDemo { public static void main(String[] args) throws Exception { User user new User(若川, 28); try (ObjectOutputStream oos new ObjectOutputStream(new FileOutputStream(user.obj))) { oos.writeObject(user); } try (ObjectInputStream ois new ObjectInputStream(new FileInputStream(user.obj))) { User restored (User) ois.readObject(); System.out.println(restored); } } }序列化这块有几个坑必须提一下。第一被序列化的类必须实现Serializable接口这是一个标记接口没有需要实现的方法。第二类里面有一个serialVersionUID字段如果漏写了编译器会随机生成一个。此后一旦类的结构发生了改变比如新增一个字段serialVersionUID就会变化导致反序列化时抛InvalidClassException。所以规范做法是显式声明serialVersionUID并保持它不变。第三用transient关键字标记的字段不会被序列化适合放密码、敏感信息等不需要持久化的数据。5.3 网络传输Socket里的字节流网络通信中也到处是字节流。操作系统的Socket接口只认字节Java的Socket封装后底层依然是InputStream和OutputStream。下面给出一个极简的客户端发送数据到服务端的示例import java.io.*; import java.net.Socket; public class SocketClient { public static void main(String[] args) throws Exception { try (Socket socket new Socket(127.0.0.1, 8080)) { OutputStream output socket.getOutputStream(); String message Hello, Server; output.write(message.getBytes(UTF-8)); output.flush(); } } }这里write的是byte数组由String的getBytes方法将文本编码为字节。网络传输场景下flush非常重要不写flush数据可能一直停留在客户端操作系统缓冲区迟迟发不出去。服务端接收时也需要按字节读入再解码为字符串。这里的缓冲设计、半包粘包处理等等就涉及到更高阶的Netty框架了但底层依然脱离不开字节流这个基础概念。5.4 内存中的字节流小工具里的常客ByteArrayOutputStream非常适合在内存中拼接数据它不需要操作磁盘或网络完全在内存中操作容量可以动态增长。比如想快速拼接一组字节时可以这样import java.io.ByteArrayOutputStream; public class ByteArrayDemo { public static void main(String[] args) throws Exception { ByteArrayOutputStream output new ByteArrayOutputStream(); output.write(Hello.getBytes(UTF-8)); output.write(0x20); // 空格 output.write(World.getBytes(UTF-8)); byte[] result output.toByteArray(); System.out.println(new String(result, UTF-8)); } }这个类在生成HTTP响应体、拼接协议报文等场景中经常扮演工具角色。与之对应的ByteArrayInputStream则可以把一个字节数组包成一个输入流便于统一处理逻辑。6. 经典报错与排查实录——这些坑我都替你踩过6.1 IOException: Stream Closed这个异常通常发生在流被关闭后继续调用其方法时。一个典型场景是方法内部关掉了传入的流调用方不知情后续又用同一个流去读写就抛出异常。排查思路是检查流的生命周期确保关闭操作只发生一次并且不要在关闭后继续使用。6.2 读取乱码与编码不一致遇到读文件乱码十有八九是编码不匹配。文件本身是GBK编码你用UTF-8去解码或者文件是UTF-8你用系统默认编码去读都会乱。解决方式打开文件时显式指定字符集不要依赖系统默认值。例如new InputStreamReader(fileInput, StandardCharsets.UTF_8)。6.3 最后一行数据丢失写文件时程序正常结束但最后一部分数据没写进去。原因是输出流的缓冲区未满程序就退出了而close没有被正常执行。常见的错误版本是用传统方式创建流但不写finally或者直接删掉了close调用。另外要小心如果使用write(byte[])方法传入的数组里只有部分有效数据但没有指定len会把数组中的所有内容都写进去包括上次遗留的旧数据。这个细节我在上面已经提过。6.4 常见问题速查表场景异常/现象核心原因解决方案读取图片文件FileNotFoundException路径错误或文件不存在检查文件路径使用绝对路径调试复制文件文件内容不一致write忽略len参数使用write(buffer, 0, len)读文本中文乱码字符编码不匹配显式指定编码集网络通信数据一直没到对方忘记flush写完消息后手动flush反序列化InvalidClassExceptionserialVersionUID不一致显式声明serialVersionUID流用后不关文件占用、句柄泄漏未执行close使用try-with-resources大文件读取OutOfMemoryError一次性读入内存改用流式读取6.5 一个真实的排错经历有一次我在处理大量文件上传的业务结果发现高并发时服务端频繁报错“Too many open files”。排查之后定位到是代码里有一处FileInputStream不是通过try-with-resources创建的而是一个旧版本写法的分支在异常发生时忘了close。这个问题单看逻辑看不太出来需要结合异常统计和代码审计。最终把所有流的使用统一改成try-with-resources模式后问题彻底消失。现在我的经验是代码里出现new FileInputStream的地方旁边必须紧跟try或立即存入try-with-resources。这是一条强制纪律。7. 关于字节流的几点心得7.1 用度与分寸字节流虽然功能强大但并不是万能的。文本处理该用字符流就用字符流不要钻牛角尖。判断依据很简单你要操作的是数据的内容还是数据本身如果要按行、按词、按字符处理明显是字符流领域。如果只是搬运、拼接、加密、序列化那就选字节流。7.2 NIO与字节流的关系我在文中提到的这些字节流都是传统IOBIO的范畴。Java后来推出的NIO里ByteBuffer同样是基于字节的概念。NIO优势在于非阻塞和多路复用对于高并发网络场景性能更好但它并不取代所有字节流的使用场景。老项目里传统字节流依然大量存在理解传统的继承体系能帮助你读任何代码。7.3 代码规范的红线关于IO这块请务必养成几个条件反射任何流都要用try-with-resources或finallyclose来确保释放指定编码集时不要依赖系统默认值处理代理敏感数据的对象字段用transient修饰Socket程序里写消息后加个flush。IO流的报错和坑很多看起来玄乎本质上还是对底层字节操作的理解不到位。把字节流搞明白了字符流、缓冲流、网络流、序列化都会自然串联起来后面学任何框架里的IO相关模块都会觉得似曾相识。最后再分享一个小技巧写代码遇到IO需求时先在脑子里过一遍“我要对字节做什么”再选择一个具体实现类。想清楚再动手往往能避免很多返工。
