★ FEATURED ARTICLE 直接说一个我自己的观察java.io这套东西到现在依然是面试必问、工作必用的高频知识点。你背过八股文、刷过LeetCode可真要让你在十分钟内写一个可靠的本地文件复制工具类或者处理一个两GB的日志文件还能保证不乱码、不崩内存、不泄漏句柄很多人当场就露馅了。我写这篇就是想把这套老技术讲透帮你把本地I/O从“会调API”提升到“真懂原理、能写稳”的层次。这篇内容适合三类人看准备Java面试、需要快速上手传统IO的新人以及在老项目里天天跟File、InputStream打交道但没时间系统梳理的开发者。我会从体系设计讲起然后是能直接抄的代码模板、踩过的大坑、性能调优思路最后附上一组实操对照表。废话不多说直接开整。1. 传统本地I/O的设计骨架先搞懂这三个抽象很多教程上来就让你背InputStream、OutputStream、Reader、Writer这就属于本末倒置。框架这东西你先把设计者的意图搞明白剩下全是水到渠成的事。java.io这套体系核心就是在解决三个问题数据从哪来、按什么形态读、写到哪去。1.1 流的本质就是一个有序的数据通道流Stream在传统IO里本质上是一条单向、有序的数据通道。你从InputStream读数据数据就从头往尾流动读完了就没了不能回退。这也是它和RandomAccessFile最本质的区别——后者可以随便改指针位置流不行。这个设计有一个很重要的推论流不关心数据最终落在哪里。FileInputStream只负责从文件里往外吐字节至于你是要打印到控制台、写进网络、还是塞进内存数组它完全不管。所以你在写代码时脑子里要有一个清晰的分层意识数据源负责生产处理器负责转换输出端负责消费。这三层可以自由组合。举一个最典型的例子try (InputStream in new FileInputStream(source.txt)) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { // 这里爱干嘛干嘛没人管你 } }这段代码里你拿到的只是原始字节流。如果你知道文件里存的是文本你还得自己处理换行、编码如果你知道存的是整数或者对象你还得自己拼字节。这就是为什么会有下面那层装饰器。1.2 装饰器模式为什么Java的IO类有一大堆很多人被BufferedInputStream、DataInputStream、ObjectInputStream这些类搞得头晕其实它们就是一层层包装。FileInputStream管文件读取但效率低、功能少你给它包一层BufferedInputStream它就具备了缓冲区功能再给它包一层DataInputStream它就能直接读int、readUTF了。这就像你买了个毛坯房水电是FileInputStream装修是BufferedInputStream家电是DataInputStream。每一层只干一件事层与层之间随意组合。理解了这个思路你看见下面这串嵌套就不会慌try (DataInputStream dis new DataInputStream( new BufferedInputStream( new FileInputStream(data.bin)))) { int count dis.readInt(); for (int i 0; i count; i) { System.out.println(dis.readUTF()); } }从内往外数FileInputStream打开文件BufferedInputStream提供8192字节的缓冲DataInputStream把字节解析成Java基本类型。凡是你看到这种一层套一层的写法全都是装饰器在起作用。1.3 字符流到底解决什么问题字节流处理一切文件都没问题但人不是这么看世界的。你读一个文本文件期望的是按行按字符去读而不是自己手动把byte拼成char。字符流Reader/Writer这层抽象就是为了处理“字节到字符的转换”而存在的。InputStreamReader是字节流转字符流的桥梁它接受一个Charset参数把底层字节按指定编码解码成char。你不在构造时指定Charset它就会用JVM的默认字符集——这在中文Windows上通常就是GBK在Linux上通常是UTF-8。跨平台部署时写不写编码参数结果能差出十万八千里。// 这样写在你的Windows机器上可能没事上Linux就乱码 Reader reader new FileReader(config.properties); // 这样写任何平台行为一致 Reader reader new InputStreamReader( new FileInputStream(config.properties), StandardCharsets.UTF_8);我强烈建议新写的代码一律用第二种写法。FileReader这种便捷类只适合你临时写个小Demo生产代码里用它是给自己埋雷。2. 四个可以直接抄的实操模板理论说再多不如直接上代码。下面这四个场景覆盖了日常开发里百分之九十的本地I/O需求。我特意把每个版本都写成可以直接复制使用的完整方法你拿回去改个路径就能跑。2.1 全量文件复制一个方法征服所有文件类型文件复制是所有I/O操作的基础但很多人写出来的版本都有问题。先看第一版这是我见过最多的错误写法// 错误示范文件稍大就内存爆炸 public static void copyBad(String src, String dest) throws IOException { byte[] all Files.readAllBytes(Paths.get(src)); Files.write(Paths.get(dest), all); }这个写法的问题在于一次性把整个文件载入内存。你复制一个200MB的文件就得吃200MB的堆内存要是并发复制几个直接OutOfMemoryError。正确的做法是固定大小的缓冲区边读边写public static void copyFile(File src, File dest) throws IOException { try (InputStream in new BufferedInputStream(new FileInputStream(src)); OutputStream out new BufferedOutputStream(new FileOutputStream(dest))) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } } }注意几个细节缓冲区大小选8192字节也就是8KB这是性能与内存占用之间一个比较平衡的点读的时候一定要用read(buffer)的带参版本不要用无参的read()每次读一个字节那会慢到怀疑人生写的时候用write(buffer, 0, len)只写实际读到的字节数。最后一个细节是最容易被忽视的如果最后一次读到的字节数不足8192你还把整个buffer写进去文件末尾就会多出一堆垃圾数据。2.2 按行读取文本文件不只是while(readLine)按行读文本是日常开发里最频繁的操作。最简单的版本长这样public static void processLineByLine(String path) throws IOException { try (BufferedReader br new BufferedReader( new InputStreamReader( new FileInputStream(path), StandardCharsets.UTF_8))) { String line; while ((line br.readLine()) ! null) { // 处理每一行 System.out.println(line); } } }但这里有一个我反复在文章里强调的细节readLine()返回的字符串是不包含换行符的。你要做文本拼接、重写文件、按行统计时一定要考虑这个因素。举例来说统计文件总行数时最后一行如果不以换行符结尾有的工具会少计一行拼接大文本时如果忘记补System.lineSeparator()你就会发现所有内容挤在了一起。如果你的JDK在8以上我建议直接用Files.lines()它内部已经帮你处理了资源释放问题而且返回的是一个Stream方便你链式操作try (StreamString lines Files.lines(Paths.get(app.log), StandardCharsets.UTF_8)) { long errorCount lines.filter(l - l.contains(ERROR)).count(); }注意它返回的Stream必须放在try-with-resources里否则底层文件句柄不会自动关闭。Java 8的Files.lines()没有自动关闭Stream的机制这是我当年排查线上“打开文件数过多”时踩过的坑。2.3 二进制数据精确读写DataInputStream的正确打开方式文本文件读起来人性化但性能和精度都差。你要传一组数值型数据、或者处理一个自定义的二进制格式文件就得用DataInputStream和DataOutputStream这对组合。写入时DataOutputStream提供了writeInt、writeDouble、writeUTF等方法直接按大端序把Java基本类型写进流里。读取时按写入顺序依次read出来就行。这里最怕的就是顺序错乱写入顺序是int、int、String读取时就必须先readInt、readInt、readUTF顺序对不上后面全乱。// 写入 try (DataOutputStream dos new DataOutputStream( new BufferedOutputStream(new FileOutputStream(score.dat)))) { dos.writeInt(1000); // 总数 for (int i 0; i 1000; i) { dos.writeInt(i); // 学号 dos.writeDouble(i * 0.5); // 成绩 dos.writeUTF(学生 i); // 姓名 } } // 读取 try (DataInputStream dis new DataInputStream( new BufferedInputStream(new FileInputStream(score.dat)))) { int count dis.readInt(); for (int i 0; i count; i) { int id dis.readInt(); double score dis.readDouble(); String name dis.readUTF(); System.out.println(id , score , name); } }这里有个坑必须提醒你writeUTF写入字符串时会先用两个字节记录长度然后跟着修改版UTF-8编码的字节。这个“修改版UTF-8”和标准UTF-8在高位字符上有差异而且单次写入的String长度不能超过65535字节。如果你要序列化大段中文文本稳妥做法是先拆分成块或者干脆用byte[]自己控制编码。2.4 对象持久化序列化不是万能的很多新人一提到把对象保存到本地文件第一反应就是实现Serializable接口然后ObjectOutputStream。这个方案在小规模场景下确实省事但有几个和“本地I/O”强相关的问题你早晚会遇到。第一序列化产生的文件是二进制格式完全不透明。你不能用文本编辑器打开检查内容也没法轻易迁移到别的语言体系。一旦Java版本升级导致serialVersionUID变化你存了一半的历史文件就全废了。第二序列化会把整个对象图连带引用的其他对象一并写入如果你的对象里藏着一个大的集合属性文件体积会失控。// 序列化写入 try (ObjectOutputStream oos new ObjectOutputStream( new FileOutputStream(user.obj))) { oos.writeObject(user); } // 反序列化读取 try (ObjectInputStream ois new ObjectInputStream( new FileInputStream(user.obj))) { User user (User) ois.readObject(); }我在项目里的经验是如果这个对象只在本Java服务内部存活、且还没有变成长期存储的历史数据用序列化没问题。但一旦涉及跨系统数据交换、版本升级、或者需要人眼排查数据老老实实用JSON、CSV、或自定义二进制格式别图省事。3. 性能盘根问底同样一段代码为什么你的慢十倍本地I/O的性能瓶颈八成都出在缓冲区设置不合理和频繁的上下文切换上。今天一起把这个问题彻底解决掉从原理到实操给你讲透。3.1 缓冲区大小到底怎么选我从Java源码的角度给你拆一下。无缓冲的FileInputStream每次read()都会触发一次系统调用让操作系统从磁盘读一个字节到用户空间这个开销之大是你无法想象的。BufferedInputStream存在的意义就是一次性从底层读一大块进内存然后你每次read()只是从内存数组里取一个字节。那缓冲区多大合适太小系统调用次数多性能上不去太大内存占用高且单次拷贝耗时也长。实测下来4KB到16KB之间性能差别不大8KB是我个人最常用的值。Java里BufferedInputStream的默认缓冲区就是8192字节我建议你手动构造时也保持这个数没必要写的天花乱坠。// 推荐8KB缓冲区性能和内存兼顾 byte[] buffer new byte[8192];如果你在写那种单次处理超大批量的工具比如几百兆甚至几个G的文件转换可以考虑把缓冲区提到64KB或128KB收益还是有的但边际递减很严重。缓冲区不是越大越好超过一定阈值后反而因为内存拷贝和缓存命中率下降导致性能回退。3.2 读一个字节的罪与罚这是我在Code Review里抓得最狠的一种写法// 错误示范一次读一个字节性能慢到爆炸 InputStream in new FileInputStream(big.bin); int b; while ((b in.read()) ! -1) { // 处理b }你没看错这里每次循环都调用一次底层读取。即使你外面包了BufferedInputStream它也只是让这些调用变快一点点但依然要经历反复的方法调用、边界检查、字节拼接。数据量一上来这代码就是时间黑洞。同一个文件用8KB缓冲区分块读可能只需要0.5秒用单字节读可能要30秒以上。这种差距就是面试官问“怎么优化文件读取性能”时的标准答案。3.3 大文件的最后一公里两阶段策略处理超大文件尤其是在内存受限的服务上我建议采用“分块处理分批落盘”的两阶段策略。第一阶段用流式读取每一批数据处理完立刻释放引用第二阶段对中间结果做合并或汇总。这比一次性把整个文件载入内存后处理再写回要稳得多。public static void recompressLargeFile(String src, String dest) throws IOException { try (BufferedReader reader new BufferedReader( new InputStreamReader(new FileInputStream(src), StandardCharsets.UTF_8)); BufferedWriter writer new BufferedWriter( new OutputStreamWriter(new FileOutputStream(dest), StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { // 处理逻辑比如压缩空白字符 String newLine line.replaceAll(\\s, ).trim(); writer.write(newLine); writer.newLine(); } } }这个写法把内存占用压到最低无论文件多大同一时刻内存里只有一两行数据。代价就是只能做逐行处理没法做全局排序这类依赖完整数据集的运算。适用场景和限制我心里很清楚你用它之前也得先问自己这个处理能不能流式完成4. 文件读写的隐藏雷区编码、路径与句柄泄漏这部分是实战里炸人最多的地方。网上教程很少正面讲这些东西但你在生产环境遇到一次能记一辈子。4.1 编码问题为什么我的中文全是乱码乱码的根源是写入时用一种编码、读取时用了另一种编码。最常见的组合就是用GBK写出再用UTF-8读回。在中文Windows环境下如果你直接new FileWriter(a.txt)FileWriter默认用系统字符集也就是GBK到了Linux服务器上代码里没指定编码FileReader默认UTF-8立马乱给你看。根治办法其实一句话所有涉及字符与字节转换的地方显式指定Charset。不要信“默认字符集”不要依赖环境你的代码在自己的机器上能跑不代表在别人机器上也能正确显示。我一般约定项目里所有文本文件统一用UTF-8然后输入输出时都强制加上StandardCharsets.UTF_8。4.2 路径分隔符你到底该用“/”还是“\”Windows用反斜杠\作为路径分隔符Linux和macOS用正斜杠/。你写死在代码里的路径换一个平台就崩。这个问题如此常见以至于我在代码规范里专门加了一条文件路径拼接一律用File.separator或者Paths.get()。// 错误写死分隔符跨平台就炸 String path data \\ logs; // 正确自动适配平台 File file new File(data, logs); Path path Paths.get(data, logs);另外提醒一句正斜杠/在Windows平台的Java里也能识别而反斜杠在Linux下就是一个普通字符。如果你只是临时拼路径用/往往也能跑但不建议养这个习惯。规范写File.separator或Paths.get准没错。4.3 文件句柄泄漏你关流的方式决定了系统能扛多久这是我最想强调的一点每打开一个文件操作系统就分配一个文件描述符。如果你只开不关达到系统上限后后续所有文件操作都会失败报“Too many open files”。这种故障排查起来极其痛苦因为报错的地方往往离泄漏源头很远。Java 7之后try-with-resources是官方推荐的资源管理方式。它保证无论代码正常执行还是抛出异常所有实现AutoCloseable的资源都会被自动关闭。你唯一要做的就是把流对象声明放在try后面的括号里try (InputStream in new FileInputStream(a.txt); OutputStream out new FileOutputStream(b.txt)) { // 读写逻辑 } // 自动关闭不用写finally里一堆if (in ! null)不要用“反正JVM会回收”来安慰自己。垃圾回收只在堆内存紧张时才会触发你永远不知道文件描述符耗尽发生在GC之前还是之后。手动close的老写法不仅要包一层finally还要把每个close都做null判断代码难看且容易漏。我现在的代码库里已经几乎没有传统Finally块了。4.4 权限与文件不存在IOException之外的隐藏炸弹本地文件操作里最隐蔽的坑是文件存在、但你没有写权限。程序会抛出FileNotFoundException——注意这它在某些情况下还真不表示“文件不存在”也可能是“没有权限访问”。如果你以为它只是没文件排查方向就会跑偏。还有一个细节是文件锁。多人协作系统里两个进程同时写同一个文件后写入的会覆盖先写入的。你自己单机测试永远不会出这种问题上了多实例部署就翻车。日常单机场景不需要加锁但分布式部署的文件读写建议用文件锁或者干脆避免共享同一文件。5. 传统IO、NIO、Files工具类的选型对比现在Java在I/O方面有三套并列的API传统的java.io、Java NIOjava.nio、以及Java 8之后的Files与Path。很多新手不知道什么时候用哪个我把它们放在一起说清楚。需求场景推荐方案理由小文本文件整体读写Files.readString / writeString一行搞定JDK 11大文件逐行流式处理BufferedReader / Files.lines内存可控二进制大文件复制BufferedInputStream BufferedOutputStream兼容所有Java版本随机访问、断点续传RandomAccessFile / FileChannel支持定位批量文件操作复制目录、遍历Files.walk / Path简洁且链式对象持久化ObjectOutputStream 或 自定义二进制看需求传统IO的优势在于简单直观、生态兼容性最好老代码全是这套。NIO引入Channel和Buffer适合高性能网络传输、文件映射等场景但代码复杂度明显更高。Files工具类则在简单任务上最省力比如拷贝文件Files.copy()一行就能完成。我的建议是四个字按需取用。业务代码里操作小文件用Files就对了处理大文件或流式逻辑传统IO的Buffer系列依然能打网络通信、非阻塞场景才会轮到NIO上场。不存在谁能完全替代谁把它们都装进工具箱才是正道。6. 经典面试题你会在白纸上怎么写文件拷贝这个问题我在面试里问过不下百次基本能筛出七八成的候选人。题目很简单手写一个文件拷贝方法不限制工具类。但我看答案时重点是观察几个细节。第一层看有没有用缓冲区。如果候选人直接Files.readAllBytes()然后Files.write()我会继续追问内存占用问题。第二层看有没有用try-with-resources。如果写的是finally里逐个close我不会直接判错但印象分会降。第三层看有没有关注字节长度的边界条件也就是write(buffer, 0, len)而不是write(buffer)。这个点能抓住的人说明是真的踩过文件的坑。正确的参考版本如下public static void copy(String src, String dest) throws IOException { try (InputStream in new BufferedInputStream(new FileInputStream(src)); OutputStream out new BufferedOutputStream(new FileOutputStream(dest))) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } } }追问环节我会问如果文件大小超过内存怎么办答案就是上面的分块读。再追问如果要求一边读一边计算MD5呢答案是在读取循环里调用MessageDigest的update方法而不是读完全部再算——这样既省内存又省时间。能看到这一步的候选人项目经验基本是真实的。7. 一组顺手可用的速查表最后上一张我收藏多年的常见问题速查表按“症状-原因-解法”的格式整理方便你直接对照排查。这里面有一半是我自己在生产环境里踩过的另一半是从同事的血泪教训里总结的含金量非常高。症状常见原因解决方案中文全部乱码写入与读取编码不一致统一UTF-8显式指定Charset读到一半抛出EOFException数据长度与读取次数不匹配核对写入顺序与读取顺序文件末尾多出一堆0字节用write(buffer)而不是write(buffer,0,len)记住只写实际读取长度程序频繁报Too many open files流未关闭或未及时关闭用try-with-resourcesLinux正常、Windows乱码路径分隔符写死为“/”或“\”用Paths.get或File.separatorGB级文件读一次内存爆满一次性readAllBytes或者数组开太大流式读取8KB缓冲修改后的字段没有保存进文件序列化版本的serialVersionUID不匹配显式声明serialVersionUID文件明明存在却FileNotFoundException没有读权限或者文件被占用检查权限和占用进程顺带补充一条我自己的使用习惯程序里尽量少用绝对路径多用相对路径或配置项。绝对路径换一台机器就失效而相对路径只要在项目根目录运行通常不会有问题。配置化的路径还能做到不修改代码就切换环境这对交付维护都友好得多。最后聊点实在的。我见过太多人把“IO会用”和“IO懂”混为一谈。能用InputStream读文件只算第一步真正的分水岭在于面对一个具体的文件操作时你能不能在不查资料的情况下写出正确、高效、健壮、可维护的代码。写这篇文章时我又把java.io的源码翻了一遍除了确认了缓冲区与编码的细节之外最大的感触是这老家伙三十年过去了核心设计依然在线新手真正该做的不是硬啃NIO而是先把传统IO玩得滚瓜烂熟。把它吃透后面学什么文件操作都快。
阅读完成 · 觉得有帮助？
