先說(shuō)明一下我寫這篇對(duì)比的起因。雖然 Java 7 就把 NIO.2也就是 java.nio.file 這套 API帶進(jìn)來(lái)了但你去翻很多生產(chǎn)項(xiàng)目的代碼java.io.File依然隨處可見。不是老項(xiàng)目不敢動(dòng)而是很多同學(xué)入行時(shí)學(xué)的就是File后面項(xiàng)目里new File()、file.exists()、file.delete()一路寫下來(lái)沒人提醒的話很難跳出這個(gè)慣性。這篇是 Java 文件操作對(duì)比系列的第 4 篇也是收尾篇。前面幾篇拆了 IO 流的讀寫細(xì)節(jié)、字符編碼處理和二進(jìn)制操作這篇就專門把java.io.File和java.nio.file兩大體系做一次全方位對(duì)照。重點(diǎn)不放在“哪個(gè) API 更高級(jí)”這種口號(hào)上而是直接落到實(shí)際開發(fā)里你每天都會(huì)碰到的場(chǎng)景文件刪不掉怎么辦、目錄怎么遞歸遍歷、移動(dòng)文件是否原子、符號(hào)鏈接怎么處理、文件監(jiān)聽怎么做。每一條都會(huì)給出可跑的示例和我會(huì)踩的坑。1. API 設(shè)計(jì)與使用體驗(yàn)對(duì)比為什么 File 用著別扭1.1 設(shè)計(jì)哲學(xué)一坨類 vs 一條路徑加一個(gè)工具類java.io.File最大的問(wèn)題在于它既是“路徑的表示”又是“文件操作的入口”。你new File(a.txt)并沒有真正觸達(dá)文件系統(tǒng)它只包裝了一個(gè)路徑字符串但同一個(gè)對(duì)象上你又可以調(diào)用exists()、delete()、mkdirs()這些方法去修改真實(shí)文件系統(tǒng)。路徑表示和狀態(tài)操作混在一起職責(zé)非常散。而java.nio.file把這兩件事拆開了。Path只負(fù)責(zé)“描述一個(gè)路徑”不帶任何文件系統(tǒng)操作真正的讀寫、復(fù)制、移動(dòng)、刪除、屬性查詢?nèi)渴諗康紽iles這個(gè)工具類里。也就是說(shuō)你拿到一個(gè)Path對(duì)象它只是一個(gè)不可變的位置標(biāo)記想對(duì)它做什么再通過(guò)Files靜態(tài)方法傳入這個(gè)Path。類名上也容易踩坑。java.io.File叫“文件”但它其實(shí)也能代表目錄Path叫“路徑”聽上去好像是給文件用的實(shí)際指向文件或目錄都行。理解這個(gè)職責(zé)分離之后寫代碼的思路會(huì)清晰很多先構(gòu)造路徑再?zèng)Q定操作而不是在一個(gè)對(duì)象上調(diào)來(lái)調(diào)去。1.2 失敗模型靜默 boolean 與顯式異常這是兩套 API 使用體驗(yàn)差異最大的地方也是從File遷到 NIO 后最先感覺“舒服”的點(diǎn)。java.io.File的寫操作基本都是返回boolean比如File file new File(/tmp/data/report.txt); boolean deleted file.delete(); if (!deleted) { // 到底為什么失敗權(quán)限不存在目錄非空完全不知道 }delete()返回false的原因可能是不存在、沒有權(quán)限、文件被占用但老 API 不會(huì)告訴你具體是哪一種。排查問(wèn)題全靠猜。mkdir()、renameTo()同理。java.nio.file的做法完全不同刪除操作要么成功要么拋出帶具體類型的異常Path path Paths.get(/tmp/data/report.txt); Files.delete(path); // 文件不存在 - NoSuchFileExceptionNoSuchFileException是IOException的子類你能從異常類一眼看出問(wèn)題文件不存在。權(quán)限問(wèn)題拋AccessDeniedException目錄非空刪除失敗會(huì)得到DirectoryNotEmptyException路徑格式不對(duì)拋InvalidPathException。這些異常類本身就攜帶了足夠多的排查信息。所以我的建議很直接新代碼一律用Files老代碼如果還在寫boolean ok file.delete()這種邏輯至少加個(gè)日志把它為什么失敗打印出來(lái)否則線上出問(wèn)題沒法定位。下面給一個(gè)簡(jiǎn)單的語(yǔ)義對(duì)照表操作java.io.Filejava.nio.file失敗表現(xiàn)刪除文件delete()Files.delete(path)返回 false / 拋異常刪除存在才刪delete()后判斷返回值Files.deleteIfExists(path)返回 boolean / 返回 false創(chuàng)建目錄mkdir()Files.createDirectory(path)返回 false / 拋異常創(chuàng)建多級(jí)目錄mkdirs()Files.createDirectories(path)返回 false / 拋異常判斷存在exists()Files.exists(path)返回 boolean / 返回 boolean1.3 資源釋放數(shù)組免操心流必須關(guān)File.listFiles()返回的是File[]數(shù)組拿到數(shù)組后不需要額外釋放什么資源。這看上去很省事但代價(jià)是“一次性全量加載”。如果目錄里有十萬(wàn)個(gè)文件數(shù)組會(huì)一次性把全部條目加載進(jìn)內(nèi)存。NIO 的Files.newDirectoryStream()返回一個(gè)DirectoryStreamPath可以邊遍歷邊處理但注意它是AutoCloseable的必須關(guān)閉否則會(huì)泄漏文件句柄。try (DirectoryStreamPath stream Files.newDirectoryStream(dir)) { for (Path entry : stream) { // 處理 entry } } // 自動(dòng) closeFiles.list()和Files.walk()返回的是StreamPath同樣需要關(guān)閉。很多人會(huì)忽略這一點(diǎn)因?yàn)镾tream平時(shí)用起來(lái)不像“資源”。事實(shí)上Files.list()底層就包了一個(gè)DirectoryStream如果不用try-with-resources包住流不關(guān)閉句柄就會(huì)一直占著。Windows 上尤其明顯文件被句柄占著后面想刪除或移動(dòng)都會(huì)失敗。2. 路徑處理File 的歷史包袱與 Path 的現(xiàn)代化2.1 分隔符別再自己拼字符串了舊的FileAPI 里最常見的路徑拼接寫法是這樣String path data File.separator 2025 File.separator report.txt;如果不小心用了File.separatorWindows 和 Linux 還能自適應(yīng)但很多人圖省事直接寫死/或者\(yùn)\。其實(shí)File內(nèi)部能處理兩種分隔符只是拼接出來(lái)的字符串在跨平臺(tái)場(chǎng)景容易被其他組件誤解。Path從根本上消滅了這類問(wèn)題。使用Paths.get()傳入多個(gè)片段NIO 會(huì)自動(dòng)用當(dāng)前文件系統(tǒng)的分隔符拼接Path path Paths.get(data, 2025, report.txt);在 Windows 上它會(huì)得到data\2025\report.txt在 Linux 上得到data/2025/report.txt。無(wú)論后面是直接交給Files操作還是傳給其他接口都不會(huì)出現(xiàn)分隔符不一致的問(wèn)題。實(shí)際開發(fā)里我?guī)缀醪辉偈謩?dòng)拼接路徑字符串全部用這種可變參數(shù)構(gòu)造方式。2.2 絕對(duì)路徑與規(guī)范路徑一個(gè)“不碰磁盤”一個(gè)“必須碰”File提供了兩個(gè)容易混淆的方法getAbsolutePath()和getCanonicalPath()。getAbsolutePath()純粹從字面上補(bǔ)全路徑不會(huì)解析..和.也不會(huì)訪問(wèn)文件系統(tǒng)。getCanonicalPath()會(huì)解析..、.、符號(hào)鏈接返回“規(guī)范路徑”。因?yàn)樗L問(wèn)文件系統(tǒng)所以方法簽名上直接聲明了throws IOException。Path對(duì)應(yīng)的是toAbsolutePath()和toRealPath()。其中toRealPath()等價(jià)于getCanonicalPath()的增強(qiáng)版默認(rèn)會(huì)解析符號(hào)鏈接也可以通過(guò)參數(shù)LinkOption.NOFOLLOW_LINKS不跟隨鏈接Path path Paths.get(/tmp/data/../data/report.txt); System.out.println(path.toAbsolutePath()); // /tmp/data/../data/report.txt帶著 .. System.out.println(path.normalize()); // /tmp/data/report.txt詞法規(guī)約不碰磁盤 System.out.println(path.toRealPath()); // 解析符號(hào)鏈接要求文件必須存在否則拋異常三者各有用途。配置文件加載時(shí)我通常用toRealPath()因?yàn)樗鼤?huì)順帶校驗(yàn)文件是否存在如果只是想規(guī)整一下路徑格式但文件還不一定存在就用normalize()。搞清楚這三者的區(qū)別比記住一堆 API 名字有用得多。2.3 路徑段操作subpath 這類高階能力 File 完全沒有File里跟路徑段有關(guān)的只有g(shù)etName()、getParent()、getPath()想取完整路徑中的某一段需要自己在字符串上切。Path提供了更結(jié)構(gòu)化的能力Path path Paths.get(/projects/order-service/src/main/java/OrderService.java); System.out.println(path.getNameCount()); // 7 System.out.println(path.getName(0)); // projects System.out.println(path.subpath(0, 4)); // projects/order-service/src/main System.out.println(path.getFileName()); // OrderService.java System.out.println(path.getRoot()); // /subpath(0, 4)這種“截取中段路徑”的能力在按目錄結(jié)構(gòu)掃描代碼、按約定解析模塊路徑時(shí)特別好用。老代碼要實(shí)現(xiàn)相同的邏輯基本只能split(/)然后自己拼數(shù)組還得分隔符在不同平臺(tái)的差異。路徑段的操作能力是 NIO 對(duì)舊 API 一次實(shí)打?qū)嵉慕稻S打擊。3. 文件元數(shù)據(jù)從多次 stat 到一次屬性視圖3.1 存在性與類型判斷老代碼里最常見的判斷邏輯是這樣File f new File(/tmp/conf/application.yml); if (f.exists() f.isFile()) { // 讀配置 }這段代碼在大多數(shù)場(chǎng)景沒問(wèn)題但如果/tmp/conf/application.yml是一個(gè)符號(hào)鏈接就得小心了。java.io.File的isDirectory()和isFile()默認(rèn)會(huì)跟隨符號(hào)鏈接——也就是說(shuō)如果符號(hào)鏈接指向的是一個(gè)目錄isFile()會(huì)返回falseisDirectory()會(huì)返回true但有時(shí)候你恰恰想知道“這個(gè)鏈接本身指向什么類型”。NIO 的Files系列方法提供了LinkOption參數(shù)Path path Paths.get(/tmp/conf/application.yml); // 判斷是否是目標(biāo)類型跟隨鏈接 boolean isFile Files.isRegularFile(path); // 判斷鏈接本身的屬性不跟隨鏈接 boolean isFileNoFollow Files.isRegularFile(path, LinkOption.NOFOLLOW_LINKS); // 直接判斷是不是符號(hào)鏈接 boolean isSymlink Files.isSymbolicLink(path);實(shí)際項(xiàng)目里處理配置文件路徑時(shí)我一般先用Files.isSymbolicLink()判斷一下再?zèng)Q定是否讀取鏈接目標(biāo)。如果只是簡(jiǎn)單判斷目錄是否存在用Files.isDirectory(path)就夠但涉及符號(hào)鏈接的部署場(chǎng)景不加上NOFOLLOW_LINKS很容易誤判。3.2 屬性視圖一次調(diào)用拿全套元數(shù)據(jù)File查詢文件大小和修改時(shí)間需要分別調(diào)用File f new File(/tmp/data.bin); long size f.length(); long lastModified f.lastModified(); boolean isDir f.isDirectory(); boolean isHidden f.isHidden();每次調(diào)用都可能觸發(fā)一次文件系統(tǒng)操作也就是一次 stat。雖然單次 stat 開銷不大但在批量處理成千上萬(wàn)個(gè)文件時(shí)反復(fù)查詢多個(gè)屬性會(huì)讓性能明顯變差而且代碼也啰嗦。NIO 的Files.readAttributes()可以一次讀取整套屬性BasicFileAttributes attrs Files.readAttributes(path, BasicFileAttributes.class); long size attrs.size(); long lastModified attrs.lastModifiedTime().toMillis(); long creationTime attrs.creationTime().toMillis(); boolean isDirectory attrs.isDirectory(); boolean isRegularFile attrs.isRegularFile(); boolean isSymbolicLink attrs.isSymbolicLink();一次系統(tǒng)調(diào)用拿到全部信息。需要區(qū)分文件類型時(shí)attrs.isRegularFile()和attrs.isDirectory()已經(jīng)幫你分好了不用像File那樣先exists()再isFile()做兩次判斷。如果需要更精細(xì)的屬性還可以換用視圖類視圖類適用平臺(tái)擴(kuò)展屬性BasicFileAttributes所有大小、時(shí)間、文件類型DosFileAttributesWindows隱藏、只讀、歸檔、系統(tǒng)文件PosixFileAttributesLinux/macOS權(quán)限、屬主、屬組PosixFileAttributes posix Files.readAttributes(path, PosixFileAttributes.class); SetPosixFilePermission perms posix.permissions();這套屬性視圖機(jī)制在File時(shí)代是完全缺失的。拿File查 Linux 文件的讀、寫、執(zhí)行權(quán)限只能通過(guò)canRead()、canWrite()、canExecute()三個(gè)方法分別判斷拿不到具體的權(quán)限組合更拿不到屬主屬組。3.3 修改屬性從粒度過(guò)粗到精細(xì)可控File提供的修改能力很有限翻來(lái)覆去就那幾個(gè)file.setReadOnly(); // 只讀 file.setWritable(true, false); // 當(dāng)前用戶可寫ownerOnlyfalse file.setExecutable(true); // 當(dāng)前用戶可執(zhí)行 file.setLastModified(timestamp); // 修改時(shí)間粒度非常粗。想要“給所有用戶加執(zhí)行權(quán)限”這種操作File根本做不了只能借助外部命令。NIO 則可以通過(guò) PosixFilePermissions 精確控制權(quán)限位SetPosixFilePermission perms PosixFilePermissions.fromString(rwxr-x---); Files.setPosixFilePermissions(path, perms);fromString(rwxr-x---)這種寫法非常直觀一眼就能看出屬主是rwx、屬組是r-x、其他用戶是---。生產(chǎn)環(huán)境里我經(jīng)常用來(lái)給腳本文件加執(zhí)行權(quán)限部署完直接一條命令生效。這個(gè)能力在File時(shí)代只能靠Runtime.exec(chmod 750 xxx)繞過(guò)去麻煩還容易踩轉(zhuǎn)義坑。4. 目錄遍歷與遞歸刪除三種寫法的演進(jìn)4.1 遍歷一個(gè)目錄null 的坑和必須關(guān)閉的流File.listFiles()最大的坑是返回值。如果目錄里面沒有條目它返回空數(shù)組但如果發(fā)生了 IO 錯(cuò)誤比如目錄不存在、權(quán)限不足它返回null。如果代碼拿到null不去判空直接for遍歷瞬間NullPointerException。File[] files dir.listFiles(); if (files ! null) { // 必須判空否則可能 NPE for (File f : files) { // ... } }NIO 的Files.newDirectoryStream()遇到目錄不存在時(shí)直接拋NoSuchFileException不會(huì)返回null也沒有必要判空。更輕量的是Files.list()返回StreamPath配合現(xiàn)代 Java 的函數(shù)式風(fēng)格非常自然try (StreamPath stream Files.list(Paths.get(/tmp/data))) { stream.filter(Files::isRegularFile) .filter(p - p.toString().endsWith(.log)) .forEach(System.out::println); }這三個(gè)方法的取舍我實(shí)際使用下來(lái)是只是列目錄、無(wú)需過(guò)濾和自定義屬性查詢用Files.list()需要過(guò)濾條件比較復(fù)雜的比如只挑大于某個(gè)大小的文件用Files.newDirectoryStream()配合自定義過(guò)濾器更清晰如果目錄很大優(yōu)先newDirectoryStream()邊讀邊處理避免一次性加載全部條目到內(nèi)存。4.2 深度遍歷walk 與 walkFileTree 怎么選按目錄樹遞歸遍歷是文件操作里最高頻的需求之一。File時(shí)代只能手寫遞歸大概長(zhǎng)這樣void listAll(File dir) { File[] files dir.listFiles(); if (files null) return; for (File f : files) { if (f.isDirectory()) { listAll(f); } else { System.out.println(f.getPath()); } } }NIO 提供了兩種現(xiàn)成的深度遍歷方案。第一種Files.walk()惰性遍歷并返回StreamPath適合過(guò)濾、收集類的場(chǎng)景try (StreamPath stream Files.walk(Paths.get(/tmp/data))) { stream.filter(Files::isRegularFile) .forEach(System.out::println); }第二種Files.walkFileTree()基于訪問(wèn)者模式需要寫一個(gè)SimpleFileVisitor。它最大的優(yōu)勢(shì)是能夠在“進(jìn)入目錄前”“離開目錄后”“訪問(wèn)文件時(shí)”“訪問(wèn)失敗時(shí)”四個(gè)時(shí)機(jī)分別插入邏輯刪除目錄樹時(shí)尤其好用。Files.walkFileTree(Paths.get(/tmp/data), new SimpleFileVisitorPath() { Override public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException { Files.delete(file); return FileVisitResult.CONTINUE; } Override public FileVisitResult postVisitDirectory(Path dir, IOException exc) throws IOException { Files.delete(dir); return FileVisitResult.CONTINUE; } });FileVisitResult除了CONTINUE還有SKIP_SUBTREE跳過(guò)當(dāng)前目錄、TERMINATE終止遍歷。比如備份時(shí)需要跳過(guò).git目錄在preVisitDirectory里判斷目錄名直接返回SKIP_SUBTREE即可這種控制力是Stream方案給不了的。4.3 遞歸刪除的三種推薦寫法刪除一個(gè)非空目錄File.delete()直接失敗因?yàn)槟夸浄强?。File時(shí)代最原始的遞歸刪除長(zhǎng)這樣void deleteRecursively(File f) { if (f.isDirectory()) { File[] children f.listFiles(); if (children ! null) { for (File child : children) { deleteRecursively(child); } } } f.delete(); }NIO 時(shí)代常見三種寫法。前面提到的walkFileTree是最穩(wěn)的。第二種是利用Files.walk()配合反序刪除——因?yàn)镕iles.walk()默認(rèn)深度優(yōu)先先列出的路徑在樹的上層刪除前需要把流排序成“子路徑在前、父路徑在后”try (StreamPath stream Files.walk(Paths.get(/tmp/data))) { stream.sorted(Comparator.reverseOrder()) .forEach(p - { try { Files.deleteIfExists(p); } catch (IOException e) { throw new UncheckedIOException(e); } }); }第三種是用遞歸加Files.deleteIfExists()簡(jiǎn)潔但對(duì)深層目錄會(huì)造成較深的調(diào)用棧void deleteRecursive(Path dir) throws IOException { try (StreamPath stream Files.list(dir)) { for (Path p : stream) { if (Files.isDirectory(p, LinkOption.NOFOLLOW_LINKS)) { deleteRecursive(p); } else { Files.deleteIfExists(p); } } } Files.delete(dir); }我個(gè)人的選擇是老代碼重構(gòu)時(shí)用walkFileTree因?yàn)檎Z(yǔ)義清晰、可控性高寫一次性腳本或臨時(shí)清理邏輯時(shí)用sorted(reverseOrder())那一行流式寫法簡(jiǎn)潔。搜索“java 文件相關(guān)的操作”這個(gè)主題時(shí)遞歸刪除永遠(yuǎn)是最熱門的場(chǎng)景之一所以這里特意把三種姿勢(shì)都列出看你們項(xiàng)目風(fēng)格自取。5. 復(fù)制、移動(dòng)與刪除原子性是最容易被忽略的點(diǎn)5.1 刪除語(yǔ)義的差異File.delete()和Files.delete()的差別前面已經(jīng)提到這里再補(bǔ)一個(gè)實(shí)操場(chǎng)景清理日志文件時(shí)我們經(jīng)常遇到“目標(biāo)可能不存在”的情況。// 舊寫法 File logFile new File(/tmp/app.log); if (logFile.exists()) { // 有些人會(huì)先 exists 再 delete logFile.delete(); } // NIO 寫法 Files.deleteIfExists(Paths.get(/tmp/app.log));Files.deleteIfExists()把“存在才刪”這個(gè)語(yǔ)義封裝好了不用再手動(dòng)判存在也省掉了“exists 判斷后文件被并發(fā)刪除導(dǎo)致 delete 返回 false”的競(jìng)態(tài)問(wèn)題。需要注意deleteIfExists()在目錄非空時(shí)依然會(huì)拋DirectoryNotEmptyException所以刪除目錄還是要走遞歸方案。5.2 復(fù)制文件保留屬性是個(gè)細(xì)節(jié)活java.io.File沒有自己的復(fù)制能力老代碼通常用兩個(gè)流手動(dòng)搬運(yùn)try (InputStream in new FileInputStream(src); OutputStream out new FileOutputStream(dst)) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } }能復(fù)制內(nèi)容但源文件的修改時(shí)間、權(quán)限這些元數(shù)據(jù)全部丟失。而Files.copy()可以通過(guò)CopyOption控制復(fù)制行為Files.copy(src, dst, StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.COPY_ATTRIBUTES);REPLACE_EXISTING表示目標(biāo)存在時(shí)覆蓋COPY_ATTRIBUTES表示盡量保留源文件的屬性修改時(shí)間等。如果不加COPY_ATTRIBUTES復(fù)制出來(lái)的文件時(shí)間戳就是“當(dāng)前時(shí)間”在發(fā)布構(gòu)建產(chǎn)物的場(chǎng)景里會(huì)造成緩存判斷錯(cuò)誤。這里有個(gè)細(xì)節(jié)Files.copy()底層在不同文件系統(tǒng)上的實(shí)現(xiàn)有差異如果源和目標(biāo)在同一個(gè)文件系統(tǒng)里某些平臺(tái)會(huì)走更高效的路徑但你不必關(guān)心這些差異API 層面一致即可。另外Files.copy()復(fù)制目錄時(shí)是淺復(fù)制只復(fù)制目錄本身不會(huì)遞歸復(fù)制子目錄和文件。需要完整復(fù)制目錄樹還得配合walkFileTree逐個(gè)創(chuàng)建和復(fù)制。5.3 移動(dòng)文件renameTo 靠不住ATOMIC_MOVE 有講究File.renameTo()是舊 API 里我踩過(guò)最多坑的方法。它的行為高度依賴平臺(tái)和文件系統(tǒng)在 Windows 上如果目標(biāo)文件已經(jīng)存在renameTo()很可能失敗如果跨文件系統(tǒng)比如從 C 盤挪到 D 盤renameTo()大概率直接返回 false如果目標(biāo)文件的父目錄不存在也會(huì)失敗。最難受的是它失敗返回false你完全不知道是哪種原因。Files.move()則干凈得多Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING);這在同一個(gè)文件系統(tǒng)內(nèi)基本是原子的。如果需要把原子性作為硬性要求可以加上AtomicMoveNotSupportedException兜底try { Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING, AtomicMoveOption.ATOMIC_MOVE); } catch (AtomicMoveNotSupportedException e) { // 文件系統(tǒng)不支持原子移動(dòng)降級(jí)為普通 move Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING); }ATOMIC_MOVE保證移動(dòng)操作要么完成、要么完全沒發(fā)生。文件替換、日志輪轉(zhuǎn)這類場(chǎng)景特別看重這個(gè)語(yǔ)義——如果你在進(jìn)程正在寫文件時(shí)做替換非原子移動(dòng)可能出現(xiàn)目標(biāo)文件短暫不存在或內(nèi)容不完整的情況。這一點(diǎn)在生產(chǎn)環(huán)境里尤其重要比如部署新版本 jar 包如果不用原子替換的方式服務(wù)重啟瞬間可能讀到半截文件。5.4 臨時(shí)文件與退出清理File.createTempFile()和File.deleteOnExit()是老代碼里常見的組合File temp File.createTempFile(data, .tmp); temp.deleteOnExit();deleteOnExit()會(huì)在 JVM 退出時(shí)刪除文件邏輯本身還好但有幾個(gè)坑它只刪除注冊(cè)的這個(gè)文件不清理目錄而且如果文件已經(jīng)被刪除它不會(huì)報(bào)錯(cuò)。更麻煩的是如果 JVM 被kill -9強(qiáng)殺deleteOnExit()根本不會(huì)執(zhí)行臨時(shí)文件會(huì)殘留。NIO 的createTempFile()只負(fù)責(zé)創(chuàng)建沒有自帶退出清理Path temp Files.createTempFile(null, .tmp);清理需要自己做。如果是邊寫邊用的臨時(shí)文件最簡(jiǎn)單的是用完立刻刪try { Files.write(temp, data); // 使用 temp } finally { Files.deleteIfExists(temp); }如果臨時(shí)文件要跨越多個(gè)方法使用直到 JVM 退出可以注冊(cè)ShutdownHook做兜底。deleteOnExit()本身也是 JVM 內(nèi)部維護(hù)了一個(gè)待刪隊(duì)列所以存在一個(gè)隱藏問(wèn)題如果短時(shí)間創(chuàng)建大量臨時(shí)文件都會(huì)進(jìn)入隊(duì)列等待 JVM 退出時(shí)逐個(gè)清理如果程序崩得早列隊(duì)里的文件就全留下變成垃圾。實(shí)際項(xiàng)目里我傾向于盡快刪除臨時(shí)文件而不是依賴退出鉤子。6. 符號(hào)鏈接與文件監(jiān)聽NIO 獨(dú)有的兩個(gè)高價(jià)值能力6.1 符號(hào)鏈接判斷與讀取目標(biāo)java.io.File完全沒有符號(hào)鏈接的概念遇到符號(hào)鏈接會(huì)直接當(dāng)普通文件處理。NIO 在這塊補(bǔ)齊了關(guān)鍵能力。Path link Paths.get(/usr/bin/java); System.out.println(Files.isSymbolicLink(link)); // true Path target Files.readSymbolicLink(link); System.out.println(target); // 實(shí)際指向的路徑注意readSymbolicLink()讀取的是鏈接自己保存的目標(biāo)路徑不會(huì)遞歸解析最終目標(biāo)。如果你需要不斷解析直到找到真實(shí)文件可以結(jié)合toRealPath()Path realPath link.toRealPath(); // 默認(rèn)跟隨所有符號(hào)鏈接返回最終真實(shí)路徑在包含軟鏈的部署環(huán)境比如/usr/bin/java普遍是軟鏈下判斷 JDK 版本時(shí)用link.toRealPath()能拿到真正安裝的 JDK 路徑比File.getCanonicalPath()穩(wěn)定得多。6.2 WatchService監(jiān)控目錄變化替代無(wú)頭輪詢java.io.File沒有文件監(jiān)聽能力。老代碼想實(shí)現(xiàn)“目錄里多了新文件就處理”一般只能靠輪詢lastModified或者listFiles()比對(duì)前后差異又慢又容易漏。NIO 的WatchService是原生的目錄監(jiān)聽機(jī)制try (WatchService watchService FileSystems.getDefault().newWatchService()) { Path dir Paths.get(/tmp/incoming); dir.register(watchService, StandardWatchEventKinds.ENTRY_CREATE, StandardWatchEventKinds.ENTRY_DELETE, StandardWatchEventKinds.ENTRY_MODIFY); while (true) { WatchKey key watchService.take(); // 阻塞等待事件 for (WatchEvent? event : key.pollEvents()) { Path changed (Path) event.context(); System.out.println(event.kind() : dir.resolve(changed)); } key.reset(); // 重置后繼續(xù)監(jiān)聽 } }這個(gè)機(jī)制的幾個(gè)注意事項(xiàng)很關(guān)鍵WatchService只能監(jiān)聽目錄本身不會(huì)遞歸監(jiān)聽子目錄。想監(jiān)聽整棵目錄樹需要手動(dòng)遍歷子目錄逐個(gè)register并在新目錄創(chuàng)建時(shí)動(dòng)態(tài)注冊(cè)。事件類型里ENTRY_MODIFY可能會(huì)觸發(fā)多次文件寫入過(guò)程中可能產(chǎn)生多次修改事件做業(yè)務(wù)處理時(shí)最好加一個(gè)短延遲去重。平臺(tái)延遲差異明顯Windows 上事件可能稍有延遲Linux 上則依賴 inotify 機(jī)制不同文件系統(tǒng)對(duì)事件粒度的支持也有區(qū)別。但在大多數(shù)場(chǎng)景下用WatchService替代“每 5 秒掃一遍目錄”的輪詢實(shí)現(xiàn)無(wú)論是實(shí)時(shí)性、準(zhǔn)確率還是系統(tǒng)開銷都有質(zhì)的提升。部署配置熱更新、文件導(dǎo)入落地的自動(dòng)觸發(fā)我都是用這個(gè)方案。7. 遷移清單與實(shí)操建議從 File 到 NIO 的平滑過(guò)渡7.1 方法替換映射表老項(xiàng)目改造時(shí)最實(shí)用的就是一張映射表。下面這份是我自己整理過(guò)的覆蓋日常 90% 的文件操作場(chǎng)景java.io.File操作java.nio.file替代new File(path)Paths.get(path)file.exists()Files.exists(path)file.isFile()Files.isRegularFile(path)file.isDirectory()Files.isDirectory(path)file.length()Files.size(path)file.lastModified()Files.getLastModifiedTime(path).toMillis()file.isHidden()Files.isHidden(path)file.mkdir()Files.createDirectory(path)file.mkdirs()Files.createDirectories(path)file.listFiles()Files.list(path)或Files.newDirectoryStream(path)file.renameTo(dest)Files.move(src, dest)file.delete()Files.deleteIfExists(path)file.getAbsolutePath()path.toAbsolutePath().toString()file.getCanonicalPath()path.toRealPath().toString()file.deleteOnExit()手動(dòng)立即清理或ShutdownHookfile.setReadOnly()Files.setPosixFilePermissions()或DosFileAttributeView這里特別強(qiáng)調(diào)一下file.length()到Files.size(path)的差異。File.length()對(duì)不存在的文件返回 0可能被誤讀為“文件存在但內(nèi)容為空”Files.size(path)對(duì)不存在的文件會(huì)拋NoSuchFileException語(yǔ)義更準(zhǔn)確。我見過(guò)不少生產(chǎn) bug 就是“文件不存在時(shí) length 返回 0然后被當(dāng)成空文件處理”。7.2 常見問(wèn)題速查表實(shí)際遷移過(guò)程中問(wèn)得最多的幾個(gè)問(wèn)題我整理成一張表問(wèn)題場(chǎng)景推薦方案關(guān)鍵坑點(diǎn)刪除目錄樹失敗walkFileTree配合SimpleFileVisitor目錄非空時(shí)delete()直接失敗遍歷大目錄內(nèi)存暴漲Files.newDirectoryStream()listFiles()一次性加載全部判斷符號(hào)鏈接Files.isSymbolicLink(path)File.isDirectory()默認(rèn)跟隨鏈接移動(dòng)文件要求原子Files.moveATOMIC_MOVE文件系統(tǒng)不支持時(shí)拋AtomicMoveNotSupportedException目錄不存在時(shí)靜默創(chuàng)建Files.createDirectories(path)mkdirs()失敗返回 false無(wú)異常信息流忘關(guān)導(dǎo)致句柄泄漏try-with-resources包住Stream/DirectoryStreamFiles.list()底層持有DirectoryStream需要監(jiān)控文件變化WatchService不遞歸子目錄需手動(dòng)注冊(cè)復(fù)制文件保留時(shí)間戳Files.copyCOPY_ATTRIBUTES不指定則時(shí)間戳是當(dāng)前時(shí)間7.3 遷移節(jié)奏建議老項(xiàng)目如果代碼量巨大不推薦一次性把所有File全換成Path/Files。我見過(guò)不少同事一上來(lái)就全局替換最后在File.separator、deleteOnExit這些邊緣語(yǔ)義上翻了車。穩(wěn)妥的做法是只改新代碼老代碼按模塊逐步替換。一個(gè)實(shí)用的中間策略是寫一個(gè)薄封裝工具類把高頻操作包一層。比如統(tǒng)一提供deleteQuietly(Path)、moveAtomic(Path, Path)、listFilesStream(Path)這類方法底層用 NIO 實(shí)現(xiàn)然后逐步把老代碼的調(diào)用點(diǎn)遷移到工具類上。這樣既能享受新 API 的能力又不至于一次性改動(dòng)太大。比較難遷移的是這幾類依賴FilenameFilter或FileFilter的老代碼可以改成DirectoryStream.FilterPath依賴file.deleteOnExit()清理臨時(shí)文件的要改成顯式清理依賴file.renameTo()實(shí)現(xiàn)移動(dòng)的務(wù)必改成Files.move()否則在 Windows 上的行為極不穩(wěn)定依賴file.getCanonicalPath()解析軟鏈路徑的改成path.toRealPath()語(yǔ)義更明確。新代碼只要運(yùn)行環(huán)境是 Java 8 以上我可以直接建議默認(rèn)java.nio.file沒有理由再用java.io.File做新的文件操作。唯一需要保留File的場(chǎng)景是調(diào)用第三方庫(kù)的舊接口——有些庫(kù)方法簽名還是File參數(shù)這時(shí)候用path.toFile()轉(zhuǎn)換即可。最后說(shuō)點(diǎn)我自己的體會(huì)。NIO 真正讓人覺得舒服的地方不是某個(gè) API 名字更好看而是它把“路徑”和“對(duì)路徑做什么”拆開了。File之所以難用根本原因是它把狀態(tài)判斷、屬性讀取、修改操作全堆在一個(gè)類里失敗時(shí)只給你一個(gè)boolean false你根本不知道發(fā)生了什么。從File遷到Path/Files不是把 API 名字換掉就完了而是把每一次操作腦子里過(guò)一遍它的語(yǔ)義刪除是不存在就報(bào)錯(cuò)還是不存在就跳過(guò)移動(dòng)失敗后是拋異常終止還是靜默降級(jí)目錄遍歷是需要全部加載還是邊讀邊處理把這些問(wèn)題想清楚了代碼的健壯性自然會(huì)上去這也是我寫這篇對(duì)比最想傳達(dá)的一個(gè)點(diǎn)。