คุณจะใช้ package sync แทน channel เมื่อไหร่?

Question

Accepted Answer

Go มีสองแนวทางสำหรับความปลอดภัยด้าน concurrency ได้แก่ **channel** ("share memory by communicating") และ **package `sync`** (mutex/lock เพื่อปกป้อง shared memory โดยตรง) แม้ว่า Go จะมีปรัชญาที่เน้น channel เป็นหลัก แต่ sync primitive มักเป็นทางเลือกที่ง่ายกว่าและมีประสิทธิภาพกว่าสำหรับการปกป้อง shared state

## sync.Mutex — ปกป้อง shared state ด้วย 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
}
```

`Mutex` รับประกันว่ามี goroutine เพียงตัวเดียวเท่านั้นที่เข้าถึงข้อมูลที่ถูกปกป้องในแต่ละขณะ จึงป้องกัน data race ได้ pattern `Lock()`/`defer Unlock()` เป็น idiomatic

## sync.RWMutex — reader หลายตัว หรือ 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` อนุญาตให้อ่านพร้อมกันได้ แต่เขียนได้แบบ exclusive เหมาะอย่างยิ่งกับข้อมูลที่อ่านบ่อยอย่าง cache

## sync primitive อื่น ๆ

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

## เมื่อไหร่ควรใช้ sync เทียบกับ channel

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

กฎเชิงปฏิบัติ: **"Don't communicate by sharing memory" เป็นแนวทาง ไม่ใช่หลักการตายตัว** สำหรับการปกป้อง shared state แบบเรียบง่าย mutex จะชัดเจนและมีประสิทธิภาพกว่าการบิดตรรกะให้กลายเป็น channel

## ทำไมจึงสำคัญ

การรู้ว่าเมื่อไหร่ควรใช้ package `sync` เทียบกับ channel เป็นสัญญาณสำคัญของความเป็นผู้ใหญ่ในด้าน concurrency ของ Go

แม้ Go จะสนับสนุน channel ("share memory by communicating") แต่นี่เป็นเพียงแนวทาง และความผิดพลาดที่พบบ่อยคือการบังคับใช้ channel ในที่ที่ **mutex** แบบเรียบง่ายจะชัดเจนและเร็วกว่า

package `sync` เป็นเครื่องมือที่ถูกต้องและ idiomatic สำหรับ **การปกป้อง shared state** (counter, cache, map) ได้แก่ mutex สำหรับการเข้าถึงแบบ exclusive, `RWMutex` สำหรับข้อมูลที่อ่านบ่อย, `WaitGroup` สำหรับการรอ goroutine, `Once` สำหรับการ initialize ครั้งเดียว และ `atomic`/`sync.Map` สำหรับกรณีเฉพาะทาง

การเข้าใจว่า channel เก่งในด้าน *การสื่อสารและการประสานงาน* ขณะที่ sync primitive เก่งในด้าน *การปกป้อง shared memory* และการเลือกเครื่องมือที่เหมาะสมแทนที่จะใช้ channel แบบตายตัว นำไปสู่โค้ด concurrent ที่เรียบง่าย มีประสิทธิภาพ และถูกต้องมากขึ้น

วิจารณญาณนี้คือสิ่งที่แยกแยะนักพัฒนา Go ที่มีประสบการณ์ได้อย่างชัดเจน และเป็นหัวข้อสัมภาษณ์ขั้นสูงที่พบบ่อย