字节流这个知识点凡是学 JavaSE 的都不可能绕过去。但说实话我在带人或者看新手代码的时候发现大部分人对于 InputStream、OutputStream 的理解就停在能读文件、能写文件这个层面真正问到底层逻辑、返回值、关闭时机、缓冲机制能讲清楚的没几个。这篇就把字节流和文件读写这件事从头捋一遍重点放在为什么这么写和实际开发中到底会遇到什么上不整虚的。1. 先搞清楚字节流到底在解决什么问题1.1 一切数据在内存里都是字节序列很多初学者搞不懂的一个点是Java 里明明有 char、String 这些类型为什么文件读写还要用 byte[] 这种原始的东西道理很简单。你写一个字符串 abc 到文件里最终落盘的是这三个字符对应的二进制编码可能是 ASCII、可能是 UTF-8、可能是 GBK。文件系统不认识什么叫字符它只认识字节也就是 0 和 1 组成的序列。字节流做的事情就是把这串字节原封不动地从一端搬到另一端。字符串、图片、音频、视频在存储层面没有任何区别都是字节。这就是为什么 FileInputStream 和 FileOutputStream 这对字节流可以处理任意类型的文件而 Reader/Writer 那套字符流只能处理文本文件。你如果用一个字符流去拷贝一张图片大概率会把二进制数据破坏掉因为字符流在读取时做了编码转换图片的字节序列一旦被按字符解码再编码就等于被翻译了一遍原始数据就丢了。所以记住一句话字节流是 Java IO 的地基字符流是在字节流之上做的装饰。凡是处理非文本文件只用字节流处理文本文件虽然字符流更方便但底层依然得靠字节流支撑。1.2 输入输出站在程序的视角理解InputStream 和 OutputStream 的名字经常把新手绕晕。把数据从文件读进内存有人管这叫读文件对应 FileInputStream把内存数据写到文件对应 FileOutputStream。但问题来了为什么读要用 InputStream而不是 OutputStream原因在于这里说的 In 和 Out站在的是Java 程序/内存这一侧不是文件那一侧。数据从文件流向你的程序对于程序而言是输入所以叫 InputStream数据从程序写到文件对于程序而言是输出所以叫 OutputStream。这个视角一定要建立起来因为你后面看网络编程、Socket 通信的时候输入输出流的命名规则是一致的——都是站在你的应用程序这一端去理解方向。一旦方向搞反排查问题的时候会非常痛苦。2. 核心 API 的使用逻辑read 和 write 的所有细节2.1 read() 的返回值是数据内容而不是数据长度别混淆InputStream 最基础的方法是int read()它每次从输入源读取一个字节返回值是这个字节的值范围是 0 到 255。当读取到流的末尾EOFEnd Of File返回 -1。这里有两个新手最容易踩的坑。第一个返回值为什么是 int 而不是 byte因为一个字节是 8 位范围是 -128 到 127如果 read 返回 byte 类型就用 -1 这个合法字节值和流末尾产生了冲突——你没法区分读到的内容是 -1 还是流结束了。所以 JDK 的设计是把字节值无符号化变成 0 到 255再用 -1 专门表示流已经读完。第二个坑int read(byte[] b)这个方法返回值表示实际读取到的字节数可能是 0可能是正数可能是 -1。这就和int read()的返回值含义完全不同。前者返回的是内容的数值后者返回的是内容的长度。我见过有人把read(byte[] b)的返回值当成最后一个字节的内容去用结果逻辑完全乱套这是概念没拎清楚。2.2 单字节 read 的效率陷阱按字节逐个读逻辑上最简单但性能上最差。为什么因为每一次read()都隐含着一次系统调用。系统调用意味着要从用户态切到内核态这是一笔不小的开销。你读一个 10MB 的文件如果一次读一个字节就是一千多万次系统调用这个性能损耗是灾难级的。我之前帮一个同事看程序他把一个几百兆的日志文件用单字节 read 循环读完处理跑了十几分钟还没结束。换成read(byte[])之后几秒钟就搞定了。这不是代码写法的问题是你对 IO 机制的理解不到位。还有一个很多人没意识到的问题单字节 read 每次返回的数据长度是 1所以你没法利用系统底层一次读取很多数据的潜力。而read(byte[])的设计目的就是让你一次性从输入源尽量多地读取数据填满你提供的缓冲区。2.3 write 的三层重载OutputStream 的核心方法是write(int b)、write(byte[] b)和write(byte[] b, int off, int len)。write(int b)虽然是接收 int但只会把这个 int 的低 8 位写入输出流。也就是说你传 300底层写的是 300 转成二进制的最后 8 位也就是 44。这个和read()返回 0 到 255 是配套的一个写入低 8 位字节值一个返回低 8 位字节值。write(byte[] b)一次性把一个字节数组写出去但这里有个常见 bug如果数组里只有一部分是有效数据你全写出去就把多余数据一起污染了。这个方法适合你确定要把整个数组都写出去的场景。真正推荐经常用的是write(byte[] b, int off, int len)它接收三个参数起始位置、长度。结合read(byte[] b)的返回值你就知道这次循环读进来了多少有效数据写的时候就只写这些不会多写也不会漏写。这就是文件拷贝的核心循环逻辑。FileInputStream in new FileInputStream(source.bin); FileOutputStream out new FileOutputStream(target.bin); byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } in.close(); out.close();这段代码是所有字节流文件操作的骨架Backup、Copy、上传下载文件的逻辑基本都是这个循环的变体。把write(buffer, 0, len)中的一个参数写错文件拷贝出来就会多一块脏数据或者缺一块。这不是理论上可能出错是实操中确实很容易犯的错我之前就在一次数据迁移任务里因为漏传第三个参数导致目标文件尾部多了几千字节的缓存残留回滚重跑之后才发现问题。2.4 close 与 flush 的先后逻辑close 之前要不要 flush严格来说close()内部会先执行flush()把缓冲区的数据推出去再关闭底层资源。但是在某些特殊场景下你不能依赖这一点。比如你用 BufferedOutputStream 写数据写完立刻读同一个文件像日志模块写完一条马上要读出来匹配关键字如果你没显式 flush数据可能还停留在缓冲区文件里暂时没有完整的内容。我习惯的做法是只要写完一批数据之后有立即读取/发送/上传之类的动作就显式调一次 flush如果只是写完了后面不再操作这个流了那 close 就够了。别省这个 flush也别滥用这是个节奏问题。3. 动手实战文件读写最常用的几种姿势3.1 一次性读取全部字节适合小文件的 Files.readAllBytesJava 7 之后的 NIO 提供了非常便利的方式Files.readAllBytes(Path)可以一口气把整个文件读进一个 byte[]。这个 API 比起手动写 FileInputStream ByteArrayOutputStream 的一大堆拼接逻辑简洁太多了。但它有一个明显的限制文件太大就撑不住。你读一个 1GB 的文件意味着 JVM 堆里要分配一块约 1GB 的 byte[]这很容易触发 OOMOutOfMemoryError。而且一次性读入后如果后续处理本身又需要额外空间内存压力就更大了。所以Files.readAllBytes的适用场景是配置文件、小图片、几百 KB 到几 MB 的临时数据。超过 50MB 我基本就不建议这样搞了。3.2 边读边写大文件只能靠流式处理文件拷贝、图片缩放、音视频处理这类场景数据量往往比较大不能假设全塞内存没事。正确的打开方式就是第 2 节那段骨架代码的思路一个固定大小的缓冲区比如 8KB 或 16KB循环readwrite让数据像流水一样经过内存而不是停留。缓冲区大小怎么选JDK 里 BufferedInputStream 的默认大小就是 8192 字节8KB这个值被反复验证过是一个性能与内存占用比较均衡的档位。你也可以用 16KB 或 32KB通常还能再挤点性能出来但再大就开始边际递减了。我自己的习惯是文件小于 100MB用 8192文件更大调到 6553664KB不算激进也不算保守。实际项目里我用 64KB 缓冲区拷贝过几个 GB 的文件内存占用稳定速度也够用。3.3 用 BufferedInputStream / BufferedOutputStream 包一层再看上面那段代码。我们手动用byte[] buffer把多次小系统调用合并成大的批量读取从而减少系统调用的次数。其实 JDK 已经提供了现成的装饰器——BufferedInputStream和BufferedOutputStream。它们内部维护了一个缓冲区默认 8KB你在外层调用单字节 read它先从内部缓冲区拿缓冲区空了才批量去底层输入流读一大块。这样你可以用非常自然的代码写业务逻辑底层 IO 次数依然是批量的。try (BufferedInputStream in new BufferedInputStream(new FileInputStream(source.bin)); BufferedOutputStream out new BufferedOutputStream(new FileOutputStream(target.bin))) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } }注意如果你外层已经有了 8KB 的 byte[] 做批量 read那么内层的 BufferedInputStream 还会再做一层缓冲这时候多少有点叠床架屋但从代码可读性和高层语义来说包一层缓冲流的结果依然是正向的它把系统调用批量化这件事完全隐藏起来你后面改业务逻辑的时候不会心惊胆战。JDK 源码里BufferedInputStream 本质上就是帮你封装了少调用底层 read多搬数据进内存这个动作。4. 关闭流的正确姿势try-with-resources 才是现代 Java 的答案4.1 为什么一定要关流不关流会导致资源泄漏。这里的资源说的不是内存而是操作系统层面的文件描述符file handle。每个进程能同时打开的文件数量是有上限的Linux 下可以用 ulimit 查看一般是 1024 或更高。如果每次打开不关跑一个长时间的批处理任务迟早把文件描述符耗尽后续所有打开文件的操作都抛异常。还有个很现实的情况Windows 下文件被某个流占用过但没有关闭你想删除或覆盖它就报文件正在被使用。排查起来真是令人崩溃。所以关流不是好习惯是必须做。早期 Java 版本的写法是把 close 放在 finally 块里还要处理 close 本身可能抛出的 IOException代码非常冗余。Java 7 引入了 try-with-resources只要你的类实现了AutoCloseable接口就可以写在 try 后面的括号里JVM 会在 try 块结束后自动调用 close。try (FileInputStream in new FileInputStream(source.bin); FileOutputStream out new FileOutputStream(target.bin)) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } }这段代码如果翻译成 finally 版本需要嵌套两层 try-finally还要处理 first exception 被 close exception 覆盖的问题。try-with-resources 的出现基本相当于把这个反复出现的问题消灭了。4.2 多个流共用一个 try按逆序关闭你可能会想in 和 out 分两行写在同一个 try 括号里关闭顺序是什么答案是从最后一个声明的开始往前关。也就是示例代码里先关 out再关 in。这个顺序是对的先关闭输出流确保数据完全落盘再关输入流结束读取。如果你把 in 定义在 out 后面关闭顺序反过来也不会报错但从逻辑上说不是最稳妥的。所以习惯上让输出流靠后声明。另外有个小坑如果流的构造过程本身失败了那么已经被成功构造的流还是会被 try-with-resources 自动关闭。比如 out 的构造抛了异常in 已经被创建它也会被关闭。这个机制非常可靠不用手动写一堆如果 in 不为 null 就关的判断。4.3 到底什么时候不能依赖 try-with-resources有没有场景是你必须手动管理流的生命周期有。比如你要把一个流作为字段存起来在对象销毁前一直保持打开状态像持有一个网络连接、一个日志输出流它的生命周期和某个方法块没关系这时候就不能用 try-with-resources 了需要在你认为合适的时候手动调用 close。但即使这样你也最好用一个统一的方法来关闭并且加好保护逻辑防止重复关闭抛异常。5. 装饰器模式与字节流家族的进阶用法5.1 FilterInputStream 家族一层套一层的流水线很多人学 IO 到字节流就停了觉得FileInputStream FileOutputStream 够用了然后看到 BufferedInputStream 也不知道它是干什么的。其实字节流家族里还有一个重要成员——FilterInputStream它像一个加工器可以套在 FileInputStream 外面对读写过程做增强。这种设计叫装饰器模式。核心思想是一个原始管道比如从文件读数据外面裹一层加工管道比如加缓冲、加数据转换你可以无限叠加每一层只负责一件小事最终形成一个强大的流水线。常见的套法是DataInputStream(FileInputStream) → 方便地读基本数据类型 BufferedInputStream(FileInputStream) → 增加缓冲这里 DataInputStream 的作用是让你直接readInt()、readUTF()、readDouble()它内部会把字节拼装成对应类型省去手动拼装字节数组的麻烦。5.2 用字节流实现一个简单的文件拷贝工具把上面的知识串起来写一个通用拷贝工具并不复杂public static void copyFile(String src, String dst) throws IOException { try (FileInputStream in new FileInputStream(src); FileOutputStream out new FileOutputStream(dst)) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } } }这个工具的潜在问题是什么首先它不做任何源文件不存在或其他异常时的友好处理其次它没有校验目标路径目录是否存在直接写入会抛 FileNotFoundException实际是路径没有权限或其他原因。真实项目里肯定要加一些前置检查源文件是否存在、目标目录是否可写、源和目标是否同一个文件。这些不是字节流本身的问题是在实操中绕不开的边角逻辑。5.3 Files.copy 和字节流手动拷贝怎么选Java NIO 提供了Files.copy(Path, Path, CopyOption...)这个方法底层走的是更高效的文件系统操作。很多人问那我干嘛还要自己写字节流循环因为Files.copy走的是平台相关的文件复制机制在同一个文件系统下它可能直接操作文件系统内部的复制逻辑速度确实快代码也简单。但它有局限你不能在复制过程中对数据做任何加工比如解密、压缩、过滤。字节流的好处是数据流经你的代码你可以随时切进去做转换。所以纯拷贝用 Files.copy有加工才需要字节流手动写。顺带一提Files.copy 还有一个常见用法把 InputStream 的内容直接写入目标文件比如上传文件保存Files.copy(inputStream, targetPath, StandardCopyOption.REPLACE_EXISTING);注意这里如果 InputStream 是网络来的最好在不额外费内存的前提下用循环 read write 保持对进度的感知而 Files.copy 一次性接完也行看你是否需要对中断做处理。6. 真实项目里最容易翻车的场景与排查思路6.1 读完文件还是乱码先分清是 IO 问题还是编码问题字节流本身不关心编码它只是搬运字节。但你读进来之后要显示成字符串就必须指定正确的字符集。同一串字节用 UTF-8 解码和用 GBK 解码结果完全不一样。我见过一个典型案例某同事用 FileInputStream 读一个 UTF-8 编码的文本然后直接new String(bytes)没指定字符集。而项目里其他地方统一用的 UTF-8但 JVM 默认字符集在某些环境下是 GBK结果所有中文全部乱码。排查到最后不是 IO 读写有问题是解码方向搞错了。所以我的原则只要从字节到字符串永远显式指定字符集绝不依赖平台默认值。String content new String(bytes, StandardCharsets.UTF_8);反向写入也一样String.getBytes(StandardCharsets.UTF_8)不要用无参版本。6.2 文件句柄泄漏表象是文件被占用根因是流没关Windows 环境下日志处理程序反复打开同一个文件突然某天报文件正由另一个进程使用很常见。初学者经常以为是杀毒软件或者别的进程在占用实际上就是你自己的代码在某条异常路径上把流漏关了。用 try-with-resources 能解决 90% 这样的问题。但有一个容易被忽略的例外如果你在循环体里每个迭代都new FileOutputStream(...)且不带资源管道的关闭循环几百次之后就挂了。所以再强调一遍所有流的创建和关闭要么 within try-with-resources要么为你自己的类实现 AutoCloseable 并做好即使抛异常也要关的保障。6.3 数据读到一半程序崩溃剩余数据怎么办这不是一个要不要处理的问题而是一个你要不要接受数据不完整的问题。如果租用的是 FileInputStream 直接读完就没写出去那这份数据等于没传成功。更隐蔽的是代码写了一半抛异常输出流里已经有一段残缺的数据。这在多线程/网络传输场景下危害更大。解决办法是要么全部成功要么全部失败也就是事务性写入。简单做法先写临时文件全部写完再 rename 成正式文件。这个技巧在很多服务端程序里应用非常广比如日志轮转、配置热更新、导入任务的落盘。Path tmp target.resolveSibling(target.getFileName() .tmp); try (FileOutputStream out new FileOutputStream(tmp.toFile())) { // 写数据 } Files.move(tmp, target, StandardCopyOption.REPLACE_EXISTING);这样做的好处是即使写一半崩了临时文件残留不影响正式文件下次启动可以清理临时文件也可以直接覆盖写。6.4 性能差异的真实对照我曾经在同一个环境实测过几种文件读取方式的耗时差异。数据是一个 500MB 的压缩包。方式耗时约内存表现适用场景单字节 read() 循环异常慢分钟级极低几乎不推荐8KB byte[] 循环副本秒级稳定约几十 KB推荐通用BufferedInputStream byte[]秒级稳定比上面略低推荐代码更优雅Files.readAllBytes最快峰值高约等于文件大小小文件专用Files.copy最快低纯拷贝专用同样一份数据依赖的方法层和缓冲策略不同耗时差了一到两个数量级。单字节读是纯靠系统调用的数量来堆批量读则是靠单次搬运的数据量来赢。7. 字节流常见问题排查清单7.1 一张表搞定大部分报错现象可能原因验证方法解决方向FileNotFoundException路径不存在/无权限/是目录检查文件是否存在、权限位调用前预检、修复路径文件拷贝后大小不一致read 返回值与 write 长度不对应打印 len 和文件大小用 read 的返回值精确截取写入内容最后缺一块缓冲区没 flush 就 close 异常场景遗漏对比 flush 前后文件大小显式 flush 或用 try-with-resources中文乱码字节解码字符集不对打印字节数组转 hex 判断显式指定 UTF-8/GBK文件被占用流未关闭任务管理器看哪个进程持有句柄用 try-with-resources 规范关闭OOM一次性读入太大文件看日志报 Java heap space换流式读写7.2 排查顺序的通用套路不管是本地开发还是线上问题遇到文件相关的 bug我建议按这个顺序排查文件存在性和权限 → 流有没有关 → 每次读写循环的 len 处理 → 字符集/编码 → 缓冲区大小 → 底层文件系统限制。大多数问题到第二、第三步就能定位。我见过有人在编码问题上折腾半天最后发现是第一步就错了——文件压根不存在Fixture 路径写错。先跑一个最小验证单独打个日志输出file.exists()和file.length()能省掉大量无谓的排查时间。7.3 注意事项清单把平时容易忽略的要点集中放在这里。第一FileOutputStream的构造器默认覆盖原文件如果你要追加写需要用new FileOutputStream(file, true)。第二FileInputStrea本身不是线程安全的多线程读写同一个流需要自己加锁或使用其他方案。第三字节流读到的内容在没有做完编码判断前不要轻易转 String先想清楚这幅字节的身份。第四流式处理的场景里数据消费完毕就关不要为了复用流而做复杂的 reset 操作。8. 从字节流到整个 IO 体系自己的知识地图该怎么铺8.1 字节流和字符流之间隔着一座桥如果你已经掌握字节流下一步要学的就是从 InputStream 到 Reader 的适配桥——InputStreamReader。它会根据指定的字符集把原始字节翻译成字符流。这个概念非常重要因为很多场景下你需要从文件里读一行一行的文本用字符流比字节流顺手太多。但是底层的读取依然是字节流在干活。try (BufferedReader reader new BufferedReader( new InputStreamReader(new FileInputStream(data.txt), StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { // 处理每一行 } }这是一个典型的嵌套流示例FileInputStream 吃字节 → InputStreamReader 做解码 → BufferedReader 提供行缓冲。看懂这行代码你对整个 IO 系的洞察就又深了一层。8.2 推荐的学习路径对新手而言字节流相关的所有内容按优先级看我认为大概是这样。第一优先read / write 的返回值语义和缓冲区循环。第二优先close 的正确姿势和资源释放。第三优先装饰器模式BufferedInputStream / DataInputStream。第四优先字符编码与桥接流。第五优先NIO 里面的 Files 工具类。把这五样吃透日常项目绝大多数文件读写需求都能应对。我个人的体会是IO 这块知识跟算法题还不一样算法你懂了思想就能用但 Java IO 你是真心得把 API 环境摸熟在具体工程里才能真正体会流式设计的妙处。很多东西光看文档看不出来比如为什么 read(byte[]) 不保证读到的就是数组长度——你实际写代码试过才有体感。全文到这里基本上把字节流与文件读写这件事从原理到实操到排查都梳理了一遍。如果你正在学 JavaSE别急着跳到下一章把 FileInputStream 和 FileOutputStream 多写几遍做一个小工具比如文件批量改名、日志切割等你对数据流经内存这种感觉习以为常的时候整个 Java IO 的大门才算真正打开了。
