When do you use the sync package instead of channels?

Question

Accepted Answer

Go offers two approaches to concurrency safety: **channels** ("share memory by communicating") and the **`sync` package** (mutexes/locks for protecting shared memory directly). Despite Go's channel-first philosophy, sync primitives are often the simpler, more efficient choice for protecting shared state.

## sync.Mutex — protect shared state with a lock

```go
type Counter struct {
    mu    sync.Mutex
    count int
}

func (c *Counter) Increment() {
    c.mu.Lock()           // acquire the lock — only one goroutine at a time past here
    defer c.mu.Unlock()    // release on return (defer ensures it always happens)
    c.count++              // safe — protected critical section
}
```

A `Mutex` ensures only one goroutine accesses the protected data at a time, preventing data races. The `Lock()`/`defer Unlock()` pattern is idiomatic.

## sync.RWMutex — many readers OR one writer

```go
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` allows concurrent reads but exclusive writes — ideal for read-heavy data like caches.

## Other sync primitives

```go
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
```

## When to use sync vs channels

```text
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
```

The practical rule: **"Don't communicate by sharing memory" is a guideline, not dogma.** For simply protecting shared state, a mutex is clearer and more efficient than contorting the logic into channels.

## Why it matters

Knowing when to use the `sync` package versus channels is a key sign of Go concurrency maturity.

While Go promotes channels ("share memory by communicating"), this is a guideline — and a common mistake is forcing channels where a simple **mutex** would be clearer and faster.

The `sync` package is the right, idiomatic tool for **protecting shared state** (counters, caches, maps): mutexes for exclusive access, `RWMutex` for read-heavy data, `WaitGroup` for waiting on goroutines, `Once` for one-time initialization, and `atomic`/`sync.Map` for specialized cases.

Understanding that channels excel at *communication and coordination* while sync primitives excel at *guarding shared memory* — and choosing the appropriate tool rather than dogmatically using channels — leads to simpler, more efficient, more correct concurrent code.

This judgment is exactly what distinguishes experienced Go developers and is a frequent advanced interview topic.