バッファリングされたチャネルのユースケースは何ですか? 複数の並列アクションが必要な場合は、デフォルトの同期チャネル eq を使用できます。
package main
import "fmt"
import "time"
func longLastingProcess(c chan string) {
time.Sleep(2000 * time.Millisecond)
c <- "tadaa"
}
func main() {
c := make(chan string)
go longLastingProcess(c)
go longLastingProcess(c)
go longLastingProcess(c)
fmt.Println(<- c)
}
バッファサイズを増やす実際のケースは何ですか?
一般に、チャネルでのバッファリングは、パフォーマンス上の理由から有益です。
プログラムがイベント フローまたはデータ フロー アプローチを使用して設計されている場合、チャネルは、あるプロセスと別のプロセスの間でイベントを渡す手段を提供します (私は Tony Hoare のCommunicating Sequential Processes (CSP)と同じ意味でプロセスという用語を使用します)。 、つまりゴルーチンと事実上同義です)。
プログラムのコンポーネントがロックステップ同期を維持する必要がある場合があります。この場合、バッファリングされていないチャネルが必要です。
それ以外の場合は、通常、チャネルにバッファリングを追加すると効果的です。これは最適化のステップと見なす必要があります (設計されていない場合、デッドロックが発生する可能性があります)。
小さなバッファを持つチャネルを使用することで可能になった新しいスロットル構造があります (例)。
プロセスのサイクル (またはループ) の特殊なケースを修正するために、 occamおよびjcspで使用される特別な上書きまたは損失の多い形式のチャネルがあり、そうでなければデッドロックする可能性があります。これは、Go で上書きゴルーチン バッファーを記述することによっても可能です ( example )。
デッドロックを修正するためだけにバッファリングを追加しないでください。プログラムがデッドロックした場合、ゼロ バッファリングから始めて依存関係を検討することで、はるかに簡単に修正できます。次に、デッドロックしないことがわかっているときにバッファリングを追加します。
ゴルーチンは構成的に構築できます。つまり、ゴルーチン自体にゴルーチンを含めることができます。これは CSP の機能であり、スケーラビリティに非常に役立ちます。ゴルーチンのグループ間の内部チャネルは、グループを自己完結型コンポーネントとして外部で使用するように設計する場合には重要ではありません。この原則は、ますます大きなスケールで繰り返し適用できます。
もう少し具体的な使用例を 1 つ挙げると、次のようになります。
タスク スケジューラがジョブをキューに送信し、ワーカー スレッドがチャネルでジョブを受信することでジョブを消費できるように、チャネルをタスク キューとして表現するとします。
さらに、一般的には各ジョブがタイムリーに処理されることを期待していますが、スケジューラーがタスクをスケジュールするよりも、ワーカーがタスクを完了するのに時間がかかるとします。
バッファーがあると、スケジューラーはジョブをキューに入れても、タスクをスケジュールするたびにワーカーの準備が整うまでスリープする必要がないため、ユーザー入力 (またはネットワーク トラフィックなど) に応答し続けることができます。代わりに、ビジネスに専念し、労働者がより静かな時期に追いつくことを信頼しています。
特定のソフトウェアを扱うさらに具体的な例が必要な場合は、何ができるか見ていきますが、これがあなたのニーズを満たすことを願っています.
バッファリングされたチャネルは、まだ余裕がある限り、送信者にとって非ブロックです。これにより、応答性とスループットが向上します。
1 つのバッファリングされたチャネルで複数のアイテムを送信すると、それらが送信された順序で処理されることが保証されます。
有効な移動から (例を使用): 「バッファリングされたチャネルは、たとえばスループットを制限するために、セマフォのように使用できます。」
一般に、チャネルの使用には多くのユースケースとパターンがあるため、これは網羅的な答えではありません。