sync.WaitGroupを使用してのベストな方法

Question

私は次のコードでいくつかの問題があります。

package main 

import (
"fmt" 
"sync" 
) 
// This program should go to 11, but sometimes it only prints 1 to 10. 
func main() { 
    ch := make(chan int) 
    var wg sync.WaitGroup 
    wg.Add(2) 
    go Print(ch, wg) // 
    go func(){ 

     for i := 1; i <= 11; i++ { 
      ch <- i 
     } 

     close(ch) 
     defer wg.Done() 


    }() 

    wg.Wait() //deadlock here 
} 

// Print prints all numbers sent on the channel. 
// The function returns when the channel is closed. 
func Print(ch <-chan int, wg sync.WaitGroup) { 
    for n := range ch { // reads from channel until it's closed 
     fmt.Println(n) 
    } 
    defer wg.Done() 
} 

は私が指定した場所でのデッドロックを取得します。私は012の代わりにwg.Add(1)を試して、それは私の問題を解決します。私の信念は、Printer関数の引数としてチャンネルを正常に送信していないということです。それを行う方法はありますか？最善の解決策は何

func Print(ch <-chan int) { 
    for n := range ch { // reads from channel until it's closed 
     fmt.Println(n) 
    } 

} 

：へ

go func() { 
Print(ch) 
defer wg.Done() 
} 

とPrinter機能を変更：そうでなければ、私の問題を解決するには、とのgo Print(ch, wg)ラインを交換していますか？

Answer 1

まあ、最初にあなたの実際のエラーは、Print方法にsync.WaitGroupのコピーを与えているということですので、それはあなたが上のINGのWait()だ1上Done()メソッドを呼び出すことはありません。

代わりにこれを試してみてください：

今

package main 

import (
    "fmt" 
    "sync" 
) 

func main() {  
    ch := make(chan int) 

    var wg sync.WaitGroup 
    wg.Add(2)  

    go Print(ch, &wg) 

    go func() { 
     for i := 1; i <= 11; i++ { 
      ch <- i 
     } 
     close(ch) 
     defer wg.Done() 
    }()   

    wg.Wait() //deadlock here 
}     

func Print(ch <-chan int, wg *sync.WaitGroup) { 
    for n := range ch { // reads from channel until it's closed 
     fmt.Println(n) 
    }    
    defer wg.Done() 
} 

を、それのWaitGroupを削除するために、あなたのPrint方法を変更することは、一般的に良いアイデアです：メソッドは、その仕事を終了するのを何かが待っているかを知る必要はありません。

Answer 2

あなたのコードの主な問題は、WaitgroupのコピーをPrintの関数に渡したことに起因する@Elwinarの解決法に同意します。

これはmainで定義したwgのコピーでwg.Done()が動作していることを意味します。したがって、mainのwgは減少することができませんでした。したがって、メインにwg.Wait()があるとデッドロックが発生します。

あなたはまた、ベストプラクティスについて尋ねているので、私はあなたに私自身のいくつかの提案を与えることができる：

• Printでdefer wg.Done()を削除しないでください。 mainのgoroutineが送信者で、印刷がレシーバーであるため、レシーバールーチン内のwg.Done()を削除すると未完成のレシーバーが発生します。これはあなたの送信者だけがあなたのメインと同期しているので、あなたの送信者が完了した後、あなたのメインは完了していますが、受信機がまだ動作している可能性があります。私のポイントは：あなたのメインルーチンが終了した後、いくつかのぶら下がったゴルーチンを残さないでください。それらを閉じたり、それらを待ってください。

• パニック回復はどこでも、特に匿名のゴルーチンを覚えておいてください。私はgolangプログラマーの多くがゴルーチンにパニックリカバリを忘れているのを見てきました。予期せぬことが起こったときに、コードが正しく動作するように、または少なくとも正常に動作させるためには、非常に重要です。初めでsync関連の呼び出しなどのすべての重要な呼び出し、前

• 使用defer、コードが壊れる可能性が場所がわからないので。例えば、wg.Done()の前にdeferを削除し、あなたの例であなたの匿名のゴルーチンにパニックが発生したとします。パニックが回復しない場合、パニックになります。しかし、パニックが回復したらどうなりますか？今はすべてうまいですか？いいえ。wg.Done()がパニックのためにスキップされるため、デッドロックはwg.Wait()になります。ただし、deferを使用すると、パニックが発生しても最後にこのwg.Done()が実行されます。また、closeの前に延期することも重要です。その結果もコミュニケーションに影響します。だからここ

は、私は上記の点に応じて変更されたコードです：

package main 

import (
    "fmt" 
    "sync" 
) 

func main() { 
    ch := make(chan int) 
    var wg sync.WaitGroup 
    wg.Add(2) 
    go Print(ch, &wg) 
    go func() { 

     defer func() { 
      if r := recover(); r != nil { 
       println("panic:" + r.(string)) 
      } 
     }() 

     defer func() { 
      wg.Done() 
     }() 

     for i := 1; i <= 11; i++ { 
      ch <- i 

      if i == 7 { 
       panic("ahaha") 
      } 
     } 

     println("sender done") 
     close(ch) 
    }() 

    wg.Wait() 
} 

func Print(ch <-chan int, wg *sync.WaitGroup) { 
    defer func() { 
     if r := recover(); r != nil { 
      println("panic:" + r.(string)) 
     } 
    }() 

    defer wg.Done() 

    for n := range ch { 
     fmt.Println(n) 
    } 
    println("print done") 
} 

は、それが:)