Производительность Go: как профилировать и ускорять код

Ваш Go-код работает медленно? Пора заглянуть под капот

Вы написали сервис на Go. Он работает. Но когда нагрузка достигает 10 000 RPS, сервер начинает «задыхаться». Знакомая ситуация? Go славится своей производительностью «из коробки», но даже в этом элегантном языке есть свои подводные камни. Утечки горутин, неэффективное управление памятью, лишние аллокации — всё это убивает скорость.

В этой статье мы разберём, как профилирование Go помогает найти узкие места, и покажем конкретные техники оптимизации Go-приложений. Вы узнаете, как с помощью встроенных инструментов pprof и go test -bench превратить ваше приложение в ракету. Поехали!

Инструментарий профилировщика: pprof и trace

Go предоставляет два мощных инструмента для анализа производительности: pprof (профилирование CPU, памяти, блокировок) и go tool trace (анализ конкурентности и событий GC).

Встраиваем pprof в HTTP-сервер

Самый простой способ начать профилирование — добавить net/http/pprof в ваш сервер. Это займёт ровно одну строку импорта:

import (
    _ "net/http/pprof"
    "net/http"
)

func main() {
    http.ListenAndServe(":8080", nil)
}

Теперь по адресу /debug/pprof/ доступны профили. Чтобы снять профиль CPU на 30 секунд, выполните:

go tool pprof http://localhost:8080/debug/pprof/profile?seconds=30

После сбора данных запустится интерактивная консоль. Команда top15 покажет самые горячие функции:

(pprof) top15
Showing nodes accounting for 3.50s, 87.50% of 4.00s total
      flat  flat%   sum%        cum   cum%
     1.20s 30.00% 30.00%      1.50s 37.50%  main.heavyComputation

Видите main.heavyComputation? Это наш кандидат на оптимизацию. Для визуализации используйте web (если установлен Graphviz) — вы получите граф вызовов.

Профилирование памяти: ищем утечки

Утечки памяти в Go — это чаще всего утечки горутин или забытые ссылки на большие объекты. Снимем heap-профиль:

go tool pprof http://localhost:8080/debug/pprof/heap

Команда alloc_objects покажет, какие функции создают больше всего объектов:

(pprof) alloc_objects
    2.50GB  100%  100%      2.50GB  100%  main.createLargeSlice

Вот так мы нашли функцию, которая выделяет 2.5 ГБ памяти! Возможно, там создаётся огромный слайс, который можно переиспользовать с помощью sync.Pool.

Написание бенчмарков: ваш первый шаг к оптимизации

Прежде чем оптимизировать, нужно измерить. Go-бенчмарки — это стандартный инструмент для замера производительности отдельных функций.

Пример: сравниваем конкатенацию строк

Допустим, мы склеиваем строки в цикле. Плохой вариант:

func ConcatSlow(parts []string) string {
    result := ""
    for _, p := range parts {
        result += p
    }
    return result
}

Хороший вариант — использовать strings.Builder:

func ConcatFast(parts []string) string {
    var b strings.Builder
    for _, p := range parts {
        b.WriteString(p)
    }
    return b.String()
}

Напишем бенчмарк (файл concat_test.go):

func BenchmarkConcatSlow(b *testing.B) {
    parts := []string{"Hello", " ", "World", "!", " ", "From", " ", "Go"}
    for i := 0; i < b.N; i++ {
        ConcatSlow(parts)
    }
}

func BenchmarkConcatFast(b *testing.B) {
    parts := []string{"Hello", " ", "World", "!", " ", "From", " ", "Go"}
    for i := 0; i < b.N; i++ {
        ConcatFast(parts)
    }
}

Запускаем:

go test -bench=. -benchmem

Результат:

BenchmarkConcatSlow-8   12345678   98.5 ns/op   48 B/op   6 allocs/op
BenchmarkConcatFast-8   23456789   32.1 ns/op   24 B/op   2 allocs/op

Разница в 3 раза по скорости и в 2 раза по памяти! Флаг -benchmem показывает количество аллокаций — ключевая метрика для оптимизации Go-кода.

Escape analysis: куда улетают ваши объекты?

Одна из главных причин медленного кода — объекты, которые «убегают» из стека в кучу (heap). Аллокации на куче дорогие, они создают нагрузку на GC. Go компилятор решает, где разместить переменную, с помощью escape analysis.

Как проверить, что улетает в кучу?

Используйте флаг компилятора -gcflags="-m":

go build -gcflags="-m -m" ./... 2>&1 | grep "escapes"

Рассмотрим пример:

func CreateUser() *User {
    u := User{Name: "Alice"}
    return &u // улетает в кучу!
}

Компилятор скажет: moved to heap: u. Решение — возвращать значение, а не указатель, если объект небольшой:

func CreateUser() User {
    return User{Name: "Alice"} // остаётся на стеке
}

Практический совет: избегайте интерфейсов

Когда вы передаёте конкретный тип через интерфейс, компилятор часто не может доказать, что объект останется на стеке. Сравните:

// Плохо: через интерфейс
func Process(r io.Reader) { ... }

// Хорошо: конкретный тип
func Process(r *os.File) { ... }

Если интерфейс неизбежен (например, для тестирования), используйте io.Reader с осторожностью.

Оптимизация горутин и каналов

Go — язык конкурентности, но неправильное использование горутин может убить производительность. Две главные проблемы: утечки горутин и неправильный размер буфера каналов.

Утечки горутин: как обнаружить

Горутина «утекает», если она заблокирована навсегда (например, ждёт данные из канала, который никто не закроет). Используйте профилировщик горутин:

go tool pprof http://localhost:8080/debug/pprof/goroutine

Команда