協程泄漏可通過監控協程數、使用pprof分析堆棧、優化退出機制來排查和預防。首先，通過runtime.numgoroutine()監控協程數量，若持續增長則可能存在泄漏；其次，使用pprof查看goroutine堆棧，重點檢查處于chan receive、select或sleep狀態的協程；最后，在編碼中避免常見問題，如忘記關閉channel、select無default分支、循環中無限啟動協程，并結合日志埋點和context控制生命周期，確保協程能正常退出。
協程泄漏在 golang 中是一個常見但容易被忽視的問題，尤其在高并發場景下，如果協程沒有正確退出，會導致內存占用持續增長、系統性能下降，甚至服務崩潰。本文直接切入主題，講幾個實用的方法，幫你檢測和預防協程泄漏，特別是結合 runtime 工具進行實戰排查。
如何發現協程數量異常？
最簡單的判斷方式就是監控當前運行的 goroutine 數量。Golang 提供了 runtime.NumGoroutine() 函數，可以實時獲取活躍的協程數。你可以把它嵌入到健康檢查接口或者日志中定期輸出：
log.Println("current goroutines:", runtime.NumGoroutine())
如果你觀察到這個數字一直增長且不回落，那大概率存在協程泄漏。這時候就需要進一步分析具體是哪個地方創建了大量無法退出的協程。
立即學習“go語言免費學習筆記（深入）”；
使用 pprof 查看協程堆棧信息
Go 自帶的 pprof 工具非常強大，不僅可以用來分析 CPU 和內存使用情況，還能查看所有正在運行的協程堆棧信息。
啟用方法很簡單，在你的服務中加入以下代碼：
import _ "net/http/pprof" go func() { http.ListenAndServe(":6060", nil) }()
然后訪問 http://localhost:6060/debug/pprof/goroutine?debug=1，可以看到當前所有 goroutine 的調用棧。重點查找那些處于 chan receive, select, 或者 sleep 狀態但長時間不退出的協程。
比如你可能會看到類似這樣的內容：
goroutine 123 [chan receive]: main.worker()
這說明某個 worker 協程卡在了 channel 接收操作上，可能是因為沒有關閉 channel 導致的阻塞。
避免協程泄漏的幾個關鍵點
協程泄漏的根本原因通常是：協程沒有正常退出路徑。下面是幾個常見的場景和應對建議：
- 忘記關閉 channel：向已關閉的 channel 發送數據會 panic，但從未關閉的 channel 讀取會一直阻塞。確保所有寫端都關閉 channel。
- select 沒有 default 分支或退出機制：如果 select 里只有幾個 case 在等 channel，而這些 channel 又永遠不觸發，協程就會卡住。
- 使用 context 控制生命周期：傳入 context 并監聽 ctx.Done() 是一種推薦做法，尤其是在處理 HTTP 請求、后臺任務時。
- 循環中啟動協程未控制生命周期：比如在一個 for 循環里不斷起新協程但沒有退出機制，很容易積累大量僵尸協程。
舉個例子：
for { go func() { // 沒有任何退出邏輯 time.Sleep(time.Hour) }() }
這段代碼會在每次循環中啟動一個協程，并且每個協程都睡一小時，但沒有任何機制能終止它們，最終導致協程爆炸。
實戰小技巧：加 defer 檢查和日志埋點
為了更容易定位問題，可以在協程開始和結束的地方加上日志，特別是在關鍵函數入口和出口處：
go func() { log.Println("goroutine started") defer func() { log.Println("goroutine exited") }() // 協程邏輯 }()
這樣即使協程真的泄露了，也可以通過日志對比“start”和“exit”的數量差異來快速發現問題點。
另外，可以考慮封裝一個帶超時的協程管理器，自動回收長時間未完成的任務。
基本上就這些。檢測協程泄漏的關鍵在于主動監控 + 日常編碼習慣，別讓協程變成“孤兒”。工具雖然好用，但還是要靠平時寫代碼的時候多留心結構設計和退出機制。
