Потому что это быстро. x4982 сокращение использования памяти и хранилища с помощью тестов ниже.
Ok. Что за черт?
Сборщик мусора запускается через определенные промежутки времени. Если ваш код постоянно выделяет память в некоторых структурах данных, а затем освобождает их, это требует постоянной работы сборщика, большего использования памяти и ЦП для выделения ресурсов в структурах инициализации.
The comments on sync/pool.go say that: A Pool is a set of temporary objects that may be individually saved and retrieved. A Pool is safe for use by multiple goroutines simultaneously.
sync.Pool позволяет нам повторно использовать память без выделения.
Также, если у вас есть http-сервер, который ожидает почтовых запросов с телом json и должен декодировать в структуру, вы можете использовать sync.Pool для экономии памяти и сокращения времени ответа сервера.
синхронизация использования пула
sync.Pool конструкция проста:
var bufferPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
Теперь у вас есть пул, который будет создаваться, и новые буферы. Вы можете получить свой первый буфер здесь:
buffer := bufferPool.Get().(*bytes.Buffer)
Метод get вернет уже существующий * bytes.Buffer в пуле, и если он не вызовет метод New, который инициирует новые * байты .Buffer
Но после использования буфера вы должны сбросить его и вернуть в пул:
buffer.Reset() bufferPool.Put(buffer)
Бенчмаркинг
Кодирование json в bytes.Buffer
// That code tried to json encode structure BenchmarkReadStreamWithPool-8 5000000 384 ns/op 0 B/op 0 allocs/op BenchmarkReadStreamWithoutPool-8 3000000 554 ns/op 160 B/op 2 allocs/op
У нас есть прирост производительности на 44% и очень большая экономия памяти (160 бит / с по сравнению с 0 бит / с)
Запись байтов в bufio.Writer
BenchmarkWriteBufioWithPool-8 10000000 123 ns/op 128 B/op 2 allocs/op BenchmarkWriteBufioWithoutPool-8 2000000 651 ns/op 4288 B/op 4 allocs/op
У нас есть увеличение производительности в 5 раз и уменьшение использования памяти в 32 раза
Расшифровка json в структуру
BenchmarkJsonDecodeWithPool-8 1000000 1729 ns/op 1128 B/op 8 allocs/op BenchmarkJsonDecodeWithoutPool-8 1000000 1751 ns/op 1160 B/op 9 allocs/op
У нас есть прирост производительности на 1%, потому что декодирование json - это слишком сложная операция, и мы не видим нормального повышения за счет повторного использования структур.
Gzip байт
BenchmarkWriteGzipWithPool-8 500000 2339 ns/op 162 B/op 2 allocs/op BenchmarkWriteGzipWithoutPool-8 10000 105288 ns/op 807088 B/op 16 allocs/op
Стоп что? x45 повышение производительности и x4982 сокращение использования памяти
Заключение
По возможности всегда используйте sync.Pool! Это действительно экономит память и увеличивает производительность вашего приложения.
Репозиторий Github с тестами здесь.
📝 Прочтите этот рассказ позже в Журнале.
👩💻 Просыпайтесь каждое воскресное утро и слушайте самые интересные истории из области технологий, ожидающие вас в вашем почтовом ящике. Прочтите информационный бюллетень« Примечательно в технологиях .
