Java IO流文件读写实战：从File对象到NIO，避开编码与内存坑

做Java开发这几年我经常看到工作两三年的同事在IO流上翻车。创建文件、读取文件听起来再基础不过可一旦涉及编码、目录、流关闭、大文件处理各种问题就全冒出来了。这篇文章就把我实战中通过IO流创建文件和读取文件的心得整理一遍适合Java新人快速建立完整认知也适合准备java面试题的朋友拿来查漏补缺。我会从File对象的本质讲起带你把字节流、字符流、NIO工具类的常用写法全部过一遍再分享几个我在真实项目里排查过的文件读写事故。1. 别被new File骗了路径与真实文件之间的距离先问你一个我面试实习生时特别喜欢问的问题执行完new File(D:/logs/info.log)之后磁盘上生成了 info.log 吗很多人的答案是“生成了”这是对Java IO的第一个误解。File对象在JVM里只是维护了一个路径字符串它既不创建文件也不维护文件内容你可以把它理解成一张写有地址的便利贴。你说“我要读这个文件”系统才会拿着这张便利贴去磁盘上找对应的实体。真正让文件出现在磁盘上的是createNewFile()方法或者是你往这个路径上写出数据时触发的输出流。1.1 File对象只是路径的抽象壳看这段代码File file new File(D:/data/hello.txt); System.out.println(file.exists()); // false System.out.println(file.isFile()); // falsenew File执行完之后D:/data/hello.txt这个文件可能根本不存在。file.exists()会返回false因为磁盘上没这个实体。这时候你该做的不是怀疑代码写错了而是要意识到File对象不会主动帮你完成任何磁盘操作。真正创建文件的方法是这样的File file new File(D:/data/hello.txt); boolean created file.createNewFile(); System.out.println(创建结果 created);createNewFile()有两个关键行为需要注意第一如果文件已经存在它不会覆盖而是返回false第二如果父目录D:/data不存在它会直接抛出IOException而不是自动补建目录。这个坑我见得太多了——新手写代码发现报错FileNotFoundException一脸迷茫我明明是要“创建文件”怎么变成了“文件未找到”其实这里的FileNotFoundException正是因为父目录不存在导致根本无从创建。1.2 创建文件前先搞定目录所以正规的做法是先确保父目录存在再创建文件。用下面这个工具方法基本够用了public static File getOrCreateFile(String filePath) throws IOException { File file new File(filePath); File parent file.getParentFile(); if (parent ! null !parent.exists()) { parent.mkdirs(); } if (!file.exists()) { file.createNewFile(); } return file; }注意这里我用的是mkdirs()而不是mkdir()。mkdir()只能创建单层目录如果父目录的父目录也不存在就会失败mkdirs()会把沿途所有缺失的目录一次性建出来。日常开发里几乎都是mkdirs()。1.3 NIO的Files.createFile更现代但同样挑剔JDK 1.7之后引入了java.nio.file包处理文件更顺手Path path Paths.get(D:/data/hello.txt); Files.createDirectories(path.getParent()); Files.createFile(path);Files.createDirectories()相当于mkdirs()Files.createFile()也要求父目录已经存在。但它和createNewFile()有一个区别如果目标文件已经存在Files.createFile()会抛出FileAlreadyExistsException而不是安静地返回false。这其实更严格能避免你误以为创建成功后续写入时把数据覆盖掉。还有一个容易被忽略的点Files.createDirectories()传参如果传的是null比如路径没有父目录会先抛NullPointerException。所以我会习惯先判断path.getParent()是否为null再决定要不要创建目录。这些细节都是实际跑一跑才能发现的。2. FileOutputStream才是真正干活的人字节流写文件的三个细节如果你只想创建一个空文件createNewFile()就够了。但大部分场景是“创建文件并写入内容”这时候你真正要面对的是输出流。字节流中最常用的就是FileOutputStream它是往文件里写原始字节的直接通道。2.1 构造方法决定了覆盖还是追加FileOutputStream有两个常用的构造方法// 覆盖写文件存在则清空重写文件不存在则新建 FileOutputStream fos1 new FileOutputStream(D:/data/hello.txt); // 追加写在文件末尾续写文件不存在则新建 FileOutputStream fos2 new FileOutputStream(D:/data/hello.txt, true);这里有一个很多人没意识到的事实new FileOutputStream(file)本身就具备创建文件的能力——只要父目录存在文件不存在时它会自动创建。所以我写日志文件时很少先调createNewFile()而是直接构建输出流File file new File(D:/data/app.log); File parent file.getParentFile(); if (parent ! null) { parent.mkdirs(); } try (FileOutputStream fos new FileOutputStream(file, true)) { fos.write(这是一条日志\n.getBytes(StandardCharsets.UTF_8)); }这样既搞定了目录也搞定了文件创建和内容写入一步到位。注意第5行的追加写参数true这是我在写日志场景下的习惯避免每次启动程序都把旧日志清空。2.2 编码问题随手就来getBytes()的默认编码是个坑写字符串的时候最忌讳直接写成content.getBytes()。因为getBytes()不带参数时会按照JVM的默认字符集编码。Windows中文环境下默认通常是GBKLinux服务器上默认通常是UTF-8。同一份代码在本机写出来的文件是GBK上传到Linux一读中文全乱。更麻烦的是这个差异很多时候要等到联调阶段才会暴露。我的建议是永远显式指定字符集try (FileOutputStream fos new FileOutputStream(D:/data/greeting.txt)) { String content 你好Java IO; fos.write(content.getBytes(StandardCharsets.UTF_8)); }StandardCharsets.UTF_8是JDK 1.7之后提供的常量省得抛UnsupportedEncodingException。如果是在JDK 1.6以下的老项目才需要用UTF-8字符串并处理异常。2.3 别小看close()不关流的真实后果很多人觉得“写完了程序结束流自然会关”确实程序结束时操作系统会回收资源。但问题在于如果你的程序是一个长期运行的服务器比如Tomcat里的一段代码每次写文件都不关流文件句柄会越来越多最终达到操作系统上限导致Too many open files。你的服务没崩溃但你再也创建不了新文件了。用try-with-resources足够简单try (FileOutputStream fos new FileOutputStream(D:/data/hello.txt)) { fos.write(Hello IO.getBytes(StandardCharsets.UTF_8)); } catch (IOException e) { e.printStackTrace(); }这样写无论是否抛异常流都会在代码块结束后自动关闭。注意如果我在内部又包了一个BufferedOutputStream关闭顺序会由内到外先关缓冲流此时会触发 flush 把残留数据推到底层再关文件流。顺序反了也不行。3. 字符流的温柔陷阱FileWriter虽然方便但编码默认你做不了主字节流适合处理图片、音频、压缩包这类二进制数据。但如果要读写的是文本直接操作字节太痛苦了一个中文字符在UTF-8下占3个字节你按单个字节去读还得自己拼字符。于是Java提供了字符流最经典的是FileReader和FileWriter。3.1 为什么有了字节流还要字符流字符流的底层仍然是字节流只不过中间多了一层编码转换。它每次读取的是一个完整的char而不是碎片化的byte处理文本逻辑更清晰。用汽车做类比字节流是单件搬货字符流是一个集装箱一次运一批货而这批货在进集装箱之前/之后要过一道翻译编码转换。拿写文件来说FileWriter确实很直接try (FileWriter fw new FileWriter(D:/data/hello.txt)) { fw.write(你好字符流); }不用指定编码不用把字符串转成字节数组直接写字符串非常方便。但方便是有代价的——编码你说了不算。3.2 FileWriter默认编码的坑FileWriter内部用的是平台默认编码。怎么理解在Windows简体中文系统上默认字符集是GBK于是你写出来的文件就是GBK编码。在大多数Linux发行版上默认字符集是UTF-8于是写出来就是UTF-8编码。如果同一个文件在两个系统之间来回倒腾或者你的程序依赖某个固定编码去解析这个文件乱码就来了。我就遇到过一次测试环境的案例开发在Windows上用FileWriter生成了一版导入模板丢到Linux服务器上跑批服务端用UTF-8读取文件里的中文全部变成“锟斤拷”。根因就是Windows下写入时用了GBKLinux读取时用了UTF-8。这问题在开发环境根本复现不了因为两边都是同一套默认编码。3.3 一个自动编码的字符流写入模板解决方式很简单绕开FileWriter自己指定编码。方式一用OutputStreamWriter包装FileOutputStreamtry (BufferedWriter bw new BufferedWriter( new OutputStreamWriter( new FileOutputStream(D:/data/template.csv), StandardCharsets.UTF_8 ) )) { bw.write(姓名,年龄,城市); bw.newLine(); bw.write(张三,28,上海); }方式二用JDK 1.7之后的Files.newBufferedWriter简洁得多Path path Paths.get(D:/data/template.csv); Files.createDirectories(path.getParent()); try (BufferedWriter bw Files.newBufferedWriter(path, StandardCharsets.UTF_8)) { bw.write(姓名,年龄,城市); bw.newLine(); bw.write(张三,28,上海); }Files.newBufferedWriter默认也是覆盖写文件不存在会自动创建但父目录必须提前存在。所以上面我仍然先调了createDirectories。这套组合把文件创建、字符集控制、缓冲性能一次性解决。4. 读取文件别蛮干三种读取姿势的选择与取舍说完了写再来说读。读文件最容易犯的错就是“一招吃遍天下”不管什么文件都Files.readAllBytes()一把梭。读完了能跑但一旦文件变大JVM堆内存就会告急。我一般把读取方式分成三档按文件大小和业务场景来选。4.1 老派读取FileInputStream与byte[] 逐段读用FileInputStream读取的经典代码长这样try (FileInputStream fis new FileInputStream(D:/data/binary.dat)) { byte[] buffer new byte[8192]; int len; while ((len fis.read(buffer)) ! -1) { // 处理 buffer 中从下标0到len-1的有效数据 } }注意read(byte[])的返回值是实际读取到的字节数最后一次读取很可能不足buffer.length不能把buffer整个当成有效数据。这个细节在面试里也常被问到。如果读的是文本我不建议直接用FileInputStream读字符。因为它只给你字节字符集解码你得自己做很容易出错。文本场景往下看字符流。4.2 按行读取的BufferedReader时代文本文件最实用的是按行读。早期写法是FileReader但和FileWriter一样默认编码是坑所以我配InputStreamReader手动指定UTF-8try (BufferedReader br new BufferedReader( new InputStreamReader( new FileInputStream(D:/data/config.ini), StandardCharsets.UTF_8 ) )) { String line; while ((line br.readLine()) ! null) { // 处理每一行 System.out.println(line); } }readLine()读到流结束时返回null所以循环条件判断line ! null。这个读法适合日志分析、配置文件解析、CSV处理。BufferedReader内部默认缓冲8KB减少了IO系统调用性能比直接用FileReader读单个char快得多。4.3 一行代码读文件Files.readAllLines与Files.readString如果只是读一个不大的配置文件比如几KB或几十KB用NIO的便捷方法最爽String content Files.readString(path, StandardCharsets.UTF_8);或者拆成行列表ListString lines Files.readAllLines(path, StandardCharsets.UTF_8); for (String line : lines) { // 处理每一行 }一个是把整个文件拼成单个字符串一个是把所有行放进ListString。两者都是“全量进内存”小文件完全没问题但你要有底线意识大于几十MB的文件就别这么玩了堆内存很容易撑爆。还有一个折中方案Files.lines()返回的是StreamString它是惰性读取的不会一次性把所有行加载进内存try (StreamString lines Files.lines(path, StandardCharsets.UTF_8)) { lines.forEach(System.out::println); }注意Stream也实现了AutoCloseable所以我给它套了一层try-with-resources避免流泄漏。这个方法适合处理几百MB的大日志文件。读取方式的选择我做了一张表方便你按需取用读取方式适用场景主要风险FileInputStream byte[]二进制文件、图片等文本需自行解码BufferedReader InputStreamReader按行读文本通用手动指定编码易被遗漏Files.readString / readAllBytes小文本文件大文件内存溢出Files.readAllLines中小配置文件全量进内存Files.lines大文件按行处理流必须关闭5. 文件读写的经典事故现场目录、编码、内存、权限这一节我把这几年在项目里实际排查过的文件读写事故集中复盘一下。每一个都真实也都让人印象深刻。排查思路比答案更重要。5.1 父目录不存在的“FileNotFoundException”陷阱有一次同事的定时任务突然报错异常是java.io.FileNotFoundException: /data/backup/tmp/report_20240101.zip (No such file or directory)。他百思不得其解这个文件不是会创建吗我让他先看一眼/data/backup/tmp目录存在不存在结果果然tmp目录当时被运维清理掉了。这个事故的根因是FileOutputStream创建文件时不会自动创建父目录。所以只要任何第三方删掉了父目录你的代码就瞬间崩。排查这类问题第一看异常信息里的路径第二看父目录是否存在。修复方案也简单每次写文件前先Files.createDirectories(path.getParent())保证父目录在。5.2 乱码与平台默认编码一台Windows测试机引发的血案有次联调一个第三方接口对方要求我们回传一个UTF-8编码的XML文件。我们本地Linux测试没问题但客户现场一台Windows服务器生成的文件对方解析出来全是乱码。查了很久最后发现我们代码里用了FileWriter在Windows上默认用了GBK写入文件虽然后缀是XML但字符编码根本不是约定的UTF-8。排查方案拿到出问题的文件用十六进制的编辑器打开看“中文”部分的字节序列。UTF-8的“你”是E4 BD A0GBK的“你”是C4 E3一眼就能区分。修复方案替换成new OutputStreamWriter(new FileOutputStream(file), StandardCharsets.UTF_8)从此统一编码。这一条强烈建议写进你们团队的代码规范。5.3 内存不足和大文件忽略问题还有人用Files.readAllBytes()读取一个2GB的数据库导出文件结果JVM直接OutOfMemoryError: Java heap space。这其实不是你代码逻辑错而是技术选型错一次性读入的内存模型根本装不下大文件。正确的处理是分块处理。如果文件是按行组织的就用Files.lines()配合Stream如果确实是二进制大文件就用FileInputStream配一个固定大小的byte[]循环读边读边处理绝不让整份内容常驻内存。遇到这种问题先确认文件大小再去看代码里有没有readAllBytes或者readAllLines基本定位很快。5.4 Windows上的文件占用与权限问题这个问题Windows上特别常见文件被Excel或者记事本打开着Java程序去写它然后抛FileNotFoundException或者AccessDeniedException。注意这里并不是文件不存在而是文件被其他进程独占操作系统拒绝写入。排查思路先关闭可能占用文件的程序Excel、WPS、浏览器下载进程、杀毒软件扫描等再重试。如果想在代码层面规避一种做法是先写到一个临时文件再通过Files.move原子替换目标文件。但Files.move也不是万能目标文件如果被占用同样会失败。Linux下还会有目录写权限问题常见的报错是Permission denied。可以用ls -l看目录权限确认运行Java进程的用户是否对这个目录有写权限。6. IO流面试里真正想听的答案缓冲、编码与桥接这个问题在java面试题里几乎必考。很多人能背出“字节流、字符流、FileInputStream、FileOutputStream”但一深问就露馅。面试官真正想听的是你对IO模型底层逻辑的理解。6.1 字节流和字符流的本质差异字节流是原生通道每次处理一个或多个字节它不关心内容是什么只知道往字节流里塞字节或者从字节流里取字节。字符流是建立在字节流之上的“翻译层”它负责按某个字符集把字节解码成字符或者把字符编码成字节。所以字符流处理文本更方便但处理图片、音视频等非文本文件你只能用字节流硬上字符流只会得到一堆乱码。面试时你可以这样表达“字符流底层一定有一个字节流外加一个Charset编码解码器。比如FileReader就是FileInputStream加上平台默认Charset实现的。所以我更习惯自己指定编码。”6.2 缓冲流为什么能快减少系统调用BufferedInputStream/BufferedOutputStream/BufferedReader/BufferedWriter这四个缓冲类是面试里的高频词。为什么加了一层缓冲就变快因为每次IO读写操作系统是要付出系统调用代价的一次系统调用从用户态切换到内核态开销不小。没有缓冲你每次read()或write()都直接触发系统调用有了缓冲底层数据会先攒到一个8KB的数组里攒满了再一次性传给操作系统系统调用次数大幅减少。用个土例子没缓冲就是一趟趟搬砖一次一块有缓冲先搬满一车再整挂车运过去。砖的总量没变但跑的次数少了几百倍。6.3 桥接字节流如何优雅地变成字符流InputStreamReader和OutputStreamWriter就是桥接类。它们的构造方法接收一个字节流和一个字符集然后从字节流中解码出字符或编码成字节。我最常用的写法在前面出现过BufferedReader br new BufferedReader( new InputStreamReader( new FileInputStream(data.txt), StandardCharsets.UTF_8 ) );这句代码把FileInputStream变成Reader同时指定了UTF-8既保留了按行读取的便利又规避了FileReader默认编码的问题。反过来OutputStreamWriter把FileOutputStream变成Writer在写文本时同样适用。6.4 一个综合示例把今天的内容串起来下面这段代码结合了创建父目录、指定编码写入、按行读取、自动关闭全部知识点。场景读取一个文本文件把每行转为大写后写入另一个新文件。Path source Paths.get(D:/data/input.txt); Path target Paths.get(D:/data/output.txt); if (Objects.nonNull(target.getParent())) { Files.createDirectories(target.getParent()); } try (BufferedReader reader Files.newBufferedReader(source, StandardCharsets.UTF_8); BufferedWriter writer Files.newBufferedWriter(target, StandardCharsets.UTF_8)) { String line; while ((line reader.readLine()) ! null) { writer.write(line.toUpperCase(Locale.ROOT)); writer.newLine(); } }最后说一下我自己的习惯凡是代码里要读写文件我先做三件事——确认父目录存在、确定文件编码是UTF-8、用try-with-resources把流管起来。看起来都是小事但确实帮我少加了很多次班。如果你也被文件读写坑过不妨把这篇当成一份对照清单下次遇到问题按“路径、编码、内存、权限”四个方向去排查基本八九不离十。