1. 從一臺(tái)剛裝好的 CentOS 7 虛擬機(jī)說(shuō)起為什么大家總在 Java 版本上卡住在 VMware 里裝完 CentOS 7第一件事往往是配網(wǎng)絡(luò)、改 yum 源緊接著第二件事就是裝 Java。這事看起來(lái)簡(jiǎn)單到不值一提但實(shí)際動(dòng)手的人大概率都遇到過(guò)下面幾種情況敲java -version出來(lái)的是 1.8.0_xxx可項(xiàng)目要求 OpenJDK 11javac能跑但JAVA_HOME指向的是 JRE 目錄Maven 一編譯就報(bào)找不到編譯器或者更微妙的java和javac的版本居然不一致。這些問(wèn)題的根源不在 Java 本身而在于 CentOS 7 這個(gè)系統(tǒng)里同時(shí)存在好幾套 Java 裝法它們各自維護(hù)自己的軟鏈接和環(huán)境變量互相覆蓋起來(lái)毫無(wú)提示。OpenJDK 11 是 LTS 版本從 2018 年發(fā)布到現(xiàn)在大量中間件、構(gòu)建工具和微服務(wù)框架都以它為基準(zhǔn)線(xiàn)。CentOS 7 默認(rèn)自帶的是 OpenJDK 8java-1.8.0-openjdk而且很多基礎(chǔ)鏡像或者最小化安裝的虛擬機(jī)干脆一個(gè) Java 都沒(méi)有。所以給 CentOS 7 裝 OpenJDK 11本質(zhì)上是在一個(gè)停留時(shí)間較長(zhǎng)、軟件源偏保守的系統(tǒng)上把一個(gè)相對(duì)較新的運(yùn)行時(shí)環(huán)境穩(wěn)穩(wěn)當(dāng)當(dāng)?shù)芈溥M(jìn)去。裝法其實(shí)就兩條路走 yum 從軟件倉(cāng)庫(kù)裝或者下 tar.gz 二進(jìn)制包手動(dòng)部署。這兩條路沒(méi)有絕對(duì)的高下之分只有場(chǎng)景適配度不同。我在自己的測(cè)試虛擬機(jī)和生產(chǎn)服務(wù)器上都跑過(guò)踩過(guò)的坑分布得也挺均勻。下面把前置檢查、兩種裝法的完整流程、裝完之后的收尾動(dòng)作以及幾類(lèi)典型故障的排查鏈路完整地?cái)傞_(kāi)講一遍。2. 動(dòng)手前的三項(xiàng)前置檢查別讓環(huán)境把你坑了2.1 確認(rèn)系統(tǒng)版本、架構(gòu)和已有的 Java 殘留CentOS 7 的小版本號(hào)直接決定了 yum 里有沒(méi)有 OpenJDK 11 的包。7.7 及之后的版本官方的 updates 倉(cāng)庫(kù)里已經(jīng)帶了java-11-openjdk如果你手里是 7.2、7.4 這種早期版本yum search大概率什么都搜不到。所以第一件事是看版本cat /etc/redhat-release # 輸出示例CentOS Linux release 7.9.2009 (Core) uname -m # x86_64 或者 aarch64這個(gè)決定后面下載哪個(gè)架構(gòu)的包接著查系統(tǒng)里現(xiàn)在有哪些 Javarpm -qa | grep -i jdk rpm -qa | grep -i java which java javac java -version 21 echo $JAVA_HOME這幾條命令看起來(lái)啰嗦但信息密度很高。rpm -qa能查出通過(guò) yum 裝過(guò)的包which能看出java這個(gè)命令當(dāng)前解析到哪個(gè)路徑正常情況應(yīng)該指向/usr/bin/java而/usr/bin/java是個(gè)軟鏈接最終會(huì)指向/etc/alternatives/java再指向真正的 JDK 目錄。這里有個(gè)很多人忽略的細(xì)節(jié)即使rpm -qa什么都沒(méi)查到which java也可能有輸出。原因是有些安裝腳本尤其是第三方一鍵部署包會(huì)自己下載 JDK 解壓到/usr/local或者/opt然后往/etc/profile里塞一段export PATH。這種“野路子”裝的 Java 不會(huì)出現(xiàn)在 rpm 數(shù)據(jù)庫(kù)里但會(huì)導(dǎo)致你后面新裝的版本被 PATH 順序壓住表現(xiàn)就是“明明裝好了java -version還是舊的”。提示如果發(fā)現(xiàn)/etc/profile或/etc/bashrc里已經(jīng)有手寫(xiě)的JAVA_HOME和PATH設(shè)置先記下位置別急著刪等新版本裝完再統(tǒng)一處理避免中途某個(gè)依賴(lài) Java 的服務(wù)起不來(lái)。2.2 網(wǎng)絡(luò)連通性與 yum 源可用性驗(yàn)證走 yum 安裝的前提是軟件源可達(dá)。VMware 里的虛擬機(jī)常見(jiàn)兩種網(wǎng)絡(luò)模式NAT 和橋接。NAT 模式下虛擬機(jī)通過(guò)宿主機(jī)的網(wǎng)絡(luò)出口訪問(wèn)外網(wǎng)一般開(kāi)箱即用如果用的是僅主機(jī)模式Host-Only那就完全沒(méi)有外網(wǎng)這種情況下你只能走 tar.gz 離線(xiàn)包的路子。驗(yàn)證順序建議是這樣ping -c 3 223.5.5.5 # 測(cè)基礎(chǔ)連通性 ping -c 3 mirrors.aliyun.com # 測(cè) DNS 解析 外網(wǎng) yum repolist # 看倉(cāng)庫(kù)列表是否正常拉取yum repolist這一條最關(guān)鍵它不只是測(cè)網(wǎng)絡(luò)還順帶驗(yàn)證了倉(cāng)庫(kù)配置文件的語(yǔ)法。如果報(bào) “Cannot find a valid baseurl for repo”通常不是網(wǎng)絡(luò)問(wèn)題而是 CentOS 7 早已停止常規(guī)維護(hù)默認(rèn)的mirror.centos.org地址在某些環(huán)境下訪問(wèn)不穩(wěn)定需要把源換成國(guó)內(nèi)鏡像。換源的操作很標(biāo)準(zhǔn)核心就是備份原文件、下載新的.repo文件、清理緩存mkdir -p /etc/yum.repos.d/bak mv /etc/yum.repos.d/CentOS-*.repo /etc/yum.repos.d/bak/ # 然后把國(guó)內(nèi)鏡像站提供的 CentOS 7 repo 文件放進(jìn) /etc/yum.repos.d/ yum clean all yum makecache2.3 磁盤(pán)空間與內(nèi)存的最低要求OpenJDK 11 本身占的空間不大解壓后約 300MB 左右加上-devel包和文檔預(yù)留 1GB 綽綽有余。但 JVM 跑起來(lái)之后的內(nèi)存開(kāi)銷(xiāo)才是重點(diǎn)。在 VMware 里給虛擬機(jī)分配內(nèi)存時(shí)如果打算同時(shí)跑 Java 應(yīng)用加數(shù)據(jù)庫(kù)2GB 是起步線(xiàn)4GB 會(huì)比較從容。這個(gè)不是安裝門(mén)檻但會(huì)影響你后面做壓測(cè)或者跑構(gòu)建時(shí)的體驗(yàn)。另外提醒一點(diǎn)/usr/lib/jvm這個(gè)目錄是 CentOS 約定俗成的 Java 安裝位置/tmp和/var也都在根分區(qū)下。如果你在裝系統(tǒng)時(shí)把根分區(qū)劃得很小比如 10GB裝完幾個(gè) JDK 加構(gòu)建工具之后可能會(huì)緊裝之前用df -h掃一眼心里有數(shù)。3. 第一種方式用 yum 從軟件倉(cāng)庫(kù)安裝 OpenJDK 113.1 先搜索包名別憑記憶敲 installjava-11-openjdk這個(gè)包名聽(tīng)起來(lái)理所當(dāng)然但倉(cāng)庫(kù)里實(shí)際拆成了好幾個(gè)子包功能邊界不一樣裝錯(cuò)了會(huì)發(fā)現(xiàn)少東西。先搜yum list available | grep -i openjdk yum search java-11搜出來(lái)的結(jié)果里你至少要認(rèn)識(shí)下面這幾個(gè)包名作用是否需要java-11-openjdk完整 JRE含圖形相關(guān)組件一般需要java-11-openjdk-headless純命令行 JRE無(wú)圖形依賴(lài)服務(wù)器必裝java-11-openjdk-devel開(kāi)發(fā)工具鏈含javac、jar、jcmd等編譯場(chǎng)景必裝java-11-openjdk-jmods用于生成自定義運(yùn)行時(shí)鏡像特殊需求判斷標(biāo)準(zhǔn)很直接只要服務(wù)器上需要編譯 Java 代碼或者要跑 Maven、Gradle 這類(lèi)構(gòu)建工具-devel就必須裝如果只是跑一個(gè)已打包好的jar那-headless就夠了。很多人圖省事直接yum install java-11-openjdk結(jié)果發(fā)現(xiàn)javac不存在回頭再補(bǔ)裝-devel多花一遍時(shí)間。3.2 執(zhí)行安裝并觀察依賴(lài)解析過(guò)程確定包名之后直接裝yum install -y java-11-openjdk java-11-openjdk-devel這一步值得盯著輸出看幾秒重點(diǎn)看兩件事。第一確認(rèn)下載的版本號(hào)比如11.0.20.0.8-1.el7_9后面的el7_9說(shuō)明這是針對(duì) CentOS 7.9 打的包兼容性有保證。第二看依賴(lài)列表里有沒(méi)有java-1.8.0-openjdk被一并拉進(jìn)來(lái)。正常情況下不會(huì)OpenJDK 11 和 8 是并行安裝的不會(huì)互相替換。如果看到 8 被引入說(shuō)明你的倉(cāng)庫(kù)里有些包對(duì) 8 有強(qiáng)依賴(lài)這時(shí)候不要慌兩個(gè)版本共存是完全允許的后面用 alternatives 切換就行。安裝路徑的落實(shí)結(jié)果通常在/usr/lib/jvm/java-11-openjdk-11.0.20.0.8-1.el7_9.x86_64/ # JDK 根目錄 /usr/lib/jvm/jre-11-openjdk-11.0.20.0.8-1.el7_9.x86_64/ # JRE 目錄注意JAVA_HOME必須指向上面那個(gè)帶java-11-openjdk的目錄而不是帶jre-前綴的。這是個(gè)高頻錯(cuò)誤后面第 5 章會(huì)展開(kāi)。3.3 驗(yàn)證安裝結(jié)果與目錄結(jié)構(gòu)裝完先不要急著配環(huán)境變量先用絕對(duì)路徑直接跑一次/usr/lib/jvm/java-11-openjdk-11.0.20.0.8-1.el7_9.x86_64/bin/java -version如果輸出類(lèi)似openjdk version 11.0.20 2023-08-15 LTS OpenJDK Runtime Environment (Red_Hat-11.0.20.0.8-1.el7_9) (build 11.0.208-LTS) OpenJDK 64-Bit Server VM (Red_Hat-11.0.20.0.8-1.el7_9) (build 11.0.208-LTS, mixed mode, sharing)說(shuō)明包本身沒(méi)問(wèn)題。這一步的意義在于把“包安裝成功”和“命令可用”這兩件事拆開(kāi)驗(yàn)證。如果絕對(duì)路徑能跑而java -version不行那問(wèn)題 100% 出在軟鏈接或 PATH 上排查方向立刻收窄。再順手確認(rèn)幾個(gè)關(guān)鍵可執(zhí)行文件都在ls -l /usr/lib/jvm/java-11-openjdk-*/bin/ | grep -E javac|jar|jps|jcmd|jmapjps、jcmd、jmap這幾個(gè)診斷工具在排查線(xiàn)上問(wèn)題時(shí)價(jià)值極高它們都屬于-devel包如果這里缺了回頭補(bǔ)裝即可。提示yum 裝的 OpenJDK 默認(rèn)會(huì)被自動(dòng)注冊(cè)到 alternatives 系統(tǒng)里優(yōu)先級(jí)一般設(shè)為 1100 左右。如果你后面裝了別的版本切換時(shí)要注意優(yōu)先級(jí)數(shù)字?jǐn)?shù)字越大越優(yōu)先。4. 第二種方式用 tar.gz 二進(jìn)制包手動(dòng)部署4.1 什么場(chǎng)景下應(yīng)該放棄 yum 走手動(dòng)部署yum 裝法最大的限制是版本被倉(cāng)庫(kù)鎖死你只能裝倉(cāng)庫(kù)里有的那個(gè)小版本。如果有明確的版本要求比如某個(gè)中間件只認(rèn) 11.0.17而倉(cāng)庫(kù)里只有 11.0.20那就只能手動(dòng)部署。另外兩種典型場(chǎng)景一是系統(tǒng)小版本太老7.4 以下倉(cāng)庫(kù)里壓根沒(méi)有 11二是要裝到特定路徑、或者要在一臺(tái)機(jī)器上塞好幾個(gè)不同小版本的 JDK 做并行測(cè)試。tar.gz 包的來(lái)源建議選正規(guī)構(gòu)建渠道比如 Adoptium原 AdoptOpenJDK的發(fā)布頁(yè)或者 OpenJDK 官方的歸檔頁(yè)面。選擇時(shí)要看清楚三個(gè)維度版本號(hào)、架構(gòu)x64 / aarch64、以及是 JDK 還是 JRE。下載下來(lái)文件名通常長(zhǎng)這樣OpenJDK11U-jdk_x64_linux_hotspot_11.0.20_8.tar.gz4.2 解壓、規(guī)劃目錄與權(quán)限設(shè)置約定俗成的做法是放到/usr/local下自己建一個(gè)語(yǔ)義清晰的目錄名mkdir -p /usr/local/java cd /usr/local/java tar -zxvf /path/to/OpenJDK11U-jdk_x64_linux_hotspot_11.0.20_8.tar.gz # 解壓后目錄名通常很長(zhǎng)改短便于管理 mv jdk-11.0.208 jdk-11 ls -ld /usr/local/java/jdk-11關(guān)于目錄名我個(gè)人的習(xí)慣是保留小版本號(hào)比如jdk-11.0.20而不是籠統(tǒng)的jdk-11。原因是當(dāng)你在同一臺(tái)機(jī)器上升級(jí)到 11.0.21 時(shí)jdk-11這個(gè)名字就失去了區(qū)分度容易搞混。當(dāng)然如果你只裝一個(gè)版本用jdk-11也沒(méi)問(wèn)題后面環(huán)境變量寫(xiě)起來(lái)更省事。兩種命名都行關(guān)鍵是全機(jī)器統(tǒng)一。權(quán)限方面如果只是自己用root擁有即可如果有多用戶(hù)需要執(zhí)行確保bin目錄下的文件有x權(quán)限chmod -R 755 /usr/local/java/jdk-11用tar包的好處是它不帶任何系統(tǒng)集成不碰 rpm 數(shù)據(jù)庫(kù)也不動(dòng) alternatives完全靠環(huán)境變量生效。干凈、可控代價(jià)是所有事情都要自己接。4.3 環(huán)境變量的寫(xiě)法三種位置三種生效范圍環(huán)境變量寫(xiě)在哪里直接決定了它對(duì)誰(shuí)生效、什么時(shí)候生效。這是手動(dòng)部署里最容易出錯(cuò)的一環(huán)。第一種寫(xiě)/etc/profile.d/下新建一個(gè)獨(dú)立腳本這是我推薦的方式cat /etc/profile.d/java11.sh EOF export JAVA_HOME/usr/local/java/jdk-11 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF chmod x /etc/profile.d/java11.sh source /etc/profile.d/java11.sh這么寫(xiě)的好處是模塊化以后要升級(jí) JDK 或者卸載刪掉這一個(gè)文件就干凈了不會(huì)污染/etc/profile這個(gè)系統(tǒng)級(jí)文件。profile.d目錄下的腳本會(huì)在登錄 shell 啟動(dòng)時(shí)被/etc/profile自動(dòng)讀取執(zhí)行順序按文件名字母排序。第二種寫(xiě)/etc/profile末尾。能用但不推薦因?yàn)殡S著時(shí)間推移這個(gè)文件會(huì)被各種安裝腳本追加內(nèi)容最后變成一團(tuán)亂麻排查 PATH 問(wèn)題時(shí)非常痛苦。第三種寫(xiě)~/.bashrc或者~/.bash_profile。只對(duì)當(dāng)前用戶(hù)生效適合多用戶(hù)環(huán)境下給某個(gè)人單獨(dú)指定版本。注意~/.bashrc對(duì)非交互式 shell 的加載行為有細(xì)微差異如果 Java 是被 systemd 服務(wù)或者 cron 任務(wù)調(diào)用的這些場(chǎng)景通常不會(huì)讀.bashrc寫(xiě)了也白寫(xiě)。這種情況下就得在服務(wù)單元文件里顯式聲明Environment或者在腳本里直接寫(xiě)絕對(duì)路徑。PATH 的順序也有講究。$JAVA_HOME/bin:$PATH是把 JDK 目錄放在最前面優(yōu)先級(jí)最高這是對(duì)的。反過(guò)來(lái)寫(xiě)成$PATH:$JAVA_HOME/bin就會(huì)導(dǎo)致系統(tǒng)里原有的java命令先被找到你的新版本形同虛設(shè)。注意CLASSPATH這一行在現(xiàn)代 Java 項(xiàng)目里其實(shí)已經(jīng)不需要了Maven、Gradle 都會(huì)自己管理依賴(lài)路徑。加上它主要是為了兼容一些老腳本的寫(xiě)法寫(xiě)不寫(xiě)都不影響正常運(yùn)行但寫(xiě)錯(cuò)了比如漏了當(dāng)前目錄的.反而可能出問(wèn)題。新手建議先不加等確實(shí)遇到ClassNotFoundException再排查。5. 裝完之后必須做的兩件收尾工作5.1 alternatives 機(jī)制讓 java 和 javac 同步切換CentOS 的 alternatives 系統(tǒng)是一套軟鏈接管理機(jī)制。/usr/bin/java并不是真的 Java 程序而是一個(gè)指向/etc/alternatives/java的鏈接后者再指向?qū)嶋H位置。這樣切換版本時(shí)只需要改中間那一層。手動(dòng)部署的 JDK 不會(huì)自動(dòng)注冊(cè)到這套系統(tǒng)里需要自己加alternatives --install /usr/bin/java java /usr/local/java/jdk-11/bin/java 2000 alternatives --install /usr/bin/javac javac /usr/local/java/jdk-11/bin/javac 2000 alternatives --install /usr/bin/jar jar /usr/local/java/jdk-11/bin/jar 2000末尾的2000是優(yōu)先級(jí)數(shù)值越大越優(yōu)先。給它設(shè)成一個(gè)比較大的值是為了壓過(guò)系統(tǒng)里可能存在的 OpenJDK 8默認(rèn)優(yōu)先級(jí)通常是 1081 左右。注冊(cè)完之后切換alternatives --config java alternatives --config javac會(huì)列出所有已注冊(cè)的候選項(xiàng)輸入編號(hào)回車(chē)即可。這里有個(gè)非常隱蔽的坑alternatives --config java和alternatives --config javac是兩個(gè)完全獨(dú)立的配置項(xiàng)切了前者不會(huì)自動(dòng)帶上后者。如果你只切了java就會(huì)出現(xiàn)java -version顯示 11 而javac -version顯示 1.8 的詭異現(xiàn)象。Maven 編譯時(shí)會(huì)直接報(bào)錯(cuò)退出。所以注冊(cè)和切換時(shí)一定要成對(duì)操作把javac、jar、jarsigner這些都考慮到。5.2 JAVA_HOME 指向 JDK 而非 JRE 這個(gè)細(xì)節(jié)前面提過(guò)一次這里展開(kāi)說(shuō)清楚。一個(gè)完整的 JDK 目錄結(jié)構(gòu)是這樣的/usr/local/java/jdk-11/ ├── bin/ # 包含 java、javac、jps 等 ├── conf/ ├── include/ ├── jmods/ ├── legal/ ├── lib/ └── release # 版本元信息而 JRE 目錄下只有bin且只有java沒(méi)有javac、lib、conf。在 OpenJDK 11 里JDK 和 JRE 的界限已經(jīng)比 8 時(shí)代模糊了很多yum 包里你還能看到獨(dú)立的jre-11-openjdk目錄但如果JAVA_HOME指到了 JRE 目錄會(huì)發(fā)生什么首先mvn compile會(huì)因?yàn)檎也坏骄幾g器失敗這是最直接的癥狀。其次某些依賴(lài)JAVA_HOME定位tools.jar或dt.jar的老工具會(huì)直接啟動(dòng)失敗——雖然 JDK 9 之后這兩個(gè) jar 已經(jīng)不存在了但依然有老腳本在檢查它們。最麻煩的是有些問(wèn)題不會(huì)立刻暴露等到某個(gè)特定功能被調(diào)用時(shí)才報(bào)錯(cuò)排查起來(lái)就要繞一大圈。驗(yàn)證方式很簡(jiǎn)單echo $JAVA_HOME ls $JAVA_HOME/bin/javac第二條命令如果報(bào) “No such file or directory”說(shuō)明JAVA_HOME指錯(cuò)了位置回去改。6. 幾類(lèi)真實(shí)故障的完整排查鏈路6.1 新裝的版本不生效PATH 加載順序排查現(xiàn)象java -version永遠(yuǎn)是 1.8無(wú)論怎么source都不變。排查要按順序來(lái)不能跳步。第一步確認(rèn)JAVA_HOME到底是什么echo $JAVA_HOME echo $PATH第二步看java命令實(shí)際解析到哪type -a java which -a java ls -l $(which java)type -a會(huì)列出所有匹配項(xiàng)按 PATH 順序排列。如果第一個(gè)不是你要的版本說(shuō)明 PATH 里有更靠前的目錄。第三步查 PATH 是誰(shuí)改的。這里用一個(gè)小技巧先重置成默認(rèn)值再逐層加載env -i bash --login -c echo $PATH這會(huì)模擬一次干凈的登錄過(guò)程打印出最終的 PATH。然后對(duì)比一下就能判斷是/etc/profile、/etc/profile.d/*.sh還是~/.bash_profile里塞進(jìn)去的路徑在搗亂。最常見(jiàn)的原因是/etc/profile.d/下有兩個(gè)腳本一個(gè)設(shè) Java 8 一個(gè)設(shè) Java 11字母序在前面的那個(gè)把路徑插到了最前面。解決辦法是把 Java 11 的腳本重命名為字母序更靠前的名字比如00-java11.sh或者直接在舊腳本里刪掉 Java 8 的 PATH 設(shè)置。6.2 多版本共存時(shí)的優(yōu)先級(jí)混亂現(xiàn)象java -version是 11但javac -version是 1.8或者反過(guò)來(lái)。原因前面提過(guò)alternatives 是成對(duì)配置的。診斷命令alternatives --display java alternatives --display javac輸出里會(huì)列出所有候選項(xiàng)、當(dāng)前指向哪個(gè)、優(yōu)先級(jí)是多少?？吹讲灰恢碌那闆r直觀得很。修復(fù)方式就是逐個(gè)alternatives --config統(tǒng)一切過(guò)去。另外補(bǔ)充一個(gè)很少人知道的操作可以用alternatives --set直接指定跳過(guò)交互式菜單alternatives --set java /usr/local/java/jdk-11/bin/java alternatives --set javac /usr/local/java/jdk-11/bin/javac這在寫(xiě)自動(dòng)化腳本時(shí)特別有用因?yàn)椴恍枰巳廨斎刖幪?hào)。如果配置完還是不對(duì)檢查一下/etc/alternatives/下的鏈接有沒(méi)有斷l(xiāng)s -l /etc/alternatives/java /etc/alternatives/javac鏈接指向的目標(biāo)文件如果不存在說(shuō)明你之前裝的那個(gè)版本被刪了但 alternatives 記錄沒(méi)清這時(shí)候得先用alternatives --remove清掉殘留記錄。6.3 服務(wù)啟動(dòng)失敗但命令行正?，F(xiàn)象SSH 進(jìn)去敲java -version一切正常但 systemd 托管的那個(gè) Java 服務(wù)啟動(dòng)就報(bào)找不到命令或者版本不對(duì)。這類(lèi)問(wèn)題的根源在于運(yùn)行環(huán)境不同。交互式登錄會(huì)讀取/etc/profile和profile.d而 systemd 服務(wù)從/usr/lib/systemd/system/加載它的環(huán)境變量來(lái)自DefaultEnvironment和單元文件里的Environment指令兩者完全不重疊。排查方式是直接看服務(wù)的實(shí)際環(huán)境systemctl show 服務(wù)名 -p Environment systemctl cat 服務(wù)名解決辦法有兩種。要么在單元文件的[Service]段落里顯式加上EnvironmentJAVA_HOME/usr/local/java/jdk-11 EnvironmentPATH/usr/local/java/jdk-11/bin:/usr/bin:/bin要么在服務(wù)啟動(dòng)腳本里全部用絕對(duì)路徑調(diào)用 Java最省事也最不容易出錯(cuò)。改完記得systemctl daemon-reload再重啟服務(wù)。注意環(huán)境變量里的 PATH 一定要把/usr/bin和/bin帶上只寫(xiě) Java 目錄會(huì)導(dǎo)致腳本里其他基礎(chǔ)命令全部失效這種錯(cuò)誤在容器環(huán)境里也經(jīng)常出現(xiàn)。7. 關(guān)于選 yum 還是選 tar 包我自己的判斷習(xí)慣開(kāi)了不少臺(tái) CentOS 7 之后我基本形成了一套固定判斷。凡是只需要一個(gè)穩(wěn)定可用的 JDK、不挑小版本、機(jī)器能正常連軟件源我一律走 yum。裝完自動(dòng)注冊(cè) alternativesjavac和java版本天然一致卸載用yum remove干凈利落省心。而只要需求里出現(xiàn)了“必須 11.0.x”“要裝三個(gè)不同小版本做兼容測(cè)試”“這臺(tái)機(jī)器在純內(nèi)網(wǎng)沒(méi)有可用的 yum 源”那就老老實(shí)實(shí)下 tar 包把版本號(hào)和路徑都控制在自己手里。還有個(gè)容易忽略的點(diǎn)無(wú)論走哪條路裝完之后都建議把java -version、javac -version、echo $JAVA_HOME這三條命令的輸出記一筆寫(xiě)在部署文檔或者機(jī)器備注里。半年之后你再回來(lái)看這臺(tái)機(jī)器不用重新猜它到底裝了什么翻一眼記錄就清楚了。我在測(cè)試環(huán)境里吃過(guò)這個(gè)虧一臺(tái)三年前配的機(jī)器/etc/profile.d/下躺著四個(gè) Java 相關(guān)腳本最后靠grep -r JAVA_HOME /etc/才理清關(guān)系那次之后所有涉及多版本共存的機(jī)器我都留一份變更記錄。