Исполняемые доки Go: Мьютекс

Q: Что такое мьютекс в Go?

sync.Mutex это блокировка, которая позволяет только одной горутине за раз выполнять код между mu.Lock() и mu.Unlock(). Им защищают данные, которые читают и пишут несколько горутин, например мапу или структуру. Его нулевое значение это разблокированный мьютекс, готовый к работе.

Защита общих данных

sync.Mutex пропускает в код между Lock и Unlock только одну горутину за раз. Кладите мьютекс рядом с данными, которые он охраняет, обычно в ту же структуру:

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

Программа всегда печатает hits: 10000. Без блокировки 100 горутин, пишущих в одну мапу, обычно уронили бы программу с fatal error: concurrent map writes. Эта ошибка идёт от проверки, которую среда выполнения делает по мере возможности, после неё нельзя восстановиться, а отсутствие падения не доказывает, что код корректен.

Важные детали:

Нулевое значение sync.Mutex разблокировано и готово к работе. Конструктор не нужен.
Методы используют получатель-указатель (*Counter). Получатель-значение заблокировал бы копию мьютекса, которая ничего не защищает.
defer c.mu.Unlock() сразу после Lock означает, что любой путь возврата, как и паника, освобождает блокировку.
Любой доступ идёт через блокировку, включая чтение. Чтение без блокировки, пока другая горутина пишет, это всё равно гонка данных.

Держите критическую секцию маленькой

defer разблокирует в конце функции. Для коротких методов, как выше, это правильно. В длинной функции разблокируйте, как только общие данные больше не нужны, чтобы другие горутины не ждали работу, которой блокировка не требуется:

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
}

Удержание блокировки во время сетевых вызовов, дискового ввода-вывода или отправки в канал это самая частая причина медленной конкурентной программы, а отправка в канал под блокировкой частая причина deadlock.

RWMutex для данных, которые в основном читают

У sync.RWMutex два режима. RLock/RUnlock берут разделяемую блокировку на чтение, которую одновременно могут держать многие горутины. Lock/Unlock берут исключительную блокировку на запись, которая ждёт, пока уйдут все читатели.

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 окупается, когда чтения преобладают и каждое чтение делает под блокировкой реальную работу. Для крошечных критических секций вроде одного поиска в мапе обычный Mutex часто не медленнее, потому что у блокировки на чтение есть собственные накладные расходы. Сначала проведите бенчмарк.

Повысить блокировку на чтение до блокировки на запись нельзя. Вызов Lock при удержании RLock в той же горутине приводит к deadlock. Сначала отпустите блокировку на чтение, затем возьмите блокировку на запись и снова проверьте условие, ведь за это время другой писатель мог изменить данные.

sync/atomic для одиночных значений

Для одного счётчика или флага sync/atomic проще и дешевле мьютекса. Используйте типизированные обёртки (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())
}

Атомарные операции защищают одно значение за раз. Как только два значения должны меняться вместе (баланс и число транзакций, мапа и её размер), используйте мьютекс. Между двумя отдельными атомарными операциями могут вклиниться другие горутины.

sync.Once

sync.Once выполняет функцию ровно один раз, сколько бы горутин её ни вызывали одновременно. Все, кто вызывает Do, ждут, пока первый вызов не завершится. Это стандартный способ ленивой инициализации:

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

Каждая строка «runs once» появляется ровно один раз. Если функция, переданная в Do, паникует, Once всё равно считает её выполненной и повторять не будет. sync.OnceValues делает то же для функций, возвращающих два значения, обычно значение и ошибку.

Мьютекс, канал или sync.Map

Ситуация	Что использовать
Структура или мапа, которую несколько горутин обновляют на месте	`sync.Mutex` в структуре
В основном чтения, изредка записи, чтения делают реальную работу	`sync.RWMutex`
Один счётчик или флаг	`sync/atomic`
Однократная инициализация	`sync.Once`, `sync.OnceValue`
Передача данных от одной горутины к другой	канал
Кеш, ключи которого записываются один раз и читаются много раз, или горутины работают с непересекающимися ключами	`sync.Map`

sync.Map не универсальная замена мапе с блокировкой. У неё нет параметров типа, поэтому значения возвращаются как any, и быстрее она только в двух случаях из таблицы. Начинайте с мьютекса и обычной мапы.

Частые ошибки

Копирование мьютекса. Передача по значению структуры, которая содержит sync.Mutex, или получатель-значение копируют блокировку. go vet сообщает passes lock by value или copies lock value.
Двойная блокировка в одной горутине. Мьютексы в Go не реентерабельны. Если Inc вызывает Get и оба берут блокировку, Inc заблокируется навсегда. Пусть публичные методы блокируют, а приватные помощники считают, что блокировка уже взята.
Забытая разблокировка при раннем возврате. Используйте defer, если нет причины поступить иначе.
Блокировки в разном порядке. Если одна горутина берёт блокировку A, затем B, а другая B, затем A, они могут вечно ждать друг друга. Всегда берите несколько блокировок в одном порядке.
Выдача охраняемых данных наружу. Если метод возвращает внутреннюю мапу, вызывающий код может читать и писать её без блокировки. Возвращайте копию (maps.Clone, Go 1.21) или одно значение.
Защита только записей. Чтения без блокировки одновременно с записями под блокировкой всё равно гонки. Запускайте тесты через go test -race.

Часто задаваемые вопросы

Что такое мьютекс в Go?

sync.Mutex это блокировка, которая позволяет только одной горутине за раз выполнять код между mu.Lock() и mu.Unlock(). Им защищают данные, которые читают и пишут несколько горутин, например мапу или структуру. Его нулевое значение это разблокированный мьютекс, готовый к работе.

Когда использовать RWMutex вместо Mutex?

Когда чтений гораздо больше, чем записей, и каждое чтение держит блокировку заметное время. RLock пускает одновременно сколько угодно читателей, а Lock ждёт исключительного доступа. Для коротких критических секций обычный Mutex часто так же быстр или быстрее, поэтому сначала измерьте.

Безопасна ли map в Go для конкурентного использования?

Нет. Конкурентные чтения допустимы, но запись одновременно с любым другим чтением или записью это гонка данных, и среда выполнения обычно её обнаруживает и роняет программу с fatal error: concurrent map writes (или concurrent map read and map write). Защищайте мапу через sync.Mutex или sync.RWMutex либо используйте sync.Map в её конкретных сценариях.

Является ли sync.Mutex в Go реентерабельным?

Нет. Если горутина, которая держит блокировку, снова вызывает Lock, она навсегда блокируется, ожидая саму себя. Стройте код так, чтобы экспортированные методы брали блокировку и вызывали неэкспортированные помощники, которые считают, что блокировка уже взята.

Связанные концепции