簡介jdk-7u80-linux-x64.tar.gz是Oracle官方發(fā)布的Java Development Kit 1.7在Linux x64環(huán)境下的正式版壓縮包面向需要部署Java應(yīng)用或進行Java開發(fā)的中高級開發(fā)者尤其適合對內(nèi)存容量有較高要求的服務(wù)器、大數(shù)據(jù)處理場景。該安裝包共包含2000個文件總大小約126.45MB主要涵蓋714個jar運行庫、230個xml配置、59個so原生庫、48個properties屬性文件以及javac、jstack、jvisualvm、jmc等完整開發(fā)與監(jiān)控工具可支持從編譯調(diào)試到性能調(diào)優(yōu)的全流程操作。目前已有1903人瀏覽學(xué)習(xí)常被仍依賴Java 7的存量項目用作標(biāo)準(zhǔn)運行時環(huán)境。包內(nèi)額外保留時區(qū)數(shù)據(jù)、安全證書庫等系統(tǒng)級資源并明確去除了src源碼包更適合只關(guān)注運行與部署的用戶直接使用。對于需要搭建Java 7運行環(huán)境的團隊或個人這份官方正式版相當(dāng)于自帶一組經(jīng)過校驗的完整組件省去自行收集零散文件的麻煩。1. 接手一臺老服務(wù)器我先找 jdk-7u80-linux-x64.tar.gz某天接手一臺遺留環(huán)境的 x64 Linux 服務(wù)器上面跑著一個六年沒動過的內(nèi)部系統(tǒng)java -version顯示的是 1.7.0_80。旁邊文檔里寫著一句話“此環(huán)境只能使用 JDK 1.7切勿升級?！睘槭裁床荒苌驗槔舷到y(tǒng)里某個核心模塊直接依賴 JDK 7 的 PermGen 行為和-XX:MaxPermSize參數(shù)升級到 8 就會出現(xiàn)內(nèi)存溢出。類似這種不能隨便升級、又要長期維護的生產(chǎn)環(huán)境jdk-7u80-linux-x64.tar.gz幾乎是唯一的正確答案——它是 JDK 1.7 序列里公認的官方最終公開版包含了此系列 x64 Linux 平臺最后的穩(wěn)定更新。本文就從一線落地的角度講清楚它是什么、怎么裝、參數(shù)怎么調(diào)、哪些坑必須躲。2. 為什么選 u80 的 tar.gz版本身份與官方包的“自證”方法2.1 u80 在 JDK 1.7 系列里的真實身份JDK 1.7 從早期的 u01 一路更新到最后的 u80中間修補了無數(shù)漏洞、類庫缺陷和 JIT 編譯器問題。u80 之所以特殊不只是因為它補丁最全而是因為它作為 JDK 7 的收尾版本被公認為這套老 JDK 的最后一次完整公開更新。實際工作中我們說的“JDK 1.7 官方正式版”絕大多數(shù)時候就是指 u80而不是更早的 u21 或 u51。對線上環(huán)境來說“最后更新”意味著在 JDK 7 這個生命周期內(nèi)沒有比它更安全、更穩(wěn)定的選擇了。對開發(fā)環(huán)境來說構(gòu)建產(chǎn)物用-source 1.7 -target 1.7編譯時u80 的 javac 給出的兼容性警告最少因為它知道自己會被用于編譯“給舊 JDK 跑”的代碼。這里有一個重要區(qū)分jdk-7u80-linux-x64.tar.gz是“JDK”不是“JRE”。壓縮包里自帶完整的開發(fā)工具鏈javac、javap、jar、jmap、jstack 等和運行時環(huán)境java。生產(chǎn)環(huán)境如果只需要跑 jar可以只用其中的 jre 目錄但如果還需要診斷線上問題、看堆棧、做線程 dump就離不開 JDK 里的工具。這就是為什么實際部署時幾乎總是直接用完整的jdk-7u80-linux-x64.tar.gz而不是拆分開的 JRE 包。2.2 為什么是 tar.gz而不是 rpm 或 yum 源里的 openjdk在 x64 Linux 上裝 Java常見的有三種形態(tài)官方 tar.gz 包、rpm安裝包、發(fā)行版軟件源里的 openjdk。我?guī)缀踔煌扑] tar.gz理由很直接形態(tài)安裝位置更換版本適合場景tar.gz 解壓包完全自選如 /usr/local解壓即換改 JAVA_HOME 即可多版本并存、無 root 權(quán)限、需要精確控制版本rpm 包系統(tǒng)默認路徑路徑固定需要卸載舊版本再裝新的面安裝場景不需要靈活切換openjdkyum/apt/usr/lib/jvm 等系統(tǒng)目錄隨系統(tǒng)源更新版本不受控只追求“能用”但版本不可控環(huán)境是黑匣子線上環(huán)境最怕的是“發(fā)版節(jié)奏不可控”。openjdk 會跟著系統(tǒng)源自動升級今天是 u80 的行為明天可能悄悄變成另一個版本行為有差異rpm 安裝路徑寫死多版本并行時 JAVA_HOME 指向極其混亂。tar.gz 是三者里唯一能把版本主動權(quán)完全握在自己手里的方案。另一個現(xiàn)實原因給老系統(tǒng)維護時很多服務(wù)器是沒有外網(wǎng)權(quán)限的yum 源根本不可用。把jdk-7u80-linux-x64.tar.gz傳到服務(wù)器上解壓是斷網(wǎng)環(huán)境下最可靠的部署方式。我處理過的幾個遺留項目都是這種形態(tài)。2.3 拿到包之后先驗明正身三步確認“官方正式版”既然是官方正式版就要先確認它確實是官方發(fā)布且未被篡改。這個步驟新手最容易跳過而老手反而每次都會做因為網(wǎng)絡(luò)上同名文件很多有些被二次打包過里面多塞了啟動腳本有些來源不明的包可能被替換了二進制。我一般按下面三步來做# 步驟1比對 SHA256 校驗值官方存檔頁會給出對應(yīng)值 sha256sum jdk-7u80-linux-x64.tar.gz # 步驟2解壓后檢查目錄結(jié)構(gòu)官方包是固定結(jié)構(gòu) tar -tzf jdk-7u80-linux-x64.tar.gz | head -n 20 # 期望輸出以 jdk1.7.0_80/ 開頭且包含 bin/、lib/、jre/ 等標(biāo)準(zhǔn)目錄 # 步驟3解壓后看 release 文件里的版本標(biāo)識 tar -xzf jdk-7u80-linux-x64.tar.gz cat jdk1.7.0_80/release這段命令里的sha256sum是驗證文件完整性的關(guān)鍵前置動作。tar -tzf不實際解壓只列出歸檔內(nèi)的文件列表方便提前確認頂層目錄名。官方 tar.gz 的頂層一定是jdk1.7.0_80一個目錄不會散落文件。release文件內(nèi)容里會標(biāo)記JAVA_VERSION1.7.0_80和具體構(gòu)建信息這是識別“是不是官方版”最直接的證據(jù)。提示從非官方渠道下載后務(wù)必先做 SHA256 比對再部署。很多“精簡版”“優(yōu)化版”JDK 改變了 JVM 默認參數(shù)線上出了問題很難排查反而得不償失。2.4 解壓后目錄結(jié)構(gòu)里哪些東西值得先記住解壓完之后的jdk1.7.0_80/目錄實際使用頻率最高的是下面幾個子路徑bin/java、javac、jar 等可執(zhí)行入口。PATH 環(huán)境變量主要指向這里。jre/獨立的運行時目錄。需要給應(yīng)用單獨提供“最小運行時”時可以把整個 jre 拷走和應(yīng)用一起打成發(fā)布包。lib/JDK 自身的類庫和工具 jar 包。tools.jar和dt.jar在編譯老項目時經(jīng)常被直接引用這一點之后避坑章節(jié)會再提。jre/lib/運行時核心類庫其中rt.jar是整個 Java 運行時的心臟。有一個細節(jié)值得注意jdk1.7.0_80/bin/下有一個javajdk1.7.0_80/jre/bin/下也有一個java兩者實際版本相同。對外只用前者因為它能自動找到同目錄下的 javac 等工具后者是干凈的最小運行時入口適合給 JRE-only 的啟動腳本調(diào)用。3. 把 jdk-7u80-linux-x64.tar.gz 落地到服務(wù)器部署與 JAVA_HOME 配置3.1 標(biāo)準(zhǔn)三步部署解壓、建立穩(wěn)定路徑、配置環(huán)境變量部署的第一要務(wù)是把 JDK 放到一個穩(wěn)定、可預(yù)期的路徑。我的習(xí)慣是統(tǒng)一放到/usr/local/下并用一個不帶版本號的軟鏈接指向當(dāng)前使用的版本這樣后續(xù)升級或切換版本時只需要改軟鏈接所有引用/usr/local/jdk的腳本都不用動。# 1. 解壓到 /usr/local 目錄 sudo tar -xzf jdk-7u80-linux-x64.tar.gz -C /usr/local # 2. 建立不帶版本號的軟鏈接方便統(tǒng)一引用 sudo ln -s /usr/local/jdk1.7.0_80 /usr/local/jdk # 3. 將環(huán)境變量寫入 /etc/profile.d/java.sh比直接改 /etc/profile 更干凈 sudo tee /etc/profile.d/java.sh /dev/null -EOF export JAVA_HOME/usr/local/jdk export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF命令里的-C /usr/local表示把歸檔解壓到指定目錄注意這一步需要寫權(quán)限實際操作時通常加sudo。軟鏈接jdk是關(guān)鍵設(shè)計以后如果要切到其他 JDK 版本unlink /usr/local/jdk再重新ln -s即可所有應(yīng)用層的 JAVA_HOME 引用不需要改動。tee /etc/profile.d/java.sh比直接編輯/etc/profile更合理因為/etc/profile.d/下的腳本對所有用戶登錄時都會自動加載同時不會破壞系統(tǒng)原有的 profile 邏輯。配置完成后重新登錄或者手動執(zhí)行source /etc/profile.d/java.sh讓環(huán)境變量在當(dāng)前 shell 生效。然后驗證# 驗證版本 java -version # 驗證 javac 可用 javac -version # 確認當(dāng)前 java 的可執(zhí)行路徑確實來自我們解壓的目錄 which java # 確認 JAVA_HOME 已生效 echo $JAVA_HOMEjava -version的輸出應(yīng)當(dāng)包含1.7.0_80字樣并且which java應(yīng)該顯示/usr/local/jdk/bin/java。如果which java指向系統(tǒng)自帶的舊版 openjdk說明 PATH 的優(yōu)先級不對需要檢查/etc/profile.d/java.sh是否在系統(tǒng)默認 PATH 之前被加載了。這一步看似簡單卻是后面很多詭異問題的根源——服務(wù)器上明明裝了 u80但java -version顯示的卻是另一個 JDK。3.2 無 root 權(quán)限的場景把 JDK 完整按住用戶目錄不是所有服務(wù)器都有 root 權(quán)限尤其是遺留系統(tǒng)的運維賬號往往只允許普通用戶操作。這種情況下部署邏輯完全不同JDK 直接解壓到用戶家目錄環(huán)境變量寫入用戶自己的.bashrc忽略所有系統(tǒng)級配置。# 1. 解壓到用戶目錄 tar -xzf jdk-7u80-linux-x64.tar.gz -C ~/ # 2. 寫入用戶級環(huán)境變量 cat ~/.bashrc -EOF export JAVA_HOME~/jdk1.7.0_80 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF # 3. 讓配置立即生效 source ~/.bashrc # 4. 驗證 java -version普通用戶場景下~/.bashrc是正確的位置不要嘗試去寫/etc/profile.d/沒有權(quán)限。整個過程不需要sudo但有一個前提JDK 的二進制文件必須有執(zhí)行權(quán)限。官方 tar.gz 解壓后bin/下所有可執(zhí)行文件已經(jīng)帶上了x權(quán)限位這一點一般不用額外處理。如果從某些渠道獲取的包丟失了權(quán)限位執(zhí)行chmod x ~/jdk1.7.0_80/bin/*即可。3.3 多版本并存的目錄規(guī)劃maven/ant 編譯環(huán)境怎么指向它老項目往往面臨“編譯用 1.7跑測試用 1.8”的雙版本需求。做得不好最容易出現(xiàn)的問題就是構(gòu)建工具比如 Maven、Ant找到的 JDK 不是你指定的那一個。我一般會做兩件事用官方提供的alternatives機制把java、javac注冊為可切換的系統(tǒng)命令。在構(gòu)建工具的配置文件里顯式指定 JAVA_HOME不依賴全局環(huán)境變量。alternatives是多數(shù) Linux 發(fā)行版自帶的多版本切換工具適合在 root 權(quán)限下使用sudo alternatives --install /usr/bin/java java /usr/local/jdk1.7.0_80/bin/java 10830 sudo alternatives --install /usr/bin/javac javac /usr/local/jdk1.7.0_80/bin/javac 10830 # 查看當(dāng)前的默認 java sudo alternatives --config java其中的數(shù)字10830是優(yōu)先級。這個數(shù)字不是隨手寫的它來自于 u80 的版本號含義歷史慣例以8開頭的較大值表示“u80”。如果同時注冊了 JDK 1.8 的 java優(yōu)先級可以設(shè)為 1080 之類稍小的值這樣系統(tǒng)默認仍選 7u80需要時再手動切換。這個機制比直接改 PATH 要穩(wěn)妥得多因為它不依賴 shell 的加載順序任何用戶執(zhí)行java時都會經(jīng)由/usr/bin/java統(tǒng)一跳轉(zhuǎn)。構(gòu)建工具的路徑設(shè)置以 Maven 為例在~/.mavenrc或項目的pom.xml里指定export JAVA_HOME/usr/local/jdk1.7.0_80構(gòu)建工具的 JAVA_HOME 優(yōu)先級高于 PATH。這樣即使服務(wù)器排障時不小心改了 PATH構(gòu)建環(huán)境也不會跟錯 JDK。3.4 驗證部署成果用一個最小 Java 程序試運行環(huán)境變量配完不代表 JDK 一定能正常跑。我習(xí)慣用一個最小程序做冒煙測試而不是直接啟動正式應(yīng)用因為正式應(yīng)用如果啟動失敗日志輸出的原因往往混合了業(yè)務(wù)配置問題難以定位是 JDK 環(huán)境問題還是應(yīng)用問題。public class SmokeTest { public static void main(String[] args) { System.out.println(JDK OK, version System.getProperty(java.version)); } }# 編譯 javac SmokeTest.java # 運行 java SmokeTest # 預(yù)期輸出JDK OK, version1.7.0_80這里其實有一個老版本 JDK 最常見的坑用javac編譯時如果當(dāng)前 JDK 是 1.8默認-source和-target就是 1.8生成的行號信息、字節(jié)碼格式在老 JDK 上可能無法識別。因此當(dāng)明確需要產(chǎn)出“在 1.7 上能跑”的 class 文件時編譯命令必須加版本參數(shù)第 5 章詳述。冒煙測試的意義在于第一步先確認“這個 JDK 本身能編譯能運行”再考慮版本兼容性問題。4. 讓 1.7 跑得穩(wěn)的 JVM 參數(shù)從 PermGen 到 GC 的必調(diào)清單4.1 為什么 u80 的參數(shù)基線不同于 JDK 8JDK 1.7 的 JVM 內(nèi)存模型和 JDK 8 有一個根本差異1.7 的類元數(shù)據(jù)存放在獨立的 PermGen 區(qū)域-XX:MaxPermSize控制上限而 JDK 8 用 Metaspace 替代了它。這意味著為 1.7 寫 JVM 參數(shù)時不能直接照搬 1.8 的配置。很多老系統(tǒng)從 7 遷移到 8 時溢出原因就是參數(shù)里還留著-XX:MaxPermSize——它在 JDK 8 里會被忽略內(nèi)存拓撲完全不同。u80 作為 1.7 的最后一個版本PermGen 的默認值仍然保守默認初始大小和最大上限都不大。老的 Web 應(yīng)用只要動態(tài)生成類稍微多一點就很容易把 PermGen 撐爆。所以為 u80 調(diào)參的第一步就是顯式放大 PermGen。4.2 一份可直接照抄的生產(chǎn)級 JVM 參數(shù)模板下面是我為一個模擬項目X內(nèi)部老系統(tǒng)基于 Spring 3 Tomcat 7堆內(nèi)存需求約 2G配置過的完整參數(shù)每一行都有具體考慮JAVA_OPTS-Xms2048m -Xmx2048m \ -XX:PermSize256m -XX:MaxPermSize512m \ -XX:UseConcMarkSweepGC -XX:CMSPermGenSweepingEnabled \ -XX:CMSClassUnloadingEnabled \ -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/java_heap.hprof \ -Xloggc:/data/logs/java_gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps \ -Dsun.rmi.dgc.server.gcInterval3600000 -Dsun.rmi.dgc.client.gcInterval3600000這段參數(shù)可以按 4 個分組理解第一組是堆與 PermGen-Xms2048m -Xmx2048m把初始堆和最大堆設(shè)成一致避免運行時頻繁擴容導(dǎo)致停頓-XX:PermSize256m -XX:MaxPermSize512m是 1.7 的保命參數(shù)確保動態(tài)類加載不會打爆 PermGen。第二組是 GC 選擇-XX:UseConcMarkSweepGC啟用 CMS 垃圾回收器減少老年代回收時的長停頓。-XX:CMSPermGenSweepingEnabled和-XX:CMSClassUnloadingEnabled是 JDK 7 下 CMS 配合 PermGen 清理的關(guān)鍵組合后者允許回收不再使用的類元數(shù)據(jù)應(yīng)用熱部署場景必須有它。第三組是故障現(xiàn)場保留-XX:HeapDumpOnOutOfMemoryError在 OOM 的瞬間自動生成堆轉(zhuǎn)儲文件并指定了輸出路徑。-Xloggc配合-XX:PrintGCDetails -XX:PrintGCDateStamps把 GC 細節(jié)按時間戳記錄到獨立文件。這兩項是事后排查“到底誰撐爆了內(nèi)存”的基礎(chǔ)。第四組是 RMI 相關(guān)sun.rmi.dgc.server.gcInterval把 RMI 內(nèi)部的分布式 GC 周期拉長到 1 小時避免 RMI 頻繁觸發(fā) Full GC。老系統(tǒng)很多內(nèi)部模塊走 RMI 通信這兩個參數(shù)能顯著降低 GC 頻率。4.3 常見參數(shù)的邊界與“為什么不能照抄”對著網(wǎng)上的模板直接抄參數(shù)最容易翻車。比如-XX:UseParallelGC在 JDK 7 里吞吐量確實好但遇到老系統(tǒng)里大量使用System.gc()的場景很多老框架有這個習(xí)慣并行 GC 被顯式觸發(fā)時停頓會很明顯表現(xiàn)在現(xiàn)象上就是“每天固定時間卡頓一下”又比如-Xss線程棧大小默認 1M老系統(tǒng)線程數(shù)一多堆內(nèi)存就被壓縮但盲目調(diào)小到 256k 可能直接引發(fā)StackOverflowError。關(guān)于 GC 有一個實戰(zhàn)結(jié)論老的 Web 應(yīng)用我默認首選 CMS配合-XX:UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction3讓 CMS 在幾次 Full GC 之后主動壓縮老年代避免碎片化。u80 對 CMS 的支持已經(jīng)很成熟是 1.7 上兼顧穩(wěn)定性和停頓的平衡選擇。-XX:UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction3這兩個參數(shù)的含義是每經(jīng)歷 3 次 Full GC 后對老年代做一次內(nèi)存壓縮整理。注意它們放在 §4.2 模板里也能生效單獨拿出來是因為很多資料只講了 CMS 的開啟忘了碎片整理的收尾措施。提示線程數(shù)較多的應(yīng)用可以在參數(shù)里顯式設(shè)-Xss512k但設(shè)置前必須確認應(yīng)用中最深的調(diào)用棧不會踩到 512k 的邊界。拿不準(zhǔn)時用默認值不要為了省內(nèi)存而主動壓線程棧。4.4 調(diào)參后的驗證從 GC 日志讀出的三個信號參數(shù)調(diào)完了不能直接說“好了”。要能從 GC 日志里讀出問題才算真正接住了。# 檢查 PermGen 占用是否接近 MaxPermSize grep Perm /data/logs/java_gc.log | tail -n 20 # 查看老年代 GC 頻率 grep CMS /data/logs/java_gc.log | tail -n 20 # 統(tǒng)計 Full GC 次數(shù) grep Full GC /data/logs/java_gc.log | wc -l三個信號分別對應(yīng)三類問題Perm 空間持續(xù)走高并逼近上限說明類加載泄漏或者 MaxPermSize 不夠CMS 頻繁出現(xiàn)說明老年代空間規(guī)劃不合理通常是堆太小對象過早晉升Full GC 次數(shù)在應(yīng)用無重大發(fā)布時仍明顯增長需要結(jié)合jmap -heap看堆占用趨勢判斷是內(nèi)存泄漏還是并發(fā)峰值導(dǎo)致的自然增長。日志配合jmap、jstack做診斷是 JDK 自帶的工具鏈里最常用的一組。5. 7u80 部署與使用中的常見問題排查5 個高頻坑5.1 證書過期HTTPs 或 RMI 調(diào)用報CertPathValidatorException現(xiàn)象JDK 1.7 的應(yīng)用訪問某個外部 HTTPS 接口時突然拋sun.security.validator.ValidatorException: PKIX path building failed但瀏覽器訪問同樣網(wǎng)址完全正常。有的團隊第一反應(yīng)是網(wǎng)絡(luò)代理問題排查半天無果。原因u80 發(fā)布于 2015 年其自帶的cacerts信任庫中根證書的有效期截止于 2025 年初左右。當(dāng)外部服務(wù)端使用的證書鏈由這些“過期根證書”簽發(fā)時JDK 7 的信任庫就不認了。這不是網(wǎng)絡(luò)問題是信任庫本身的時效問題。注意這是時間相關(guān)的2025 年之后這個問題會大規(guī)模爆發(fā)。解決把新的根證書導(dǎo)入 JDK 的cacerts。實際操作中從權(quán)威渠道獲取新的根證書 PEM 文件后執(zhí)行keytool -import -trustcacerts -alias newroot -file newroot.pem -keystore $JAVA_HOME/jre/lib/security/cacerts默認密碼changeit。更穩(wěn)妥的做法是定期用所在機構(gòu)的標(biāo)準(zhǔn) CA 根證書更新整個cacerts文件。對于內(nèi)部系統(tǒng)來說也可以考慮換用內(nèi)部 CA 簽發(fā)的雙向認證證書繞開公網(wǎng)根證書有效期問題。5.2 TLS 協(xié)議不兼容三方對接時SSLHandshakeException現(xiàn)象JDK 1.7 的客戶端調(diào)用外部服務(wù)時報SSLHandshakeException: Received fatal alert: protocol_version或者反過來外部客戶端連不上 JDK 1.7 服務(wù)的 HTTPS 接口。日志里常見TLSv1、TLSv1.1字樣。原因JDK 7 默認支持的 TLS 協(xié)議最高到 TLSv1.1u80 可以通過參數(shù)啟用 TLSv1.2。而 2020 年以后幾乎所有外部服務(wù)默認關(guān)閉了 TLSv1.0/1.1最低要求 TLSv1.2。老 JDK 作為客戶端時協(xié)商失敗作為服務(wù)端時新客戶端主動放棄連接。解決在 JDK 1.7 的 JVM 啟動參數(shù)里顯式啟用 TLSv1.2-Dhttps.protocolsTLSv1.2。如果服務(wù)端還有其他限制再配合-Djdk.tls.client.protocolsTLSv1.2。這兩個參數(shù)對 u80 有效但對更早的 u20 之前版本不一定有效。若接口調(diào)用仍然失敗需要確認對方是否接受密碼套件必要時在代碼或配置里精簡EnabledCipherSuites。從根本上講這屬于“老 JDK 和新世界互聯(lián)”的典型摩擦能通過參數(shù)解決就盡量不動代碼。5.3 PATH 被“污染”掃描到的是另一個 JDK現(xiàn)象java -version顯示 1.8 或者更早的 1.6但/usr/local/jdk1.7.0_80/bin/java -version明確顯示 1.7.0_80。應(yīng)用啟動腳本怎么改都還是老的。原因常見于系統(tǒng)/etc/profile或個別用戶的~/.bashrc里存在硬編碼的export PATH$JAVA_HOME/bin:$PATH或export JAVA_HOME/usr/lib/jvm/...加載順序上覆蓋了/etc/profile.d/java.sh的效果。有些老機器的/usr/bin/java被 rpm 包安裝的 openjdk 占用了而which java會優(yōu)先命中/usr/bin。解決用type -a java看所有可能路徑再逐個排查/etc/profile、~/.bashrc、~/.profile里是否有硬編碼。修改之后不要只看當(dāng)前 shell 的輸出要su - 應(yīng)用賬號重新登錄后再驗證因為環(huán)境變量只在登錄時加載。5.4 應(yīng)用編譯或啟動時找不到 tools.jar / dt.jar現(xiàn)象老項目構(gòu)建腳本或 IDE 配置里引用了$JAVA_HOME/lib/tools.jar和$JAVA_HOME/lib/dt.jar換成 u80 后報Error: Could not find or load main class或者直接編譯失敗。原因JDK 9 開始取消了tools.jar和dt.jar但很多老項目是從 JDK 1.6/1.7 時代延續(xù)下來的構(gòu)建腳本里寫死了這兩個 jar 的路徑。還有一種情況是某些監(jiān)控 agent 軟件的安裝腳本也會引用tools.jar做 attach 操作。解決只要部署的確實是完整的jdk-7u80-linux-x64.tar.gz這兩個文件就存在$JAVA_HOME/lib/下。報錯通常是環(huán)境變量JAVA_HOME指向了 JRE 而不是 JDK——比如有人圖省事把JAVA_HOME設(shè)成了$JAVA_HOME/jre。把JAVA_HOME指回 JDK 根目錄構(gòu)建腳本自然恢復(fù)正常。注意部署時一定用“JDK 包”不是 JRE 包否則這個坑無解。5.5 中文字符集亂碼與file.encoding默認值現(xiàn)象同一個應(yīng)用在 Windows 的 JDK 7 上運行正常部署到 Linux 的 7u80 后日志和導(dǎo)出文件里的中文全部變成問號。原因Linux 系統(tǒng)的默認字符集如果沒有顯式指定為 UTF-8JDK 7 會依據(jù)系統(tǒng) locale 決定file.encoding。很多服務(wù)器的 locale 是 POSIX 或 C導(dǎo)致默認編碼不是 UTF-8。JDK 7 環(huán)境和 JDK 8 的區(qū)別在于JDK 8 在部分場景下的默認編碼行為也有類似問題但 7 更敏感。解決在啟動腳本中顯式加-Dfile.encodingUTF-8 -Dsun.jnu.encodingUTF-8同時確保操作系統(tǒng) locale 是en_US.UTF-8啟動腳本里加上export LANGen_US.UTF-8。檢查是否生效可以在 Java 代碼里打印System.getProperty(file.encoding)確認。6. 把 u80 的性能底牌吃透最后的三個技巧與收尾6.1 用jmap和jstack抓取應(yīng)用現(xiàn)場部署完 7u80遇到應(yīng)用假死或 CPU 飆升是很常見的事抓現(xiàn)場的能力直接決定排查效率。u80 自帶的jmap和jstack是這兩類問題的最強工具。# 查看堆內(nèi)存使用情況確認 PermGen 是否還在安全水位 jmap -heap pid # 導(dǎo)出堆轉(zhuǎn)儲后續(xù)用 MAT 分析 jmap -dump:live,formatb,file/data/logs/heap_dump.hprof pid # 打印線程?？词欠裼兴梨i或長時間等待 jstack pid /data/logs/thread_dump.txt重點說明jmap -heap的輸出要看三個值Eden Space使用率、Old Generation使用率、PermGeneration使用率。舊年代和 Perm 持續(xù)高位基本可以判定是泄漏或類卸載不了的問題。jmap -dump:live表示在 dump 前先觸發(fā)一次 Full GC只保存存活對象文件會小很多但同時意味著“當(dāng)前堆的快照中已經(jīng)丟失了死對象的信息”。如果懷疑泄漏更建議先做一次普通 dump不加live留底再對比后續(xù)。jstack輸出里出現(xiàn)大量BLOCKED狀態(tài)且等待同一個鎖那才是死鎖的直接證據(jù)。6.2 用jinfo確認運行時 JVM 參數(shù)有沒有真正生效參數(shù)配置完后最怕遇到“寫了沒生效”。jinfo可以查看運行中 JVM 的實際參數(shù)值不需要重啟應(yīng)用是核驗配置的終極手段。# 查看指定進程的 JVM 參數(shù) jinfo -flags pid # 查看某個具體參數(shù) jinfo -flag MaxPermSize pid有一個常見誤會-XX:CMSClassUnloadingEnabled在jinfo -flags里可能不會直接顯示為“開啟”因為 JDK 7 的某些參數(shù)是“由其他參數(shù)間接推導(dǎo)”的。比如顯式開了-XX:UseConcMarkSweepGC后CMSClassUnloadingEnabled的默認值就是 true。所以在核對時要看整體 GC 配置衍生出的行為而非只看單個 flag。如果發(fā)現(xiàn)實際值和預(yù)期不同優(yōu)先檢查啟動腳本有沒有被其他配置文件覆蓋。6.3 什么時候該守 7u80什么時候該考慮升級寫到這里說一句我的真實態(tài)度。u80 是 JDK 7 的絕唱也是老系統(tǒng)不被業(yè)務(wù)方允許做大規(guī)模升級時的務(wù)實之選。但它改變不了一個事實這是十年前的 JDK互聯(lián)網(wǎng)上每一周都有它的新漏洞披露。我接手過的模擬項目X在 2024 年還能正常跑但安全掃描報告永遠是一疊。我的實踐準(zhǔn)則是兩條線如果系統(tǒng)只是內(nèi)部調(diào)用、不出內(nèi)網(wǎng)、不處理高價值數(shù)據(jù)那么守著 7u80、配齊我前面寫的證書和 TLS 參數(shù)完全可以繼續(xù)穩(wěn)定服役。如果系統(tǒng)暴露給外部、或者需要對接新支付/新協(xié)議棧盡早評估遷移到 JDK 8 或 11——u80 可以作為遷移前的基線環(huán)境把兩邊的輸出行為都測清楚再切換而不是在遷移窗口里反復(fù)拉鋸。7u80 對我來說像一個可靠的老同事它不新但它在自己的領(lǐng)域里足夠規(guī)矩。配置上給它明確的 PermGen、給它 CMS、給它留好日志和 dump 通道它能把你的服務(wù)穩(wěn)住很多年。踩過的坑我都記錄在上面了如果你也正在給一臺老服務(wù)器裝這個版本照著前幾章走完再按避坑清單逐個排除這個方向是值得的。希望幫到你。本文還有配套的精品資源點擊獲取