Mutex di Golang: sync.Mutex, RWMutex, atomic, dan sync.Once

Melindungi data bersama

sync.Mutex mengizinkan satu goroutine pada satu waktu masuk ke kode di antara Lock dan Unlock. Taruh mutex di sebelah data yang dijaganya, biasanya di struct yang sama:

package main

import (
	"fmt"
	"sync"
)

type Counter struct {
	mu     sync.Mutex
	counts map[string]int
}

func (c *Counter) Inc(key string) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.counts[key]++
}

func (c *Counter) Get(key string) int {
	c.mu.Lock()
	defer c.mu.Unlock()
	return c.counts[key]
}

func main() {
	c := Counter{counts: make(map[string]int)}

	var wg sync.WaitGroup
	for range 100 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			for range 100 {
				c.Inc("hits")
			}
		}()
	}
	wg.Wait()

	fmt.Println("hits:", c.Get("hits"))
}

Program ini selalu mencetak hits: 10000. Tanpa lock, 100 goroutine yang menulis ke map yang sama biasanya akan membuat program crash dengan fatal error: concurrent map writes. Error itu berasal dari pemeriksaan best-effort di runtime, tidak bisa di-recover, dan tidak adanya crash tidak membuktikan bahwa kodenya benar.

Detail yang penting:

• Zero value sync.Mutex sudah tidak terkunci dan siap dipakai. Tidak perlu constructor.
• Method memakai pointer receiver (*Counter). Value receiver akan mengunci salinan mutex, yang tidak melindungi apa pun.
• defer c.mu.Unlock() tepat setelah Lock berarti setiap jalur return, dan juga panic, akan melepas lock.
• Setiap akses melewati lock, termasuk pembacaan. Pembacaan tanpa lock saat goroutine lain menulis tetap merupakan data race.

Jaga critical section tetap kecil

defer melepas lock di akhir fungsi. Itu tepat untuk method pendek seperti di atas. Di fungsi yang lebih panjang, lepas lock begitu data bersama tidak lagi disentuh, supaya goroutine lain tidak menunggu pekerjaan yang tidak butuh lock:

func (s *Store) Save(key string) error {
	s.mu.Lock()
	data := s.items[key] // copy what you need
	s.mu.Unlock()

	return writeToDisk(key, data) // slow I/O, outside the lock
}

Menahan lock selama pemanggilan jaringan, I/O disk, atau pengiriman ke channel adalah penyebab paling umum program concurrent yang lambat, dan pengiriman ke channel saat memegang lock adalah penyebab umum deadlock.

RWMutex untuk data yang sering dibaca

sync.RWMutex punya dua mode. RLock/RUnlock mengambil read lock bersama yang bisa dipegang banyak goroutine sekaligus. Lock/Unlock mengambil write lock eksklusif, yang menunggu sampai semua pembaca keluar.

package main

import (
	"fmt"
	"sync"
)

type Config struct {
	mu     sync.RWMutex
	values map[string]string
}

func (c *Config) Get(key string) (string, bool) {
	c.mu.RLock()
	defer c.mu.RUnlock()
	v, ok := c.values[key]
	return v, ok
}

func (c *Config) Set(key, value string) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.values[key] = value
}

func main() {
	cfg := &Config{values: map[string]string{"mode": "dev"}}

	var wg sync.WaitGroup
	for range 50 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			cfg.Get("mode") // many readers at the same time
		}()
	}
	wg.Add(1)
	go func() {
		defer wg.Done()
		cfg.Set("mode", "prod") // one writer, exclusive
	}()
	wg.Wait()

	v, _ := cfg.Get("mode")
	fmt.Println("mode:", v)
}

RWMutex sepadan saat pembacaan mendominasi dan setiap pembacaan melakukan pekerjaan sungguhan di bawah lock. Untuk critical section yang sangat kecil seperti satu kali pencarian di map, Mutex biasa sering sama cepatnya, karena read lock punya pencatatannya sendiri. Lakukan benchmark sebelum memilih.

Kamu tidak bisa menaikkan read lock menjadi write lock. Memanggil Lock saat masih memegang RLock di goroutine yang sama akan deadlock. Lepas read lock dulu, lalu ambil write lock dan periksa kondisinya lagi, karena penulis lain mungkin sudah mengubah data di antaranya.

sync/atomic untuk satu nilai

Untuk satu counter atau flag, sync/atomic lebih sederhana dan lebih murah daripada mutex. Wrapper bertipe (Go 1.19) adalah yang sebaiknya dipakai:

package main

import (
	"fmt"
	"sync"
	"sync/atomic"
)

func main() {
	var requests atomic.Int64
	var ready atomic.Bool

	var wg sync.WaitGroup
	for range 1000 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			requests.Add(1)
		}()
	}
	wg.Wait()
	ready.Store(true)

	fmt.Println("requests:", requests.Load())
	fmt.Println("ready:", ready.Load())

	// CompareAndSwap: set only if the current value is what you expect.
	fmt.Println("swapped:", requests.CompareAndSwap(1000, 0), "now:", requests.Load())
}

Atomic melindungi satu nilai pada satu waktu. Begitu dua nilai harus berubah bersamaan (saldo dan jumlah transaksi, map dan ukurannya), pakai mutex. Dua operasi atomic yang terpisah bisa diselingi goroutine lain di antaranya.

sync.Once

sync.Once menjalankan sebuah fungsi tepat satu kali, sebanyak apa pun goroutine yang memanggilnya pada saat bersamaan. Semua yang memanggil Do menunggu sampai pemanggilan pertama selesai. Ini cara standar untuk menginisialisasi sesuatu secara lazy:

package main

import (
	"fmt"
	"sync"
)

var (
	once   sync.Once
	config map[string]string
)

func loadConfig() map[string]string {
	once.Do(func() {
		fmt.Println("loading config (runs once)")
		config = map[string]string{"env": "prod"}
	})
	return config
}

// Go 1.21: OnceValue wraps a function and caches its result.
var port = sync.OnceValue(func() int {
	fmt.Println("computing port (runs once)")
	return 8080
})

func main() {
	var wg sync.WaitGroup
	for range 5 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			_ = loadConfig()
			_ = port()
		}()
	}
	wg.Wait()
	fmt.Println(loadConfig()["env"], port())
}

Setiap baris "runs once" muncul tepat satu kali. Kalau fungsi yang diberikan ke Do memicu panic, Once tetap menganggapnya selesai dan tidak pernah mencoba lagi. sync.OnceValues melakukan hal yang sama untuk fungsi yang mengembalikan dua nilai, biasanya sebuah nilai dan error.

Mutex, channel, atau sync.Map

sync.Map bukan pengganti umum untuk map yang dikunci. Tipe ini tidak punya type parameter, jadi nilainya kembali sebagai any, dan hanya lebih cepat di dua kasus dalam tabel. Mulailah dengan mutex dan map biasa.

Kesalahan umum

• Menyalin mutex. Mengirim struct yang berisi sync.Mutex sebagai nilai, atau memakai value receiver, akan menyalin lock-nya. go vet melaporkan passes lock by value atau copies lock value.
• Mengunci dua kali dalam satu goroutine. Mutex di Go tidak reentrant. Kalau Inc memanggil Get dan keduanya mengambil lock, Inc terblokir selamanya. Biarkan method publik yang mengunci, dan helper privat menganggap lock sudah dipegang.
• Lupa melepas lock saat return lebih awal. Pakai defer, kecuali kamu punya alasan untuk tidak memakainya.
• Mengunci dengan urutan berbeda. Kalau satu goroutine mengambil lock A lalu B sementara goroutine lain mengambil B lalu A, keduanya bisa saling menunggu selamanya. Selalu ambil beberapa lock dengan urutan yang sama.
• Membuka akses ke data yang dijaga. Mengembalikan map internal dari sebuah method memungkinkan pemanggil membaca dan menulisnya tanpa lock. Kembalikan salinannya (maps.Clone, Go 1.21) atau satu nilai saja.
• Hanya melindungi penulisan. Pembacaan tanpa lock yang bersamaan dengan penulisan yang dikunci tetap merupakan race. Jalankan test-mu dengan go test -race.