我正在練習通過同時將計算分成 100 個組來計算階乘的挑戰(zhàn)，我在 WaitGroups 上解決了很多問題，但仍然在函數(shù)中calculateFactorial我在通道部分的范圍上遇到了死鎖。希望有人能指出這里的問題，謝謝。更新：它通過簡單地將 更改為緩沖通道解決了上述代碼中的問題。你永遠不應該僅僅為了修復死鎖而添加緩沖。如果您的程序死鎖，從零緩沖開始并仔細考慮依賴關系，修復起來要容易得多。然后在您知道不會死鎖時添加緩沖。那么誰能幫我弄清楚如何不為此使用緩沖通道？是否可以？此外，我對導致死鎖的確切原因做了一些研究。如果通道是無緩沖的，則發(fā)送方會阻塞，直到接收方收到該值。如果通道有緩沖區(qū)，發(fā)送方只會阻塞直到值被復制到緩沖區(qū)；如果緩沖區(qū)已滿，這意味著等待某個接收者檢索到一個值。否則說：當通道已滿時，發(fā)送方等待另一個 goroutine 通過接收來騰出一些空間你可以看到一個無緩沖的通道總是滿的：必須有另一個 goroutine 來接收發(fā)送者發(fā)送的內(nèi)容。所以在我原來的情況下，可能導致僵局的原因可能是：頻道上的范圍沒有接收到？通道上的范圍未在單獨的 go 例程中接收。？沒有oneResult正確關閉，所以 range over channel 不知道盡頭在哪里？對于數(shù)字 3，我不知道關閉 before range over 是否有任何錯誤oneResult，因為這種模式出現(xiàn)在互聯(lián)網(wǎng)上的許多示例中。如果是 3 號，是不是等待組有問題？我得到了另一篇與我的情況非常相似的文章，他使用for { select {} }無限循環(huán)作為 range over 的替代方法，似乎解決了他的問題。go func() {? ? ? ? for{? ? ? ? ? ? select {? ? ? ? ? ? case p := <-pch:? ? ? ? ? ? ? ? findcp(p)? ? ? ? ? ? }? ? ? ? }? ? }()第 2 課 &mdash; 無緩沖通道無法保存值（是的，它就在名稱&ldquo;無緩沖&rdquo;中），因此無論發(fā)送到該通道的什么，都必須立即由其他代碼接收。接收代碼必須在不同的 goroutine 中，因為一個 goroutine 不能同時做兩件事：它不能發(fā)送和接收；它必須是一個或另一個。