Паттерны Проектирования На Go. Singleton

Рассмотрим простой и вообщем-то спорный шаблон Singleton. Его “потокобезопасную” версию и общие подходы к решению таких задач.

Классическое назначение: гарантирует, что у типа есть только один экземпляр, и предоставляет глобальную точку доступа к нему.

В объектно-ориентированных языках синглетон эмулирует глобальные переменные.

В Go есть глобальные переменные, которые к тому же могут быть инициализированы в init(). Но синглетон может дать возможность для отложенной(ленивой) инициализация(lazy initialization).

Надо помнить, что синглетон обладает теми же проблема, что и глобальные переменные.

Начнем с простой реализации

Реализуем глобальный счетчик:

package base

type Singleton interface {
   AddOne() int
}

type singleton struct {
   count int
}

var instance *singleton

func GetInstance() Singleton {
   if instance==nil{
      instance = new(singleton)
   }
   return instance
}
func (s *singleton) AddOne() int {
   s.count++
   return s.count
}

Напишем тесты и убедимся что он работает:

package base

import "testing"

func TestGetInstance(t *testing.T) {
   var counter1 Singleton
   counter1 = GetInstance()
   if counter1 == nil {
      t.Fatalf("expected pointer to Singleton after calling GetInstance(), not nil")
   }

   currentCount := counter1.AddOne()
   if currentCount != 1 {
      t.Errorf("After calling for the first time to count, the count must be 1 but it is %d\n", currentCount)
   }

   var counter2, expectedCounter Singleton
   expectedCounter = counter1
   counter2 = GetInstance()
   if counter2 != expectedCounter {
      t.Error("Expected same instance in counter2 but it got a different instance")
   }

   currentCount = counter2.AddOne()
   if currentCount != 2 {
      t.Errorf("After calling 'AddOne' using the second counter, the current count must be 2 but was %d\n", currentCount)
   }
}

Проблема этой реализации становится сразу очевидна, функция GetInstance и метод AddOne подвержены ошибкам конкурентного доступа.

GetInstance

Первое, что приходит в голову это просто добавить блокировок:

var instance *singleton
var mu sync.Mutex

func GetInstance() Singleton {
   mu.Lock()   
   defer mu.Unlock()
   
   if instance==nil{
      instance = new(singleton)
   }
   return instance
}

И это неплохо работает. Но создаем мы instance всего один раз, а блокировки срабатывают каждый раз.

Так же можно попробовать некоторые варианты “блокировка с двойной проверкой”, но к счастью в стандартной библиотеке Golang есть sync.Once. Ему можно передать функцию, которая будет выполнена не более одного раза:

var instance *singleton
var once sync.Once

func GetInstance() Singleton {
   once.Do(func() {
      instance = new(singleton)
   })

   return instance
}

С GetInstance разобрались, осталось самое интересное.

AddOne и другие методы доступа

Начнем с теста который сможет продемонстрировать проблему:

func TestParallel(t *testing.T) {
   singleton := GetInstance()
   singleton2 := GetInstance()

   n := 5000

   var wg sync.WaitGroup

   for i := 0; i < n; i++ {
      wg.Add(1)
      go func() {
         singleton.AddOne()
         wg.Done()
      }()
      wg.Add(1)
      go func() {
         singleton2.AddOne()
         wg.Done()
      }()
   }

   fmt.Printf("Before loop, current count is %d\n", singleton.GetCount())

   wg.Wait()

   fmt.Printf("Current count is %d\n", singleton.GetCount())

   currentCount1 := singleton.GetCount()
   currentCount2 := singleton2.GetCount()
   if currentCount1 != currentCount2 {
      t.Errorf("Counts not match\nCurrentCount1=%d\nCurrentCount2=%d", currentCount1, currentCount2)
   }

   if currentCount1 != n*2 {
      t.Errorf("Counts not match\nCurrentCount1=%d\nN*2=%d", currentCount1, n*2)
   }
}

Запускаем цикл на 5000 итераций в которых создается по две горутины, в горутинах вызывается метод AddOne. По завершению всех горутин мы ожидаем, что наш счетчик будет иметь значение 5000*2=10к

=== RUN   TestParallel
Before loop, current count is 9499
Current count is 9524
--- FAIL: TestParallel (0.00s)
        main_test.go:68: Counts not match
                CurrentCount1=9524
                N*2=10000

Сразу по окончанию цикла у нас получилось 9499, это неплохо, к этому моменту еще не все горутины закончили свою работу.

А уже по завершению мы получаем счетчик со значением 9524, а это плохо, куда то потерялось целых 476.

Добавляем -race и запускаем:

WARNING: DATA RACE
Read at 0x00c04205e130 by goroutine 9:
  github.com/germangorelkin/go-patterns/creational/singleton/once.(*singleton).AddOne()
      ./github.com/germangorelkin/go-patterns/creational/singleton/once/main.go:26 +0x3f
  github.com/germangorelkin/go-patterns/creational/singleton/once.TestParallel.func2()
      ./github.com/germangorelkin/go-patterns/creational/singleton/once/main_test.go:50 +0x45
Previous write at 0x00c04205e130 by goroutine 8:
  github.com/germangorelkin/go-patterns/creational/singleton/once.(*singleton).AddOne()
      ./github.com/germangorelkin/go-patterns/creational/singleton/once/main.go:26 +0x55
  github.com/germangorelkin/go-patterns/creational/singleton/once.TestParallel.func1()
      ./github.com/germangorelkin/go-patterns/creational/singleton/once/main_test.go:45 +0x45
Goroutine 9 (running) created at:
  github.com/germangorelkin/go-patterns/creational/singleton/once.TestParallel()
      ./github.com/germangorelkin/go-patterns/creational/singleton/once/main_test.go:49 +0x178
  testing.tRunner()
      ./testing/testing.go:777 +0x174
Goroutine 8 (finished) created at:
  github.com/germangorelkin/go-patterns/creational/singleton/once.TestParallel()
      ./github.com/germangorelkin/go-patterns/creational/singleton/once/main_test.go:44 +0x11f
  testing.tRunner()
      ./testing/testing.go:777 +0x174
==================
Before loop, current count is 9988
Current count is 9989
--- FAIL: TestParallel (0.60s)
        main_test.go:68: Counts not match
                CurrentCount1=9989
                N*2=10000
        testing.go:730: race detected during execution of test
FAIL

Получаем DATA RACE.

Data race(“гонка данных”) осуществляется, когда две горутины одновременно обращаются к одной и той же переменной и по крайней мере одно из обращений представляет собой запись. Подробней можно посмотреть в статье Race condition и Data Race.

Существует минимум три способа избежать этой проблемы:

Первый способ — не изменять переменную. Как не странно, но иногда есть возможность отказаться от записи и использовать уже предустановленный набор данных.

Второй способ — использовать взаимное исключение. Для этой цели служит бинарный семафор, он же мьютекс. В Go его можно реализовать через буферизированный канал. Но, к счастью, в стандартной библиотеки уже есть примитивы синхронизации: sync.Mutex и sync.RWMutex.

Внесем корректировки:

import "sync"

type Singleton interface {
   AddOne()
   GetCount() int
}

type singleton struct {
   count int
   sync.RWMutex
}

var instance *singleton
var once sync.Once

func GetInstance() Singleton {
   once.Do(func() {
      instance = new(singleton)
   })

   return instance
}

func (s *singleton) AddOne() {
   s.Lock()
   defer s.Unlock()
   s.count++
}

func (s *singleton) GetCount()int {
   s.RLock()
   defer s.RUnlock()
   return s.count
}

go test -race:

Before loop, current count is 9864
Current count is 10000
PASS

Всё в порядке, всё отлично.

Третий способ — избегать обращения к переменной из нескольких горутин.

Ограничиваем переменную одной горутиной. Другие горутины не могут получить прямой доступ к переменным, они должны использовать каналы для запроса у ограничивающей горутины(“monitor”) получения значения или обновления переменной.

Следуя этому принципам, пробуем реализовать синглетон.

Потребуются три канала:

var addCh chan bool = make(chan bool)
var getCountCh chan chan int = make(chan chan int)
var quitCh chan bool = make(chan bool)

Через канал addCh будем запрашивать обновление переменной. Канал quitCh сигнализирует ограничивающей горутине, что нужно завершить работу и освободить ресурсы.

getCountCh это канал каналов int. Через него можно будет запрашивать значение переменной, значение будет передано обратно через полученный канал. Возможно, это звучит запутано, но на деле это достаточно удобно и требует небольшого усилия, что бы разобраться.

Функция которая будет выступать ограничителем:

go func() {
   for {
      select {
      case <-addCh:
         instance.count++
      case ch := <-getCountCh:
         ch <- instance.count
      case <-quitCh:
         return
      }
   }
}()

Полный код может выглядит таким образом:

import "sync"

var addCh chan bool = make(chan bool)
var getCountCh chan chan int = make(chan chan int)
var quitCh chan bool = make(chan bool)

type Singleton interface {
   AddOne()
   GetCount() int
   Stop()
}

type singleton struct {
   count int
}

var instance *singleton
var once sync.Once

func GetInstance() Singleton {
   once.Do(func() {
      instance = new(singleton)

      go func() {
         for {
            select {
            case <-addCh:
               instance.count++
            case ch := <-getCountCh:
               ch <- instance.count
            case <-quitCh:
               return
            }
         }
      }()
   })

   return instance
}

func (s *singleton) AddOne() {
   addCh <- true
}

func (s *singleton) GetCount() int {
   resCh := make(chan int)
   defer close(resCh)
   getCountCh <- resCh
   return <-resCh
}

func (s *singleton) Stop() {
   quitCh <- true
   close(addCh)
   close(getCountCh)
   close(quitCh)
   instance = nil
}

go test -race:

Before loop, current count is 9824
Current count is 10000
PASS

Benchmark

func BenchmarkChannelSingletonParallel(b *testing.B) {
 singleton := GetInstance()
 singleton2 := GetInstance()
 b.ResetTimer()
 b.RunParallel(func(pb *testing.PB) {
  for pb.Next() {
   singleton.AddOne()
   singleton2.GetCount()
   singleton2.AddOne()
   singleton.GetCount()
  }
 })
}
func BenchmarkChannelSingleton(b *testing.B) {
 singleton := GetInstance()
 singleton2 := GetInstance()
 b.ResetTimer()
 for i := 0; i < b.N; i++ {
  singleton.AddOne()
  singleton2.GetCount()
  singleton2.AddOne()
  singleton.GetCount()
 }
}

Дают такой результат на каналы:

BenchmarkChannelSingletonParallel-4       500000              3441 ns/op             192 B/op          2 allocs/op
BenchmarkChannelSingleton-4               300000              4590 ns/op             192 B/op          2 allocs/op
flat  flat%   sum%        cum   cum%
650ms  9.37%  9.37%      650ms  9.37%  runtime.osyield
470ms  6.77% 16.14%      470ms  6.77%  runtime.stdcall1
400ms  5.76% 21.90%      410ms  5.91%  runtime.addspecial
400ms  5.76% 27.67%      850ms 12.25%  runtime.pcvalue
400ms  5.76% 33.43%      400ms  5.76%  runtime.stdcall2
390ms  5.62% 39.05%      390ms  5.62%  runtime.procyield
360ms  5.19% 44.24%      450ms  6.48%  runtime.step
340ms  4.90% 49.14%     1500ms 21.61%  runtime.gentraceback
290ms  4.18% 53.31%     1150ms 16.57%  runtime.lock
280ms  4.03% 57.35%      880ms 12.68%  runtime.selectgo

И такие на мьютексы:

BenchmarkMutexSingletonParallel-4        3000000               419 ns/op               0 B/op          0 allocs/op
BenchmarkMutexSingleton-4               10000000               207 ns/op               0 B/op          0 allocs/op
flat  flat%   sum%        cum   cum%
690ms 13.12% 13.12%      690ms 13.12%  runtime.procyield
470ms  8.94% 22.05%      950ms 18.06%  runtime.deferreturn
470ms  8.94% 30.99%      470ms  8.94%  runtime.freedefer
460ms  8.75% 39.73%      460ms  8.75%  runtime.newdefer
330ms  6.27% 46.01%      990ms 18.82%  sync.(*Mutex).Lock
310ms  5.89% 51.90%      390ms  7.41%  sync.(*RWMutex).RUnlock
260ms  4.94% 56.84%     1260ms 23.95%  sync.(*RWMutex).Lock
250ms  4.75% 61.60%      320ms  6.08%  sync.(*Mutex).Unlock
230ms  4.37% 65.97%      230ms  4.37%  sync.(*RWMutex).RLock
220ms  4.18% 70.15%      720ms 13.69%  runtime.deferproc

https://github.com/GermanGorelkin/go-patterns/tree/master/creational/singleton