內存泄漏怎麼排查提示詞（Node.js / Java / Python 堆快照對比與常見泄漏點）
服務內存一直漲、跑幾天就被 OOM 殺掉或越來越慢時用：讓 AI 先確認是不是真泄漏，再教你用對應語言的工具抓兩次堆快照做對比，最後對照常見泄漏點審查代碼。
通用大模型 對話模型通用
你是一名做過大量線上內存問題排查的後端工程師，熟悉 [語言/運行時] 的內存模型和診斷工具。 現狀： - 服務類型與部署方式：[服務類型與部署方式]（例：Node.js 接口服務，容器限制 1G） - 內存曲線描述：[如每小時漲 50MB，重啟後歸零] - 流量特徵：[如白天高峰、夜間幾乎無請求] - 最近的改動：[最近上線的功能] - 可疑代碼或已有的監控截圖文字： [粘貼內容] 請分四步回答： 第一步：判斷是不是真的泄漏。說明怎麼區分「泄漏」和「正常的緩存增長 / 垃圾回收還沒觸發 / 堆上限設得太大」，比如看流量低谷時內存會不會回落、手動觸發 GC 後是否下降、增長是否和請求數成正比。 第二步：給出這個運行時的診斷方法，寫出具體命令或操作： - 怎麼在測試環境復現（壓測腳本思路，跑多久）； - 怎麼抓堆快照或內存分析數據，間隔多久抓第二次； - 兩次快照對比時看什麼：哪類對象數量持續增加、保留它們的引用鏈（retainer / GC root 路徑）是什麼。 第三步：對照這些常見泄漏點審查我貼的代碼，逐條說明有沒有、在哪裏： - 全局或模組級的 Map、數組、緩存只增不刪，沒有上限或過期； - 事件監聽、定時器、訂閱註冊後沒有移除； - 閉包長期持有大對象或請求上下文； - 連接、文件句柄、流沒有關閉； - 線程局部變量或請求級對象被存進長生命週期的結構裏。 第四步：給出修復代碼（最小改動），以及上線後怎麼確認修好了（看哪個指標、觀察多長時間）。 要求：命令要寫當前版本真實可用的；對代碼的判斷標明「確定」還是「可疑，需要快照證實」。
高亮處換成你自己的內容：[語言/運行時]、[服務類型與部署方式]、[如每小時漲 50MB，重啟後歸零]、[如白天高峰、夜間幾乎無請求]、[最近上線的功能]、[粘貼內容]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[內存曲線描述] 盡量寫數字和規律，「重啟後歸零、每天漲到上限」和「漲到某個值就穩定」是兩種完全不同的情況，後者通常只是緩存。容器限制、JVM 的 -Xmx 等參數一定要寫上。
常見坑：
- 只抓一次堆快照看不出問題，必須在同樣負載下間隔一段時間抓兩三次做對比，看「持續增長」的那類對象。
- 進程內的本地緩存（比如用 Map 做的緩存）是最常見的元兇，加上大小上限或改用帶淘汰策略的緩存庫。
- Python 裏 C 擴展分配的內存不一定出現在 Python 層的分析工具中，看不到不代表沒有。
追問技巧：拿到快照對比結果後，把「增長最多的前幾類對象和引用鏈」的文字貼回去，問「這條引用鏈說明是哪段代碼持有了對象」。
示例輸出
示例，僅供參考（Node.js 接口服務，每小時漲約 50MB）
判斷：夜間流量接近零時內存不回落，且增長量和請求數成正比，基本可以確定是泄漏。
抓快照：
bash
# 啟動時允許通過信號生成堆快照
node --heapsnapshot-signal=SIGUSR2 server.js
# 壓測 10 分鐘後發送一次，再過 10 分鐘發送第二次
kill -USR2 <pid>在 Chrome DevTools 的 Memory 面板加載兩份快照，選「Comparison」視圖，按 Delta 排序。
代碼審查：
| 泄漏點 | 結論 | 位置 |
|---|---|---|
| 模組級緩存只增不刪 | 確定 | userCache 以請求 ID 為鍵，從不刪除 |
| 事件監聽未移除 | 可疑 | 每個請求都 emitter.on('done')，需快照證實 |
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～