Java 報錯分析提示詞（異常堆棧定位、OutOfMemoryError 分類排查、線程 dump 看死鎖與線程池打滿）
Java 服務報了一長串異常堆棧看不懂、出現 OutOfMemoryError、接口全部卡住疑似死鎖或線程池耗盡時用：把堆棧、GC 日誌或線程 dump 貼給 AI，它找出真正的根因所在行、判斷 OOM 屬於哪一類，並告訴你下一步該抓什麼數據、怎麼修。
通用大模型 對話模型通用
你是一名排查過大量 Java 線上問題的工程師，熟悉 JVM 內存結構、GC 和線程模型。請幫我分析下面的問題。 - 問題類型：[問題類型]（可選：異常堆棧/內存溢出/接口卡死） - JDK 版本與框架：[JDK 與框架]（例：JDK 17 + Spring Boot 3） - JVM 啟動參數：[JVM 參數]（例：-Xmx2g，沒有就寫不知道） - 部署環境：[部署環境]（例：容器內存限制 3G） - 現象與發生時間：[現象] - 材料（異常堆棧、GC 日誌片段、線程 dump，原樣粘貼）： [粘貼材料] - 相關代碼（如果已經定位到某個類）： [相關代碼] 分析方法： 1. 異常堆棧： - 找到最底層的 Caused by，這通常才是根因； - 跳過框架內部的調用幀，找出第一個屬於我們自己代碼的幀，指出具體的類、方法和行號； - 解釋異常的直接原因（比如空指針是哪個變量為空），以及可能的上游原因。 2. 內存溢出：先根據錯誤訊息判斷類型——堆內存不足、元空間不足、無法創建新的本地線程、直接內存不足、GC 開銷超限、容器限制導致進程被系統終止（這種情況 JVM 可能來不及打印錯誤）——不同類型的排查方向完全不同。然後說明需要的數據（堆轉儲、GC 日誌）、啟動參數應該怎麼加，以及分析堆轉儲時看什麼。 3. 線程 dump：統計線程狀態分佈；找出大量線程阻塞在同一處的位置（例如都在等待數據庫連接池、都在等同一把鎖）；檢測死鎖（dump 中會明確標出）；判斷是線程池滿了還是下游變慢。 4. 給出結論：最可能的根因（按可能性排序）、驗證方法、修復方案、短期止血辦法。 材料不足以下結論時，告訴我還需要哪些數據、用什麼命令獲取。
高亮處換成你自己的內容：[問題類型]、[JDK 與框架]、[JVM 參數]、[部署環境]、[現象]、[粘貼材料]、[相關代碼]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[粘貼材料] 不要只截取最上面幾行。異常堆棧要包含所有 Caused by 段；線程 dump 最好完整貼上，或者至少包括所有業務線程。[部署環境] 中的容器內存限制很重要，堆設定得太接近容器限制時，進程會被直接終止，日誌裏看不到 OOM。
常見坑：
- 只看堆棧最上面一行，那往往是框架包裝後拋出的異常，真正的原因在最下面的 Caused by。
- 一遇到 OOM 就調大堆內存，如果是內存泄漏，只是推遲了崩潰時間；如果是「無法創建本地線程」，調大堆反而更糟。
- 線上卡住時只重啟不留證據。重啟前先抓一次線程 dump（間隔幾秒抓兩到三次），之後才有機會找到原因。
追問技巧：拿到堆轉儲的分析結果（如佔用最多的對象、支配樹）後貼回去，問「這些對象被誰持有，對應哪段代碼」。
示例輸出
示例，僅供參考（線程 dump，接口全部超時）
線程狀態：200 個 Tomcat 工作線程中，186 個處於 TIMED_WAITING，堆棧均停在：
at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:...)
at ...OrderRepository.findByUser(OrderRepository.java:42)判斷：線程池滿的直接原因是數據庫連接池耗盡（連接池大小為 10，所有線程都在等連接），而不是死鎖（dump 中沒有死鎖提示）。
可能的根因（按可能性）：
- 有慢查詢長時間佔用連接——查看同時段數據庫的慢查詢日誌；
- 連接泄漏——代碼中手動獲取連接後未在異常路徑關閉，開啟連接池的泄漏檢測驗證；
- 下游流量突增——對比請求量監控。
止血：臨時擴容實例分攤流量；定位到慢查詢後先加索引或限流該接口。不建議直接把連接池調得很大，會把壓力轉移給數據庫。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～