Go は並行安全性に対して 2 つのアプローチを提供しています: channel ("メモリを共有して通信する") と sync パッケージ (共有メモリを直接保護するための mutex/ロック)。Go の channel-first 哲学にもかかわらず、sync プリミティブは多くの場合、共有状態を保護するためのより単純で効率的な選択肢です。
Counter {
mu sync.Mutex
count
}
Increment() {
c.mu.Lock()
c.mu.Unlock()
c.count++
}
Mutex は、保護されたデータへのアクセスを 1 つの goroutine に限定し、データ競合を防ぎます。Lock()/defer Unlock() パターンは慣用的です。
type Cache struct {
mu sync.RWMutex
data map[string]string
}
func (c *Cache) Get(key string) string {
c.mu.RLock() // READ lock — multiple readers allowed concurrently
defer c.mu.RUnlock()
return c.data[key]
}
func (c *Cache) Set(key, value string) {
c.mu.Lock() // WRITE lock — exclusive
defer c.mu.Unlock()
c.data[key] = value
}
RWMutex は並行読み取りを許可しますが、書き込みは排他的です — キャッシュなどの読み取り集約的なデータに理想的です。
sync.WaitGroup // wait for a group of goroutines to finish (Add/Done/Wait)
sync.Once // run something EXACTLY once (lazy init, singletons)
var once sync.Once
once.Do(initialize) // initialize runs only on the first call, ever
sync.Map // a concurrent map (specialized cases)
atomic.AddInt64(&n, 1) // lock-free atomic operations for simple counters
Use sync (Mutex/RWMutex/atomic) when:
✓ Protecting simple shared STATE (a counter, a cache, a map)
✓ The logic is "guard this data" — locking is simpler and faster than channels here
✓ Read-heavy data (RWMutex), one-time init (Once), simple counters (atomic)
Use channels when:
✓ COMMUNICATING/passing data between goroutines, signaling, coordinating
✓ Pipelines, worker distribution, ownership transfer
実践的なルール: "メモリを共有して通信しない" はガイドラインであり、教義ではありません。 単に共有状態を保護するには、mutex の方が channel にロジックを無理やり合わせるより明確で効率的です。
sync パッケージと channel をどのように使い分けるかを知ることは、Go の並行処理の成熟度の重要な指標です。
Go は channel を推奨していますが ("メモリを共有して通信する")、これはガイドラインであり、よくある誤りは、シンプルな mutex の方がより明確で高速な場面で channel を無理やり使うことです。
sync パッケージは、共有状態を保護する (カウンタ、キャッシュ、マップ) ための正しい慣用的なツールです: 排他的アクセスには mutex、読み取り集約的なデータには RWMutex、goroutine の待機には WaitGroup、1 回限りの初期化には Once、特殊なケースには atomic/sync.Map です。
Channel は 通信と協調 に優れ、sync プリミティブは 共有メモリの保護 に優れているということを理解し、教義的に channel を使うのではなく適切なツールを選択することで、より単純で効率的で正確な並行コードが得られます。
この判断力は正に経験豊富な Go 開発者を区別する特徴であり、高度なインタビュー質問として頻出です。