1. 先搞清楚為什么現(xiàn)在還有人要裝 JDK8打開任何一個后端招聘帖或者是老項目的部署文檔你會發(fā)現(xiàn)一個很奇怪的現(xiàn)象2024 年了新項目都在討論 JDK17、JDK21可偏偏有一大批系統(tǒng)還在 Windows 上用著 JDK8。這不是誰偷懶而是現(xiàn)實決定的。JDK8 是 Java 歷史上生命周期最長的一個版本2014 年發(fā)布到 2030 年前后都還有商業(yè)支持版本在跑大量企業(yè)內(nèi)部的中間件、老框架、定制化組件都建立在 JDK8 的語言特性和運行機制之上。你把它換成高版本輕則啟動報錯重則字節(jié)碼不兼容、反射被模塊系統(tǒng)攔住排查成本高得離譜。所以我寫這篇東西不是教你點下一步就完事而是把這件看起來簡單的事講透。Windows 安裝 JDK8這件事表面是下載一個安裝包、配兩個環(huán)境變量真正容易翻車的點在于選哪個發(fā)行版、裝 32 位還是 64 位、JAVA_HOME 和 Path 到底誰管誰、機器上已經(jīng)有別的 JDK 怎么辦、命令行顯示版本不對怎么查。這些問題在搜索引擎上答案零散而且互相矛盾很多人配了半小時環(huán)境變量最后卡在java -version打印出另一個版本上。這篇文章適合三類人看第一類是完全沒接觸過 Java 環(huán)境配置的新手想一次裝對不折騰第二類是手上維護著老項目、需要在同一臺 Windows 機器上讓 JDK8 和 JDK17 和平共處的開發(fā)者第三類是幫同事、幫客戶遠程裝環(huán)境的技術(shù)支持人員需要一套能復(fù)現(xiàn)、能抄作業(yè)的標準流程。全文基于 Windows 10 和 Windows 11 的實測Windows Server 2016 及以上同樣適用涉及命令的地方我都會給出可直接粘貼的內(nèi)容。在動手之前我建議你先在心里回答一個問題這臺機器上的 JDK8是唯一版本還是多個版本之一答案不同后面的配置策略完全不一樣。很多教程只講單版本裝法等你后面要裝第二個 JDK 時環(huán)境變量一團亂只能重裝系統(tǒng)級別的折騰。所以下面的內(nèi)容我會兩套都講并且告訴你為什么。1.1 JDK8 到底老在哪又強在哪先說清楚概念避免新手把 JDK 和 JRE 混為一談。JRE 是運行環(huán)境只有java命令能跑 class 文件但不能編譯JDK 是開發(fā)工具包包含 JRE 外加javac、jar、javadoc、jps、jstack這些工具。你要做開發(fā)必須裝 JDK如果只是運行別人打包好的程序裝 JRE 理論上夠用但實際工作中我建議一律裝 JDK因為排查問題時jps、jstack、jmap這些工具是你唯一的救命稻草缺了它們線上問題只能靠猜。JDK8 相對 JDK7 最大的變化是引入了 Lambda 表達式和 Stream API讓 Java 第一次有了像樣的函數(shù)式寫法。還有接口默認方法、方法引用、Optional 類、全新的日期時間 APIjava.time以及把永久代 PermGen 換成了元空間 Metaspace。這最后一條尤其重要以前 JDK7 跑久了報java.lang.OutOfMemoryError: PermGen space是無數(shù)人的噩夢JDK8 之后這個錯誤基本消失了取而代之的是元空間溢出排查思路完全不同。如果你在維護老系統(tǒng)看到 PermGen 相關(guān)的報錯那說明機器上跑的其實不是 JDK8或者是 JDK8 但參數(shù)里還留著-XX:MaxPermSize這種情況下 JVM 會直接警告參數(shù)無效。還有個細節(jié)很多人不知道JDK8 的file.encoding在 Windows 上默認跟隨系統(tǒng)區(qū)域設(shè)置中文環(huán)境就是 GBK。而 JDK9 之后默認改成了 UTF-8。這就導(dǎo)致同一個項目在 JDK8 上讀文件正常換到 JDK11 上中文全亂碼。反過來也一樣。所以當你在 Windows 上裝 JDK8 時編碼問題一定要提前意識到不要等程序跑出亂碼才回頭找原因。1.2 哪些場景非 JDK8 不可我列幾個實際遇到過的場景你對照看看自己是不是其中之一。第一公司內(nèi)部的 ERP、OA、財務(wù)系統(tǒng)用的是十年前的框架比如 Struts2 加 Spring 3這些框架在高版本 JDK 上會直接拋異常。第二某些國產(chǎn)中間件、老版本的 Tomcat 7 或者 WebLogic官方支持的 JDK 上限就寫死在 8。第三大數(shù)據(jù)生態(tài)里Hadoop、Hive、Spark 的早期版本對 JDK8 依賴很深雖然新版本已經(jīng)支持 11 和 17但存量集群升級成本極高。第四教學和考試環(huán)境很多高校的 Java 課程、軟考、認證考試仍然以 JDK8 為基準。第五也是最現(xiàn)實的一條你接手了一個沒人敢動的項目能跑就行別的事以后再說。這種時候正確的做法不是順便升級一下而是老老實實把 JDK8 裝好先讓系統(tǒng)穩(wěn)定運行升級的事單獨排期評估。我見過太多人抱著順手升一升的心態(tài)把一個本來只是環(huán)境缺失的問題變成了兩周的兼容性改造。注意如果這臺機器是生產(chǎn)服務(wù)器裝 JDK8 之前一定要確認應(yīng)用當前的 JDK 版本和啟動參數(shù)別想當然認為肯定是 8。用java -version和jps -lvm確認清楚再動手。2. 下載前的三個決定發(fā)行版、位數(shù)、安裝包類型很多人一上來就搜jdk8下載點進第一個結(jié)果下載、裝完然后發(fā)現(xiàn)裝的是 JRE或者裝完是 32 位版本內(nèi)存上限被卡在 1.5G 左右跑什么都慢。這三個決定必須在下載之前想清楚否則后面全是返工。2.1 選哪個發(fā)行版別只盯著一個來源JDK8 的發(fā)行版有好幾個來源各有各的適用場景。我整理成表格你按自己的情況對號入座。發(fā)行版典型包名適合場景需要注意的點Oracle JDK 8jdk-8uXXX-windows-x64.exe傳統(tǒng)企業(yè)項目、老框架后期更新版本在授權(quán)條款上有變化商用前要確認合規(guī)Eclipse Temurin 8OpenJDK8U-jdk_x64_windows_hotspot_8uXXX.zip通用開發(fā)、開源項目只提供壓縮包需要手動配環(huán)境變量Amazon Corretto 8amazon-corretto-8-x64-windows-jdk.msi長期免費支持、服務(wù)器安裝器行為與 Oracle 略有差異Azul Zulu 8zulu8.XX.X-ca-jdk8.0.XXX-win_x64.msi需要長期穩(wěn)定更新的場景版本號命名規(guī)則不同國內(nèi)廠商發(fā)行版各家自有命名國內(nèi)網(wǎng)絡(luò)環(huán)境、企業(yè)采購需確認與目標項目的兼容性選哪個我的經(jīng)驗是**開發(fā)機優(yōu)先選帶 exe/msi 安裝器的版本省心服務(wù)器和需要頻繁切換版本的機器優(yōu)先選 zip 壓縮包版本可控。**壓縮包版本不寫注冊表、不碰系統(tǒng)目錄解壓即用刪掉就是卸載干凈這對需要多版本共存的機器來說是最優(yōu)解。至于從哪下載原則很簡單認準發(fā)行方的官方站點或者其官方代碼托管倉庫的發(fā)布頁。第三方下載站的安裝包我強烈不建議用一是版本可能是被改過的二是很多下載站會捆綁東西三是你無法驗證文件完整性。這一點在給客戶裝環(huán)境時尤其重要出問題你沒法解釋。2.2 32 位還是 64 位這個問題比你想象的嚴重2024 年了還有人裝 32 位 JDK通常是因為看了一篇年代久遠的教程。判斷方法很簡單在 Windows 上打開設(shè)置 - 系統(tǒng) - 關(guān)于看系統(tǒng)類型這一行寫的是基于 x64 的處理器就裝 64 位寫的是基于 x86或者32 位操作系統(tǒng)才裝 32 位。現(xiàn)在還在跑 32 位 Windows 的機器基本都是十幾年前的老設(shè)備或者某些工控機。為什么強調(diào)這個因為 32 位 JVM 的堆內(nèi)存上限受地址空間限制實際上你能給的最大堆通常在 1.5G 到 2G 之間再大就啟動不了。而 64 位 JVM 只要物理內(nèi)存夠幾十 G 的堆都能給。如果你在一個 16G 內(nèi)存的機器上誤裝了 32 位 JDK然后按教程配了-Xmx4g結(jié)果就是 JVM 直接起不來報Could not reserve enough space for object heap新手很容易以為是內(nèi)存不夠其實是位數(shù)錯了。確認當前已裝 JDK 位數(shù)的方法命令行執(zhí)行java -version如果輸出里有64-Bit Server VM就是 64 位只寫Client VM沒有 64-Bit 字樣那多半是 32 位。這是最快的判斷方式。2.3 校驗文件完整性一個被忽略的好習慣從官網(wǎng)下載的文件如果網(wǎng)絡(luò)不穩(wěn)定有可能下載不完整裝到一半報錯或者裝完了運行異常。養(yǎng)成校驗的習慣能省很多時間。發(fā)行方一般會提供 SHA256 校驗值Windows 上用 PowerShell 一條命令就能算出本地文件的哈希Get-FileHash -Algorithm SHA256 C:\Users\你的用戶名\Downloads\jdk-8uXXX-windows-x64.exe把輸出的哈希值和官網(wǎng)公布的值比對一致就放心裝。不一致就重新下載。這一步大概花 10 秒但能擋掉一類莫名其妙的安裝失敗。提示如果官網(wǎng)只給了 MD5用Get-FileHash -Algorithm MD5也行。哈希值不區(qū)分大小寫比對時不用糾結(jié)字母大小寫。3. 安裝實操從雙擊安裝包到環(huán)境變量配好進入正題。下面按安裝器版本這一條主線講因為它涉及步驟最多坑也最集中講完再補壓縮包版本的做法。3.1 圖形化安裝每一步都在做什么雙擊安裝包第一個界面是歡迎頁直接下一步。第二個界面是安裝路徑默認是C:\Program Files\Java\jdk1.8.0_XXX后面還有一步問你 JRE 裝哪里默認是C:\Program Files\Java\jre1.8.0_XXX。路徑要不要改我的建議分兩種情況。如果你這輩子只打算在這臺機器上裝這一個 JDK默認路徑完全沒問題別折騰。如果你確定以后會有多個 JDK 版本共存那從一開始就把安裝目錄規(guī)劃好比如統(tǒng)一放在C:\Java\下面每個版本一個子目錄C:\Java\jdk1.8.0_202 C:\Java\jdk-17.0.9 C:\Java\jdk-21.0.1這樣做的好處是所有 JDK 在同一層級切換版本時只需要改一個環(huán)境變量值不用去翻Program Files里那一堆名字相似的目錄。而且路徑里沒有空格寫腳本的時候不用處理引號轉(zhuǎn)義少一類奇怪的問題。安裝過程中的兩個小坑第一安裝器會順便裝一個 JRE并且往系統(tǒng) Path 里塞一個C:\ProgramData\Oracle\Java\javapath的條目。這個目錄里放的是java.exe、javaw.exe、javac.exe的轉(zhuǎn)發(fā)程序它總是指向最后安裝的那個 JRE。這就是很多人裝完 JDK8 又裝了 JDK17 之后java -version顯示的不是自己想要的那個版本的根源。記住這個條目后面排查要用。第二安裝路徑里絕對不要出現(xiàn)中文和空格之外的怪字符尤其不要放在桌面或者中文命名的文件夾下。JVM 在解析類路徑時對非 ASCII 字符的處理在 JDK8 上并不完美有些場景會出問題沒必要給自己找麻煩。安裝完成后安裝器會提示成功。但此時打開命令行執(zhí)行java -version可能會成功javac -version卻提示找不到命令因為安裝器配了 Path 但沒配 JAVA_HOME而且不同版本安裝器的行為不一致。所以下一步的環(huán)境變量配置必須自己動手。3.2 JAVA_HOME、Path、CLASSPATH三個變量的分工這三個變量的關(guān)系用一個比喻就明白了。JAVA_HOME 是JDK 住在哪Path 是系統(tǒng)去哪兒找可執(zhí)行文件CLASSPATH 是java 命令去哪兒找要加載的類。很多人配錯是因為把 JAVA_HOME 和 Path 的職責搞混了。先說 JAVA_HOME。它的值是 JDK 的安裝根目錄不帶\bin變量名JAVA_HOME 變量值C:\Java\jdk1.8.0_202為什么要設(shè)這個變量因為大量第三方工具依賴它Maven、Gradle、Tomcat 的啟動腳本、各種 IDE 的項目配置都會去讀 JAVA_HOME 來決定用哪個 JDK。你如果不設(shè)這些工具要么報錯要么用系統(tǒng)里第一個找到的 java結(jié)果不可控。再說 Path。Path 里要加的是 JDK 的 bin 目錄。這里有一個關(guān)鍵選擇**寫絕對路徑C:\Java\jdk1.8.0_202\bin還是寫%JAVA_HOME%\bin**我強烈建議后者。原因是切換 JDK 版本時你只需要改 JAVA_HOME 一個變量的值Path 不用動。如果你寫的絕對路徑以后每換一次版本就得改一次 Path改漏了就會出現(xiàn)JAVA_HOME 是 17java -version 顯示 8這種詭異現(xiàn)象。Path 中新增%JAVA_HOME%\bin操作路徑右鍵此電腦→ 屬性 → 高級系統(tǒng)設(shè)置 → 環(huán)境變量。注意要區(qū)分用戶變量和系統(tǒng)變量。對于個人開發(fā)機配在用戶變量里就夠了改動即時生效且不需要管理員權(quán)限如果是多人共用的服務(wù)器配在系統(tǒng)變量里這樣所有賬戶都能用。切換版本的靈活性上用戶變量更占優(yōu)勢因為你可以給不同用戶配不同版本。最后說 CLASSPATH。**我的建議是不要設(shè)或者只設(shè)一個點號.。**網(wǎng)上大量老教程讓你設(shè).;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar這在 JDK8 上完全沒必要因為這兩個 jar 里放的是老式的 Java 類庫現(xiàn)代 JDK 的類加載機制已經(jīng)不需要顯式指定。而如果你設(shè)錯了 CLASSPATH比如丟了開頭的點號會導(dǎo)致java HelloWorld找不到當前目錄的類報Could not find or load main class新手排查這個錯誤能耗掉一下午。不設(shè) CLASSPATH 時JVM 默認就是當前目錄最省事。注意如果機器上已有 CLASSPATH 變量且里面還有別的內(nèi)容不要在原有內(nèi)容上亂加先備份一份值再改。刪掉別人配的東西可能導(dǎo)致其他軟件出問題。3.3 驗證四條命令確認裝對了環(huán)境變量改完必須重新打開一個新的命令行窗口因為已經(jīng)打開的窗口繼承的是舊的環(huán)境變量改了也不會生效。這是新手最常犯的錯誤改完發(fā)現(xiàn)沒用以為是配置錯了其實是窗口沒重開。新開一個 cmd 或 PowerShell依次執(zhí)行java -version javac -version echo %JAVA_HOME% where java逐條解釋結(jié)果應(yīng)該是什么樣。java -version正常輸出類似java version 1.8.0_202 Java(TM) SE Runtime Environment (build 1.8.0_202-b08) Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)注意這里顯示的版本號是1.8.0_XXX而不是8.0.XXX這是 JDK 的歷史遺留命名兩者是同一個東西不要以為自己裝錯了。第二行如果出現(xiàn)64-Bit說明位數(shù)正確。javac -version應(yīng)該輸出javac 1.8.0_202。如果這條報不是內(nèi)部或外部命令說明 Path 沒配好或者配的是 JRE 的路徑而不是 JDK 的路徑。JDK 的 bin 目錄里一定有javac.exe去目錄里看一眼就能確認。echo %JAVA_HOME%應(yīng)該原樣打印你設(shè)的路徑。如果打印出%JAVA_HOME%本身說明變量沒設(shè)成功檢查是不是把變量設(shè)到了另一個作用域用戶變量和系統(tǒng)變量設(shè)混了。where java會列出系統(tǒng)里所有能找到的 java.exe按 Path 順序排列。**這條命令是排查版本沖突的利器。**正常情況下應(yīng)該優(yōu)先列出你配的C:\Java\jdk1.8.0_202\bin\java.exe。如果第一行是C:\ProgramData\Oracle\Java\javapath\java.exe或者C:\Windows\System32\java.exe那就是被搶了需要把 Path 里%JAVA_HOME%\bin的條目上移到這些條目之前。3.4 壓縮包版本的做法解壓即用如果你下載的是 zip 包很多發(fā)行版只提供這種流程更簡單但要更細心。解壓到一個沒有空格和中文的目錄比如C:\Java\jdk8u202注意解壓后的目錄結(jié)構(gòu)很多壓縮包解壓出來會多一層目錄比如jdk8u202-b08\jdk8u202-b08\bin這種情況下 JAVA_HOME 要指向真正含 bin 的那一層。然后配環(huán)境變量的步驟和上面完全一樣。區(qū)別在于壓縮包版本不在系統(tǒng)里注冊任何東西也不會有 javapath 這類干擾項所以where java通常非常干凈只有你自己配的那一個。對需要精細控制版本的場景來說這是優(yōu)點。卸載也很簡單把環(huán)境變量里的相關(guān)條目刪掉然后把目錄刪掉就完事了不留垃圾。相比之下安裝器版本卸載后可能殘留注冊表和 javapath 目錄還得手動清理。提示解壓類 JDK 建議在目錄名里保留完整的版本號比如jdk8u202、jdk8u392這樣以后裝了多個 8 的小版本時一眼能分清哪個是哪個不用去翻 release 文件。4. 多版本共存讓 JDK8 和 JDK17 不打架這部分是很多人真正需要的。一臺機器上同時有 JDK8 和 JDK17怎么做到想用哪個用哪個而不是改一次環(huán)境變量重啟一次。4.1 不要直接改 Path改用切換策略最笨的辦法是用 JDK8 時把 Path 改成 8 的 bin用 JDK17 時改成 17 的 bin每次改完重啟命令行。能用但費勁而且容易忘。更好的做法是分層第一層把每個 JDK 的版本變量單獨定義好互不干擾JAVA8_HOME C:\Java\jdk1.8.0_202 JAVA17_HOME C:\Java\jdk-17.0.9 JAVA21_HOME C:\Java\jdk-21.0.1第二層定義一個總的 JAVA_HOME它的值引用上面某一個JAVA_HOME %JAVA8_HOME%第三層Path 里只寫%JAVA_HOME%\bin。這樣切換版本時你只需要把 JAVA_HOME 的值從%JAVA8_HOME%改成%JAVA17_HOME%全局就是一致的。改完之后新開窗口驗證即可。這種做法的好處是所有依賴 JAVA_HOME 的工具Maven、Gradle、IDE、Tomcat 腳本都會自動跟著切不會出現(xiàn)命令行是 8IDE 里是 17這種分裂狀態(tài)。我見過太多項目因為 IDE 和命令行用了不同 JDK編譯出來的 class 版本對不上報Unsupported major.minor version 52.0或者61.0這類錯誤只要版本統(tǒng)一就不會出現(xiàn)。4.2 用腳本做單次會話級切換上面改的是系統(tǒng)級變量影響所有新開的窗口。如果你只是臨時想用另一個版本跑一下不想改全局配置可以在腳本里做會話級覆蓋。寫一個 bat 文件雙擊就直接進入使用 JDK8 的命令行echo off set JAVA_HOMEC:\Java\jdk1.8.0_202 set PATH%JAVA_HOME%\bin;%PATH% echo JAVA_HOME set to %JAVA_HOME% java -version cmd /k這段腳本的邏輯很直白把 JAVA_HOME 臨時設(shè)置成 JDK8 的路徑然后把它的 bin 目錄拼到當前 Path 的最前面這樣本次會話里java命令優(yōu)先找到的就是 JDK8。最后一句cmd /k保持窗口不關(guān)閉方便你繼續(xù)在里面敲命令。把這段保存成use-jdk8.bat放在桌面或者放一個專門的工具目錄里同理再做一份use-jdk17.bat。需要哪個版本就雙擊哪個互不影響也不污染系統(tǒng)環(huán)境。這個技巧我在處理跨版本兼容性驗證時用得特別多比如要確認這個 API 在 JDK8 上能不能編譯通過直接開一個 JDK8 會話編譯一遍再開一個 JDK17 會話編譯一遍兩分鐘就能得出結(jié)論。PowerShell 用戶可以用這段來做永久設(shè)置需要管理員權(quán)限[Environment]::SetEnvironmentVariable(JAVA_HOME, C:\Java\jdk1.8.0_202, Machine)第三個參數(shù) Machine 表示系統(tǒng)變量換成 User 就是用戶變量。設(shè)置完同樣要新開窗口才生效。4.3 驗證多版本切換是否成功切換之后不要只看java -version就完事把這三條都跑一遍命令期望結(jié)果說明echo %JAVA_HOME%指向當前目標版本目錄確認變量本身生效where java第一行是目標版本的 bin 下的 java.exe確認沒有被其他路徑搶占javac -version與 java 版本一致確認編譯器也是目標版本不是殘留的舊版特別強調(diào)第三行。我遇到過一種情況java 命令已經(jīng)是 JDK17 了但 javac 還是 JDK8 的原因是某次操作在 Path 里額外加了一個絕對的 bin 路徑導(dǎo)致兩個版本混在一起。這種狀態(tài)下編譯出來的 class 是 52.0用 JDK17 的 java 運行會直接報版本不支持的錯。所以每次切換后三條一起驗養(yǎng)成習慣。還有一個隱蔽的干擾源C:\Windows\System32\java.exe。某些軟件會在安裝時往這里放一個 java.exe。系統(tǒng)目錄在 Path 里的優(yōu)先級通常很高所以偶爾會出現(xiàn)明明配了 JAVA_HOMEwhere java第一行卻是 System32 的情況。解決辦法是把%JAVA_HOME%\bin移到 Path 列表的最上方或者干脆把系統(tǒng)目錄里那個 java.exe 重命名備份前提是確認沒有別的軟件依賴它。5. 常見問題與排查技巧實錄下面這些是我在實際操作中反復(fù)遇到過的按癥狀—原因—處理的結(jié)構(gòu)整理你可以當速查表用。5.1 命令行提示不是內(nèi)部或外部命令這是最高頻的問題。先按順序排除四個可能。第一命令行窗口沒有重新打開用的是改環(huán)境變量之前的老窗口。第二Path 里寫的是絕對路徑但路徑本身寫錯了比如把jdk1.8.0_202寫成了jdk1.8.0_20。第三配置的是用戶變量但當前命令行是以另一個用戶身份運行的比如管理員權(quán)限的窗口對應(yīng)的是管理員賬戶的環(huán)境變量。第四裝的其實是 JREbin 目錄里根本沒有 javac.exe。排查順序建議先去文件資源管理器里打開你配的路徑確認java.exe和javac.exe都在。在的話再看環(huán)境變量里 Path 的條目是否完整。都不行就重開窗口再試。這三步能解決 95% 的此類問題。5.2 java 版本和預(yù)期的對不上where java輸出多行第一行不是你配的那個就是被搶了。常見的搶占者有C:\ProgramData\Oracle\Java\javapath\Oracle 安裝器寫的、C:\Windows\System32\、其他軟件自帶的 JRE 目錄。處理方法是打開環(huán)境變量里 Path 的編輯界面從上往下看找到%JAVA_HOME%\bin這一條把它上移到所有其他 java 相關(guān)條目的前面。Windows 的 Path 是按順序查找的誰在前面用誰。如果 Path 太長看不到全貌可以點編輯文本按鈕切換到文本模式看清楚順序再調(diào)整。注意Path 編輯界面的編輯文本模式下每一行是一個路徑不要給路徑加引號也不要留空行。加引號會導(dǎo)致整個路徑失效這是個非常隱蔽的坑。5.3 中文亂碼怎么處理JDK8 在 Windows 上默認編碼跟隨系統(tǒng)區(qū)域中文系統(tǒng)就是 GBK。如果你的程序讀寫的文件是 UTF-8 編碼就會亂碼。臨時解決辦法是在命令行先執(zhí)行chcp 65001把代碼頁切成 UTF-8再運行程序。但這個只對當前窗口有效而且某些老程序在 65001 代碼頁下會輸出異常。更穩(wěn)妥的做法是啟動時顯式指定編碼java -Dfile.encodingUTF-8 -jar your-app.jar如果希望永久生效可以設(shè)一個環(huán)境變量JAVA_TOOL_OPTIONS值為-Dfile.encodingUTF-8。這個變量的好處是 JVM 啟動時會自動讀取不用每次改命令。缺點是它會在啟動時打印一行Picked up JAVA_TOOL_OPTIONS提示看著有點煩但不影響使用。還有一個相關(guān)參數(shù)是-Dsun.jnu.encodingUTF-8它控制的是文件名的編碼。這兩個參數(shù)一起用時能覆蓋絕大多數(shù)中文亂碼場景。不過要注意JDK8 上改編碼不如 JDK9 之后干凈某些場景依然會跟隨系統(tǒng)所以最根本的辦法還是統(tǒng)一下項目里的文件編碼和運行環(huán)境編碼。5.4 安裝包雙擊沒反應(yīng)或中途失敗這種現(xiàn)象在 Windows 11 上比以前多?？赡艿脑蛴袔讉€。一是安裝包被安全軟件攔截了去安全軟件的攔截記錄里找找看或者臨時關(guān)閉實時防護再裝。二是臨時目錄權(quán)限問題安裝器需要往%TEMP%寫文件如果那個目錄權(quán)限異常就會卡住可以用管理員身份運行安裝包試試。三是下載的文件不完整回到第 2.3 節(jié)的哈希校驗步驟驗證一下。四是系統(tǒng)里的某個殘留服務(wù)占用了文件重啟后重裝通常能解決。另外還有一種情況安裝到一半報錯誤 1723或類似的 MSI 錯誤多半是 Windows Installer 服務(wù)狀態(tài)異常。這種時候重啟電腦再裝或者用msiexec /unregister和msiexec /regserver重新注冊一下服務(wù)成功率很高。5.5 裝完了但程序起不來幾個方向如果java -version一切正常但你的 jar 或者 Tomcat 起不來問題通常不在 JDK 安裝本身而在下面幾個方向。檢查啟動腳本里有沒有硬編碼的 JAVA_HOME 路徑指向一個不存在的目錄這在遷移或者拷貝項目時極其常見。檢查有沒有-Xmx之類的內(nèi)存參數(shù)超過了物理內(nèi)存減去系統(tǒng)占用后的可用值。檢查端口是否被占用Web 應(yīng)用常見的 8080、8005 沖突會直接導(dǎo)致啟動失敗。還有一個容易被忽略的點JDK8 的 Metaspace 默認沒有上限如果某個應(yīng)用瘋狂生成動態(tài)類比如大量使用反射、字節(jié)碼增強的框架會出現(xiàn)元空間持續(xù)增長直到耗盡機器內(nèi)存的情況。這類問題的表現(xiàn)是程序運行一段時間后響應(yīng)變慢、機器內(nèi)存吃緊日志里不一定有明顯報錯。處理方式是加參數(shù)限制-XX:MaxMetaspaceSize256m然后觀察是否穩(wěn)定。提示排查 JVM 層面的問題jps -lvm能列出當前機器上所有 Java 進程及其啟動參數(shù)jstack pid能打印線程棧jmap -heap pid能看堆內(nèi)存分布。這三個命令都在 JDK 的 bin 目錄里前提是你裝的是 JDK 而不是 JRE。6. 裝完之后值得馬上做的幾件事環(huán)境裝好只是起點下面這幾件事做了能讓你后面少走很多彎路。第一件寫一個最小的 Hello World 跑通全流程。不要覺得多余這能一次性驗證 javac 和 java 兩個命令、編碼、類路徑三個環(huán)節(jié)。新建一個HelloJDK8.java內(nèi)容如下public class HelloJDK8 { public static void main(String[] args) { System.out.println(JDK version: System.getProperty(java.version)); System.out.println(Java home: System.getProperty(java.home)); } }在文件所在目錄執(zhí)行javac HelloJDK8.java java HelloJDK8java.home輸出的路徑會告訴你當前實際用的是哪個 JDK 的運行環(huán)境。這個信息在多版本環(huán)境下特別有用比java -version更準確因為它打印的是 JVM 自己認定的主目錄。第二件把常用的構(gòu)建工具一并配好。如果項目用 Maven注意 Maven 自己也會讀 JAVA_HOME所以只要 JDK 切對了Maven 通常不用額外配置。但如果你需要針對某個項目固定 JDK 版本可以在maven-compiler-plugin里顯式聲明 source 和 target 都為 1.8這樣即使有人用 JDK17 跑構(gòu)建編譯出來的也是 8 的目標版本。當然這只解決編譯層面運行時還是得用 8。第三件給環(huán)境留一份記錄。在C:\Java\下面放一個README.txt寫清楚每個目錄對應(yīng)哪個版本、什么時候裝的、用在哪個項目上。這個習慣聽起來有點多余但當你半年后接手一個沒人維護的機器看到這份記錄會非常慶幸。我自己維護的幾臺構(gòu)建機上都放了這個文件同事接手時能省掉大量摸索時間。第四件考慮把 JAVA_HOME 和 Path 的配置導(dǎo)出備份。用setx命令可以或者直接截圖存一份。Windows 的環(huán)境變量界面看起來能看全但實際上長 Path 會被折疊出問題時不容易發(fā)現(xiàn)。導(dǎo)出一份文本備份出問題能快速對照。最后再說個實際體會。JDK8 在 Windows 上的安裝本身并不復(fù)雜復(fù)雜的是它經(jīng)常出現(xiàn)在一個已經(jīng)有其他 JDK 的機器上而大部分教程默認你是從零開始的。所以我在任何一臺新機器上裝 JDK 之前都會先花兩分鐘執(zhí)行where java、java -version、echo %JAVA_HOME%三條命令摸清現(xiàn)狀再動手。這個兩分鐘的投入比事后排查版本沖突省下的時間多得多。另外如果你是要給一臺長期運行的服務(wù)器裝環(huán)境盡量選壓縮包版本放在統(tǒng)一的目錄下別用安裝器因為安裝器版本在多用戶、多版本場景下帶來的隱性耦合太多卸載時還可能留下 javapath 那種干擾項后續(xù)維護的人會罵人。這些都是踩過坑之后才明白的寫下來給后面的人省點事。