簡介這是一份面向 Linux ARM64aarch64平臺的 Eclipse Java IDE 2023-06 正式版壓縮包專為在樹莓派、ARM 服務器和嵌入式設備上進行 Java 開發(fā)的學生與工程師準備解決這些平臺缺少圖形化開發(fā)環(huán)境、安裝配置繁瑣的問題。包內(nèi)共 1709 個文件、約 325.74MB以 566 個 jar 插件包為核心附帶 html 幫助文檔、properties 與 xml 配置文件、so 動態(tài)庫以及啟動腳本等jar 包提供編輯、調(diào)試、構(gòu)建等核心功能properties/xml 負責插件與工作空間配置so 庫保障 GTK 界面在 ARM Linux 下正常運行解壓后運行目錄中的 eclipse 可執(zhí)行文件即可使用。目前已有 95 人學習下載。該版本內(nèi)置 javac、jshell、keytool 等 JDK 工具支持代碼補全、調(diào)試、構(gòu)建管理與版本控制集成免去在 ARM 平臺手動組裝工具鏈的負擔gz 包目錄結(jié)構(gòu)清晰可直接部署到開發(fā)機或用作國產(chǎn)化 ARM 環(huán)境中的 Java 基礎工具包。1. 在 Linux ARM64 上解壓這個 Eclipse Java 包它到底解決什么第一次拿到eclipse-java-2023-06-R-linux-gtk-aarch64.tar.gz這個文件名的人多半和我當時一樣手里有一臺 64 位 ARM 的 Linux 機器要么是云上的 ARM 實例要么是裝了 Linux 的 ARM 開發(fā)板想在本地直接打開一個能寫 Java 的 IDE而不是每次都用 vi 加命令行編譯。這個包解決的就是這個場景Eclipse Java IDE 的 2023 年 6 月正式發(fā)布版圖形界面走 GTK指令集限定 aarch64解壓后還自帶一串 JDK 工具文件。它適合在 ARM 服務器、ARM 開發(fā)板上做 Java 開發(fā)的人也適合需要離線安裝包、不想每次用在線安裝器拉依賴的團隊內(nèi)網(wǎng)環(huán)境。下面我從版本選擇、解壓啟動、工具鏈用途到五個高頻坑把這份資源完整拆開講一遍。2. 版本號、GTK、aarch64 三個后綴決定什么下載前先判斷兼容性拿到壓縮包先別急著解壓文件名里其實已經(jīng)寫清楚了它能在什么機器上跑、不能用什么機器上跑。這三個后綴2023-06-R、gtk、aarch64分別對應發(fā)布基線、圖形工具包、CPU 指令集任何一項不匹配都會導致裝在機器上卻起不來。2.1 2023-06-R 的命名規(guī)則這是發(fā)布基線不是補丁Eclipse 近些年的版本號不再使用代號而是直接用年份-月份加一個字母來標識。2023-06-R 里的 2023-06 表示這是 2023 年 6 月發(fā)布的版本R 是 Release 的縮寫表示正式發(fā)布基線不是 RC 候選版也不是 nightly 快照。正式基線意味著插件市場里的大多數(shù)主流插件都會標明自己測試過的兼容范圍你的 Maven 插件、Spring 工具、檢查工具在裝之前可以先對照版本范圍省去插件裝完 IDE 起不來的麻煩。為什么選 6 月這版而不是 3 月或 9 月我的經(jīng)驗是3 月版本一般是當年第一批功能落地插件兼容性還沒完全跟上9 月和 12 月版本會引入較多的底層調(diào)整對老工程有時會有意想不到的編譯行為變化年中版本通常是在 3 月版基礎上修了一批問題又不會立刻引入大改動對普通團隊來說是最穩(wěn)妥的出發(fā)點。這個包的java、javac、jshell、jcmd等文件都屬于 2023-06-R 這個基線的一部分它們之間的兼容性是有保證的。所以當你決定要升級團隊 IDE 時把這個包當作一個整體替換不要單獨抽里面的某個工具去配舊版 IDE。2.2 GTK 變體與 x86_64 版的差異同一 IDE兩套皮膚Eclipse 在 Linux 上的圖形界面基于 SWT 框架實現(xiàn)。SWT 在不同平臺有不同實現(xiàn)方式Windows 上直接調(diào)用 Win32 接口macOS 上走 Cocoa而 Linux 上主要是調(diào)用 GTK。文件名里的 gtk 指的就是 SWT 在 Linux 下使用 GTK 作為窗口工具包菜單欄、編輯器、對話框這些界面的繪制最終都交給 GTK 庫完成。這個選擇帶來的實際問題很直接系統(tǒng)里必須存在 GTK 的運行時庫。GTK3 的運行時、libatk、libcairo、libpango 這些都需要在系統(tǒng)里找得到否則啟動器可能連窗口都彈不出來。另一個差異是縮放。在高分屏上GTK 版要配合 GDK_SCALE 環(huán)境變量或者 Linux 桌面的縮放設置來調(diào)整字體清晰度。你可以把 x86_64 版和 aarch64 版理解為同一套源碼針對不同 CPU 做了編譯GTK 依賴基本一致唯一要注意的是某些發(fā)行版在 ARM64 軟件源里相關依賴庫的版本可能比 x86_64 源落后一點裝庫的時候留意版本號即可。2.3 aarch64 的兼容邊界不是所有 ARM 都能跑aarch64 是 64 位 ARM 的指令集架構(gòu)商業(yè)上常直接叫 ARM64。這里容易犯的第一個錯是看到ARM就以為樹莓派全系列都能跑其實 32 位 ARMv7 開發(fā)板完全不行必須 64 位處理器才行。第二個容易忽略的是 C 庫差異。這個 Eclipse 的 GTK 變體在主流發(fā)行版上基于 glibc 構(gòu)建如果系統(tǒng)是純 musl 的極簡環(huán)境或者精簡到只有 BusyBox 的嵌入式系統(tǒng)解壓后大概率出現(xiàn)動態(tài)鏈接庫找不到的報錯這種依賴不解決后續(xù)所有操作都進行不下去。判斷是否匹配建議解壓前先跑三個命令一次性確認uname -m cat /etc/os-release ldd --version | head -n 1uname -m輸出必須是 aarch64os-release里能看到當前發(fā)行版的版本信息避免在過老的系統(tǒng)上安裝新庫時出現(xiàn)依賴沖突ldd --version第一行如果能看到 glibc 字樣說明 C 庫兼容性沒問題。三個條件都滿足再繼續(xù)后面遇到的坑會少掉一大半。下表是我每次拿到新包之后做判斷時用的對照檢查項期望結(jié)果不匹配的表現(xiàn)指令集aarch64不能是 armv7l直接報 Exec format errorC 庫glibc不能是 musl啟動時缺 .so 文件顯示環(huán)境有 X11 或可用 XWayland啟動器無反應或崩潰內(nèi)存建議 2G 以上頻繁卡死或 JVM 啟動失敗3. 解壓、配環(huán)境、啟動 IDE三步把壓縮包變成可用工具這一章從零開始把包從磁盤上變成一個能打開寫代碼的 IDE。每一步我都會給出命令、參數(shù)含義以及失敗時最先懷疑什么。照做的時候建議每執(zhí)行完一步就回頭看輸出不要一次性跑完所有命令再去找問題。3.1 解壓前先跑三個檢查命令很多人拿到壓縮包第一件事就是解壓但我建議先做 30 秒的檢查。把上一章的三個命令在目標機器上執(zhí)行一遍確認架構(gòu)是 aarch64、系統(tǒng)是常見發(fā)行版、glibc 在位。尤其在 ARM 開發(fā)板上系統(tǒng)鏡像經(jīng)常被人精簡過缺庫是常態(tài)。提前發(fā)現(xiàn)問題好過解壓完再對著黑匣子猜。我自己的習慣是這樣的uname -a cat /etc/os-release ldd --version | head -n 1 readelf -h /bin/sh | grep Class\|Machineuname -a能看到內(nèi)核版本和架構(gòu)信息os-release是判斷發(fā)行版類型的主要依據(jù)ldd --version用來看 glibc 版本號太舊的版本裝新版 GTK 庫會報依賴版本不滿足readelf是額外保險確認系統(tǒng)根文件系統(tǒng)確實是 aarch64 而不是模擬器里的 armhf 兼容層。這一步不是浪費時間它決定了后面所有操作的前提條件。3.2 解壓到目標目錄并注意權限確認環(huán)境沒問題后開始解壓。這個壓縮包解開后是一個標準的 Eclipse 程序目錄最上層通常是eclipse文件夾里面有可執(zhí)行文件、eclipse.ini配置、plugins目錄和一堆 JDK 工具命令。我的習慣是把這類大型工具放到/opt/tools下避免之后 PATH 和權限管理混亂sudo mkdir -p /opt/tools sudo tar -xzf eclipse-java-2023-06-R-linux-gtk-aarch64.tar.gz -C /opt/tools/ cd /opt/tools/eclipse ls -ltar命令的參數(shù)含義-x代表解壓-z表示通過 gzip 解壓-f指定文件名-C指定目標目錄。這里特別注意如果用管道方式解壓比如cat xxx.tar.gz | tar -x權限位可能因為 umask 設置不對而丟失后續(xù)執(zhí)行eclipse會提示 Permission denied。解壓完成后用ls -l確認eclipse文件有可執(zhí)行權限沒有就補一句chmod x eclipse。3.3 配置 JAVA_HOME 和 PATH這個包的文件清單里有java、javac、jshell、jcmd等完整 JDK 工具說明它自帶了一套 Java 工具鏈不需要再額外安裝 JDK 就能啟動 IDE。接下來的操作是把這套工具鏈暴露給命令行使用export JAVA_HOME/opt/tools/eclipse export PATH$JAVA_HOME/bin:$PATH java -version javac -versionJAVA_HOME指向解壓出來的 eclipse 目錄PATH在前面加上$JAVA_HOME/bin這樣終端里敲java、javac時系統(tǒng)會優(yōu)先使用包內(nèi)自帶的版本。設置完執(zhí)行java -version和javac -version檢查版本輸出是否一致。如果輸出不對說明 PATH 里還有別的 JDK 在搶位置這個坑我會在第四章專門講。需要注意的是環(huán)境變量只對當前終端窗口生效。關掉終端再開環(huán)境變量會丟失所以如果不想每次啟動都重新敲一遍建議把這兩行寫進 shell 的配置文件或者干脆在 IDE 啟動腳本里統(tǒng)一設置后面第六章會給出完整做法。3.4 首次啟動工作區(qū)、內(nèi)存參數(shù)、GTK 變量首次啟動建議用命令行方式運行這樣報錯信息能直接看到而不是在桌面上雙擊圖標然后對著光標轉(zhuǎn)圈干等GDK_SCALE1 /opt/tools/eclipse/eclipse -data ~/eclipse-workspace GDK_SCALE1表示讓 GTK 應用按系統(tǒng)原始分辨率渲染如果你的屏幕是高分屏默認不縮放時界面文字會偏小但首次啟動先用 1等確認能正常打開再改也不遲。-data參數(shù)指定工作區(qū)目錄用了這個參數(shù)啟動時不會再彈Select a workspace對話框。命令末尾的是把 IDE 放到后臺運行終端窗口還能繼續(xù)執(zhí)行其他命令。啟動過程如果報錯最常見的是缺 GTK 運行庫提示形如libgtk-3.so.0: cannot open shared object file。這時不要動包內(nèi)文件去系統(tǒng)里把 GTK3 運行時補上具體做法我在避坑章節(jié)會展開。第一次打開需要一點時間因為 Eclipse 要為工作區(qū)生成元數(shù)據(jù)看到歡迎頁出現(xiàn)說明解壓出來的這套工具鏈已經(jīng)能正常運行了。4. 包里那串 jshell、jcmd、jstat、jpackageIDE 之外的完整工具鏈很多人下載 Eclipse 只是把它當 IDE 用忽略了文件清單里那串 JDK 工具。其實這個包的價值除了編輯器之外還包含一條從編碼、編譯、簽名到打包診斷的完整工具鏈。掌握這些工具的用法遇到問題時能直接看到 JVM 內(nèi)部發(fā)生了什么而不是把 Eclipse 當成一個無法窺探的黑匣子。4.1 這九個文件名不是湊數(shù)的解壓出來就是一個 JDK 工具集文件清單里的java、keytool、javac、jarsigner、javadoc、jshell、jcmd、jstat、jpackage、jdeps對應的是整個 Java 工具鏈的骨架。這意味著這份資源不只是 IDE它是一個自帶運行時與工具的完整開發(fā)環(huán)境。在實際部署時我通常把包內(nèi)自帶的這套 JDK 作為團隊統(tǒng)一基線團隊里所有人用同一套 javac 編譯避免出現(xiàn)本地編得過、流水線編不過這類經(jīng)典問題。逐個說說這些工具的定位java是運行時的入口keytool用來管理密鑰庫和證書jarsigner對 jar 文件做簽名驗證javadoc從源碼生成 API 文檔jshell是一個交互式 REPL可以不用建工程直接執(zhí)行 Java 語句jcmd是 JVM 診斷命令能查看運行參數(shù)和堆信息jstat監(jiān)控 GC 和類加載jpackage把編譯好的 Java 應用打包成平臺安裝包jdeps分析 jar 的依賴關系。它們在 IDE 之外都有獨立用途是排查問題時的后手。4.2 jshell 和 jcmd日常工作里最值得先用的兩個當你想快速確認這套 JDK 能不能執(zhí)行代碼時jshell是比javac更直接的驗證方式。它不用建目錄、不用寫完整類直接敲表達式就能看到結(jié)果/opt/tools/eclipse/bin/jshell jshell int a 3; jshell System.out.println(a * 4);我一般用jshell驗證三件事JDK 是否正常、基礎語法在當前版本下是否可用、以及某個標準庫 API 的行為。它和編輯器的區(qū)別在于每行語句輸入后立即執(zhí)行不用等整個文件編譯。遇到 HTTP 接口不定期返回奇怪數(shù)據(jù)時我還會在 jshell 里手寫一段調(diào)用代碼觀察數(shù)據(jù)是否符合預期比反復改代碼、編譯、打包要快得多。jcmd則是診斷IDE 為什么越來越卡這類問題的突破口。Eclipse 卡死時界面可能完全無法點擊但 JVM 進程還在此時jcmd仍能連上去拿信息jcmd -l jcmd pid VM.infojcmd -l列出當前機器上所有 JVM 進程及主類名從中找到 Eclipse 的進程號VM.info顯示 JVM 的運行模式、編譯器線程數(shù)等基本信息。如果想看啟動參數(shù)用VM.flags。這套命令的價值在于它完全不走圖形界面直接在命令行跟 JVM 通信。Eclipse 的 UI 卡死時你依然能拿到堆棧和參數(shù)定位到真相。4.3 jstat、jdeps、jpackage從性能觀察到交付的完整閉環(huán)jstat是監(jiān)控 JVM 統(tǒng)計信息的命令最常用的場景是觀察 GC 行為。命令格式是jstat -gc pid 采樣間隔毫秒 采樣次數(shù)jstat -gc 12345 1000 10上面命令的含義是對 12345 號進程每 1000 毫秒采樣一次 GC 數(shù)據(jù)連續(xù)采樣 10 次。輸出里的 YGC 和 YGCT 表示 Young GC 次數(shù)和累計消耗時間如果 FGC 次數(shù)持續(xù)增長且最終占到總時間很大比重說明堆內(nèi)存配置或代碼里有明顯的對象分配壓力。你可以在 Eclipse 運行卡頓時跑這么一組看是不是 GC 頻繁導致的暫停。這在改代碼之前先定性方向不會錯。jdeps是依賴分析工具專門用來排查本地編譯沒問題部署到服務器后報 ClassNotFound這類問題jdeps --multi-release 17 --ignore-missing-deps target/app.jar--multi-release指定按 Java 17 的版本規(guī)則處理多版本 jar--ignore-missing-deps讓它在遇到找不到的依賴時不直接報錯退出。輸出會列出每個類依賴的 JDK 內(nèi)部包以及第三方 jar。重點看輸出里有沒有 JDK 內(nèi)部 API這類內(nèi)部依賴在低版本運行時上最容易翻車。jpackage則是把整個 Java 應用交付成安裝包的命令。在 aarch64 的 Linux 上它可以輸出 deb 或 rpm 格式產(chǎn)物可以直接分發(fā)到同架構(gòu)機器上。基本用法jpackage --input dist --main-jar app.jar --main-class com.demo.Main --name demo --type deb--input指向包含所有運行資源的目錄--main-jar是主程序 jar--main-class指定入口類--type是包格式。jpackage會把應用和運行時一起打包目標機器不需要預裝 JDK。在 ARM 開發(fā)板場景里我用這種方式分發(fā)內(nèi)部工具比讓每臺機器手動裝 JDK 可靠得多。4.4 PATH 順序與 IDE 內(nèi)部 JDK 的選擇一個順序引發(fā)的錯亂一個最常見的排查場景是Eclipse 里項目運行正常命令行里敲mvn package卻失敗錯誤信息指向編譯級別不對。原因大多不是代碼問題而是 PATH 里先找到的java命令來自另一個 JDK。命令行里執(zhí)行which java就能看出實際生效的是哪個路徑。解決辦法是讓 IDE 和命令行各自顯式綁定 JDK。對于 Eclipse在eclipse.ini里加上兩行-vm /opt/tools/eclipse/bin/java注意-vm和路徑必須各占一行而且必須放在-vmargs之前否則 Eclipse 會忽略這個設置。這樣配置之后IDE 啟動時用的 Java 就是包內(nèi)自帶的那一套不依賴于用戶的 PATH 環(huán)境。命令行那邊則繼續(xù)用JAVA_HOME和PATH控制。兩套機制各管各的互不干擾。5. 避坑手冊aarch64 Linux 上跑 Eclipse 的五個典型現(xiàn)場這一章記錄的是我在 ARM64 Linux 上跑 Eclipse 實際遇到過的踩坑記錄按現(xiàn)象 → 原因 → 解決的順序?qū)憽Ｃ恳粭l都來自真實復現(xiàn)不是理論推演。如果你照著前面章節(jié)執(zhí)行到某一步卡住優(yōu)先看這里。5.1 啟動器雙擊無反應現(xiàn)象文件管理器里雙擊 eclipse 圖標鼠標轉(zhuǎn)圈幾秒窗口始終沒有出現(xiàn)命令行里也不報任何提示。原因啟動器找不到 GTK 運行庫最常見是系統(tǒng)缺少libgtk-3.so.0。桌面環(huán)境可能自帶 GTK 組件但版本不完整導致 SWT 初始化失敗而 GUI 方式啟動時錯誤信息被吞掉了。解決先回到命令行執(zhí)行/opt/tools/eclipse/eclipse把報錯信息抓出來。如果是libgtk-3.so.0: cannot open shared object file在 Debian 系發(fā)行版上安裝 GTK3 運行時庫命令是sudo apt install libgtk-3-0安裝完再跑ldd /opt/tools/eclipse/eclipse | grep not found確認沒有輸出即表示依賴補齊。從那以后我再也不會用雙擊方式做首次啟動驗證命令行先跑一遍已經(jīng)是固定動作。5.2 高分屏下字體發(fā)虛或界面比例失調(diào)現(xiàn)象啟動成功后界面文字邊緣模糊菜單和編輯器圖標比例不協(xié)調(diào)整體看起來像沒適配屏幕分辨率。原因GTK 應用在高分屏下默認不開啟縮放字體和控件按低分辨率計算顯示器像素密度一高就發(fā)虛。解決啟動前設置兩個環(huán)境變量再開 IDEexport GDK_SCALE2 export GDK_DPI_SCALE1GDK_SCALE2讓 GTK 界面整體放大兩倍GDK_DPI_SCALE1保持字體邏輯大小不變。這里面的關系是GDK_SCALE控制界面元素縮放GDK_DPI_SCALE控制字體渲染密度兩個配合不好會出現(xiàn)界面放大了但字體糊成一團的效果。設置完重新啟動如果沒有變化檢查桌面環(huán)境的縮放設置是不是同時也在作用雙重慶祝會疊加出更大的比例。5.3 Wayland 會話下窗口崩潰或白屏現(xiàn)象在 Wayland 桌面環(huán)境里啟動正常但一打開編輯器的某個視圖或者彈右鍵菜單Eclipse 直接崩潰退出在 X11 會話下完全沒有這個問題。原因SWT 在部分 Wayland 合成器下對彈出層和窗口重繪支持不完整屬于底層框架兼容性問題不是這個包本身損壞。解決在啟動腳本里強制 GTK 走 X11 后端export GDK_BACKENDx11 /opt/tools/eclipse/eclipse GDK_BACKENDx11告訴 GTK 使用 X11 協(xié)議而不是 Wayland通過 XWayland 兼容層把界面渲染出去。如果系統(tǒng)沒有安裝 XWayland則考慮直接切換到 X11 會話登錄桌面。出現(xiàn)這種情況時不要反復調(diào)整 eclipse.ini 里的參數(shù)優(yōu)先考慮后端切換這是成本最低且最有效的一招。5.4 彈窗提示 Failed to create the Java Virtual Machine現(xiàn)象點擊啟動后彈出一個對話框標題是 Failed to create the Java Virtual MachineIDE 直接退出。原因兩種情況最常見。一種是 PATH 里根本沒有可用的java命令Eclipse 找不到虛擬機另一種是eclipse.ini中的-Xmx參數(shù)設得超過物理內(nèi)存JVM 分配失敗。解決先在終端執(zhí)行which java如果沒有任何輸出說明沒把 JDK 工具鏈加入 PATH返回第三章 3.3 小節(jié)重新配置環(huán)境變量。如果java -version能正常輸出那就打開eclipse.ini把-Xmx值先降到1g試一次能啟動說明是內(nèi)存參數(shù)問題再根據(jù)機器實際內(nèi)存逐步調(diào)大。這里每次只改一個參數(shù)改完重啟再確認不要一次性把-Xms、-Xmx、-XX:MaxMetaspaceSize都改掉出問題了不知道是哪個改壞的。5.5 解壓后文件執(zhí)行權限丟失、符號鏈接損壞現(xiàn)象tar 解壓完成進入目錄后運行./eclipse提示Permission denied部分插件的動態(tài)庫加載也報錯。原因解壓時用了管道方式或非 GNU tar 的精簡版本沒有完整保留歸檔中的執(zhí)行權限位和符號鏈接信息。權限位丟失后可執(zhí)行文件無法運行符號鏈接指向的目標不對動態(tài)庫就加載失敗。解決重新用標準命令解壓不要用 zip 工具處理 tar.gz 文件。解壓后執(zhí)行一次權限修復chmod x /opt/tools/eclipse/eclipse find /opt/tools/eclipse/bin -type f -exec chmod x {} \;第一條給主啟動器加執(zhí)行權限第二條把bin目錄下所有普通文件統(tǒng)一加上執(zhí)行權限。做完后用ls -l抽查幾個文件確認權限位正常。如果你發(fā)現(xiàn)解壓期間有中斷或磁盤已滿的報錯最穩(wěn)妥的做法是刪掉重解不要在半損壞狀態(tài)下續(xù)解。6. 從命令行驗證安裝并固化啟動參數(shù)把 Eclipse 當命令行工具用經(jīng)過前面五章的操作Eclipse 已經(jīng)能正常運行了。但每次從終端啟動都要敲一長串參數(shù)還不能保證環(huán)境變量每次都一致這里我習慣的做法是把啟動流程固化成一個腳本同時加入驗證步驟讓裝好沒裝好這件事變得可判斷。下面這個腳本是我的標準模板#!/usr/bin/env bash export JAVA_HOME/opt/tools/eclipse export PATH$JAVA_HOME/bin:$PATH export GDK_BACKENDx11 export GDK_SCALE1 /opt/tools/eclipse/eclipse \ -vm $JAVA_HOME/bin/java \ -data $HOME/eclipse-workspace \ -Xloggc:$HOME/eclipse-gc.log 腳本里的JAVA_HOME和PATH保證命令行和 IDE 內(nèi)部用的是同一套 JDKGDK_BACKENDx11規(guī)避 Wayland 下的崩潰問題-vm顯式指定虛擬機路徑不受環(huán)境變量污染影響-data固定工作區(qū)-Xloggc把 GC 日志寫到固定文件方便以后排查卡頓。執(zhí)行這個腳本后如何確認這套環(huán)境沒問題我每次都會在啟動完成后跑一段驗證命令javac -version jshell System.out.println(ok); jcmd -ljavac -version驗證編譯器可執(zhí)行jshell通過標準輸入執(zhí)行一行語句并輸出驗證運行時和類加載正常jcmd -l列出 JVM 進程確認 IDE 已經(jīng)在 JVM 層注冊。這三條命令全部通過說明從壓縮包解壓出來的工具鏈已經(jīng)是可以依賴的開發(fā)環(huán)境了。如果還想加一個簡單性能基線可以在日常開發(fā)半小時后跑一次jstat -gc pid 1000 5留意 FGC 的次數(shù)變化。IDE 卡頓和項目編譯變慢很大比例都能從這里找到原因。從那以后我每次拿到新的 Eclipse 包不管是什么架構(gòu)什么版本都強制走一遍uname -m、ldd --version、javac -version、jshell四步驗證流程再開始寫業(yè)務代碼。這套流程幫我省掉了很多莫名其妙的深夜排查希望也能幫到你。本文還有配套的精品資源點擊獲取