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