Потокобезопасен ли слайс

Потокобезопасность слайса в Go

Нет, слайсы в Go по умолчанию не являются потокобезопасными. Это фундаментальное ограничение встроенного типа данных slice, и понимание причин этого критически важно для написания корректного конкурентного кода.

Почему слайс не потокобезопасен

Слайс — это дескриптор, состоящий из трех компонентов под капотом:

• Указатель на базовый массив
• Длина (length)
• Ёмкость (capacity)

При конкурентной модификации (чтении и записи) без синхронизации возникают проблемы:

1. Гонки данных (Data Races):

   package main
   
   import (
       "fmt"
       "sync"
   )
   
   func main() {
       var s []int
       var wg sync.WaitGroup
       
       for i := 0; i < 1000; i++ {
           wg.Add(1)
           go func() {
               defer wg.Done()
               s = append(s, 1) // ОПАСНО: гонка данных!
           }()
       }
       
       wg.Wait()
       fmt.Println(len(s)) // Результат непредсказуем, обычно меньше 1000
   }
   

2. Повреждение структуры слайса: Операция append может вызвать реаллокацию памяти, и если это происходит одновременно из нескольких горутин, указатель на базовый массив может стать невалидным для некоторых из них.

3. Конкурентное чтение и запись:

   // Даже чтение при наличии параллельной записи опасно
   go func() { s = append(s, 1) }()
   go func() { fmt.Println(s[0]) }() // Может прочитать мусор!
   

Конкретные сценарии проблем

1. Конкурентные операции append

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

2. Реаллокация при расширении

// Если ёмкость недостаточна, append создает новый массив
// Две горутины могут создать разные массивы, потеряв данные друг друга

3. Модификация элементов

s := make([]int, 10)
go func() { s[5] = 42 }()
go func() { s[5] = 100 }() // Конечное значение неопределенно

Стратегии обеспечения потокобезопасности

1. Использование мьютексов

type SafeSlice struct {
    mu    sync.RWMutex
    items []string
}

func (ss *SafeSlice) Append(item string) {
    ss.mu.Lock()
    defer ss.mu.Unlock()
    ss.items = append(ss.items, item)
}

func (ss *SafeSlice) Get(index int) (string, bool) {
    ss.mu.RLock()
    defer ss.mu.RUnlock()
    if index < 0 || index >= len(ss.items) {
        return "", false
    }
    return ss.items[index], true
}

2. Каналы для сериализации доступа

type SliceManager struct {
    ch chan command
}

type command struct {
    action string
    value  interface{}
    resp   chan interface{}
}

func (sm *SliceManager) run() {
    slice := []int{}
    for cmd := range sm.ch {
        switch cmd.action {
        case "append":
            slice = append(slice, cmd.value.(int))
        case "get":
            idx := cmd.value.(int)
            cmd.resp <- slice[idx]
        }
    }
}

3. sync.Map для конкурентных коллекций

Когда нужна частная конкурентная модификация отдельных элементов, sync.Map может быть лучше.

4. Иммемтабельность (функциональный подход)

Создание новых слайсов вместо модификации существующих.

Особый случай: только для чтения

Если слайс инициализирован до запуска горутин и никогда не модифицируется после этого, он безопасен для конкурентного чтения:

data := prepareData() // Создаем данные ДО запуска горутин

var wg sync.WaitGroup
for i := 0; i < 10; i++ {
    wg.Add(1)
    go func(idx int) {
        defer wg.Done()
        _ = data[idx] // Безопасно, если слайс не меняется
    }(i)
}
wg.Wait()

Производительность vs безопасность

Мьютексы добавляют накладные расходы. Альтернативы:

• Разделение данных: Каждая горутина работает со своей частью слайса
• Локальные буферы с последующим объединением
• sync.Pool для временных слайсов

Практические рекомендации

1. Всегда используйте go run -race для детектирования гонок данных
2. Документируйте требования к конкурентному доступу для каждого слайса
3. Предпочитайте каналы или мьютексы в зависимости от семантики доступа
4. Рассмотрите альтернативы: иногда map или структурированные типы лучше подходят

Вывод: Слайсы требуют явной синхронизации при конкурентной модификации. Игнорирование этого приводит к тонким, трудноуловимым багам, которые проявляются только под нагрузкой или недетерминировано. Правильная синхронизация — не опция, а необходимость.