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