Mutex trong Golang: sync.Mutex, RWMutex, atomic và sync.Once

Bảo vệ dữ liệu dùng chung

sync.Mutex chỉ cho phép mỗi lần một goroutine đi vào phần code nằm giữa Lock và Unlock. Hãy đặt mutex ngay cạnh dữ liệu mà nó bảo vệ, thường là trong cùng một struct:

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"))
}

Chương trình này luôn in ra hits: 10000. Nếu không có khóa, 100 goroutine cùng ghi vào một map thường sẽ làm sập chương trình với fatal error: concurrent map writes. Lỗi đó đến từ một phép kiểm tra "cố gắng hết sức" của runtime, không thể recover, và việc chương trình không sập cũng không chứng minh code đúng.

Những chi tiết quan trọng:

• Giá trị zero của sync.Mutex là chưa khóa và dùng được ngay. Không cần hàm khởi tạo.
• Phương thức dùng receiver con trỏ (*Counter). Receiver giá trị sẽ khóa một bản sao của mutex, và như vậy chẳng bảo vệ được gì.
• defer c.mu.Unlock() ngay sau Lock giúp mọi đường return, kể cả khi panic, đều nhả khóa.
• Mọi lần truy cập đều phải qua khóa, kể cả đọc. Một lần đọc không khóa trong lúc goroutine khác đang ghi vẫn là data race.

Giữ vùng găng thật nhỏ

defer nhả khóa ở cuối hàm. Như vậy là đúng với những phương thức ngắn như ở trên. Trong một hàm dài hơn, hãy nhả khóa ngay khi không còn đụng đến dữ liệu dùng chung, để các goroutine khác không phải chờ những việc không cần khóa:

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
}

Giữ khóa trong lúc gọi mạng, đọc ghi đĩa hay gửi vào channel là nguyên nhân phổ biến nhất khiến chương trình đồng thời chạy chậm, và gửi vào channel khi đang giữ khóa là nguyên nhân thường gặp của deadlock.

RWMutex cho dữ liệu đọc nhiều

sync.RWMutex có hai chế độ. RLock/RUnlock lấy khóa đọc dùng chung, nhiều goroutine có thể giữ cùng lúc. Lock/Unlock lấy khóa ghi độc quyền, khóa này chờ đến khi mọi goroutine đọc đã rời đi.

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 đáng dùng khi phần lớn là đọc và mỗi lần đọc làm việc thực sự trong lúc giữ khóa. Với vùng găng rất nhỏ như một lần tra cứu map, một Mutex thường nhanh không kém, vì khóa đọc cũng có chi phí quản lý riêng. Hãy benchmark trước khi chọn.

Bạn không thể nâng khóa đọc thành khóa ghi. Gọi Lock trong khi vẫn giữ RLock trong cùng một goroutine sẽ gây deadlock. Hãy nhả khóa đọc trước, rồi lấy khóa ghi và kiểm tra lại điều kiện, vì một goroutine ghi khác có thể đã thay đổi dữ liệu trong khoảng giữa.

sync/atomic cho một giá trị đơn lẻ

Với một bộ đếm hay một cờ, sync/atomic đơn giản và rẻ hơn mutex. Nên dùng các kiểu bọc có kiểu (Go 1.19):

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 chỉ bảo vệ từng giá trị một. Ngay khi hai giá trị phải thay đổi cùng nhau (số dư và số giao dịch, một map và kích thước của nó), hãy dùng mutex. Hai thao tác atomic riêng rẽ có thể bị goroutine khác chen vào giữa.

sync.Once

sync.Once chạy một hàm đúng một lần, dù có bao nhiêu goroutine gọi nó cùng lúc. Mọi goroutine gọi Do đều chờ đến khi lần gọi đầu tiên chạy xong. Đây là cách chuẩn để khởi tạo trễ một thứ gì đó:

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())
}

Mỗi dòng "runs once" xuất hiện đúng một lần. Nếu hàm truyền vào Do panic, Once vẫn coi như đã chạy xong và không bao giờ thử lại. sync.OnceValues làm điều tương tự cho những hàm trả về hai giá trị, thường là một giá trị và một lỗi.

Mutex, channel hay sync.Map

sync.Map không phải là thứ thay thế chung cho một map có khóa. Nó không có tham số kiểu, nên giá trị trả về là any, và nó chỉ nhanh hơn trong hai trường hợp ở bảng trên. Hãy bắt đầu với một mutex và một map bình thường.

Lỗi thường gặp

• Sao chép mutex. Truyền theo giá trị một struct chứa sync.Mutex, hoặc dùng receiver giá trị, sẽ sao chép cả khóa. go vet báo passes lock by value hoặc copies lock value.
• Khóa hai lần trong một goroutine. Mutex của Go không reentrant. Nếu Inc gọi Get và cả hai cùng lấy khóa, Inc sẽ bị chặn mãi mãi. Hãy để các phương thức public lấy khóa, còn các hàm hỗ trợ private mặc định là khóa đã được giữ.
• Quên nhả khóa khi return sớm. Hãy dùng defer, trừ khi có lý do để không dùng.
• Lấy khóa theo thứ tự khác nhau. Nếu một goroutine lấy khóa A rồi B, trong khi goroutine khác lấy B rồi A, cả hai có thể chờ nhau mãi mãi. Luôn lấy nhiều khóa theo cùng một thứ tự.
• Để lộ dữ liệu được bảo vệ. Trả về map bên trong từ một phương thức cho phép nơi gọi đọc và ghi nó mà không qua khóa. Hãy trả về một bản sao (maps.Clone, Go 1.21) hoặc một giá trị đơn lẻ.
• Chỉ bảo vệ các lần ghi. Đọc không khóa đồng thời với ghi có khóa vẫn là race. Hãy chạy test bằng go test -race.