Πότε χρησιμοποιείτε το πακέτο sync αντί για channels;

Question

Accepted Answer

Το Go προσφέρει δύο προσεγγίσεις για ασφάλεια ταυτοχρονισμού: **channels** ("μοιράστε μνήμη μέσω επικοινωνίας") και το **πακέτο `sync`** (mutexes/κλειδώματα για προστασία κοινόχρηστης μνήμης απευθείας). Παρά τη φιλοσοφία του Go που προτιμά τα channels, τα sync primitives είναι συχνά η απλούστερη και αποδοτικότερη επιλογή για προστασία κοινόχρηστης κατάστασης.

## sync.Mutex — προστασία κοινόχρηστης κατάστασης με ένα κλείδωμα

```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 έχει πρόσβαση στα προστατευμένα δεδομένα κάθε φορά, αποτρέποντας race conditions. Το πρότυπο `Lock()`/`defer Unlock()` είναι ιδιωματικό.

## sync.RWMutex — πολλοί αναγνώστες Ή ένας συγγραφέας

```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` επιτρέπει ταυτόχρονες αναγνώσεις αλλά αποκλειστική εγγραφή — ιδανικό για δεδομένα με υψηλό ποσοστό ανάγνωσης όπως οι κρυφές μνήμες.

## Άλλα 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
```

## Πότε να χρησιμοποιήσετε sync έναντι 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
```

Ο πρακτικός κανόνας: **"Μην επικοινωνείτε μοιράζοντας μνήμη" είναι μια κατευθυντήρια γραμμή, όχι δογματισμός.** Για απλή προστασία κοινόχρηστης κατάστασης, ένα mutex είναι πιο σαφές και αποδοτικό από το να στρεβλώνετε τη λογική σε channels.

## Γιατί είναι σημαντικό

Το να γνωρίζετε πότε να χρησιμοποιείτε το πακέτο `sync` έναντι channels είναι ένα βασικό σημάδι της ωριμότητας ταυτοχρονισμού του Go.

Αν και το Go προάγει τα channels ("μοιράστε μνήμη μέσω επικοινωνίας"), αυτή είναι μια κατευθυντήρια γραμμή — και ένα συνηθισμένο λάθος είναι η επιβολή των channels όπου ένα απλό **mutex** θα ήταν πιο σαφές και γρήγορο.

Το πακέτο `sync` είναι το σωστό, ιδιωματικό εργαλείο για **προστασία κοινόχρηστης κατάστασης** (μετρητές, κρυφές μνήμες, χάρτες): mutexes για αποκλειστική πρόσβαση, `RWMutex` για δεδομένα με υψηλό ποσοστό ανάγνωσης, `WaitGroup` για αναμονή σε goroutines, `Once` για ενιαία αρχικοποίηση, και `atomic`/`sync.Map` για ειδικές περιπτώσεις.

Το να καταλαβαίνετε ότι τα channels διαπρέπουν στην *επικοινωνία και συντονισμό* ενώ τα sync primitives διαπρέπουν στην *προστασία κοινόχρηστης μνήμης* — και να επιλέγετε το κατάλληλο εργαλείο αντί να χρησιμοποιείτε τα channels κατά δογματισμό — οδηγεί σε απλούστερο, πιο αποδοτικό και πιο σωστό κώδικα ταυτοχρονισμού.

Αυτή η κρίση είναι ακριβώς αυτό που διακρίνει τους έμπειρους προγραμματιστές Go και είναι ένα συχνό θέμα σε προχωρημένες συνεντεύξεις.