👣 "Leak and Seek: A Go Runtime Mystery" на сайте Cyolo описывает расследование команды разработчиков, направленное на выявление и устранение утечки памяти в приложении, написанном на языке программирования Go.

Несмотря на то, что Go использует сборку мусора для управления памятью, команда столкнулась с необычной утечкой, связанной с объектами SqliteRows, SqliteStmt и SqliteConn.​


Основные моменты статьи:
- Начало расследования: После сообщений от нескольких крупных клиентов о значительных проблемах с производительностью, команда начала собирать профили памяти и горутин, чтобы определить источник утечки.​

- Исключение горутин: Анализ показал отсутствие накопления активных горутин, что позволило исключить утечки, связанные с ними.​

- Обнаружение проблемы в драйвере SQLite3: График распределения объектов в памяти указал на утечку, связанную с драйвером SQLite3, используемым в приложении.​

- Анализ финализаторов: Команда обнаружила, что недавно добавленный финализатор для SqliteRows может вызывать блокировку единственной горутины, ответственной за выполнение всех финализаторов в Go. Это приводило к накоплению неосвобожденных объектов и, как следствие, к утечке памяти.​
Cyolo

- Использование инструмента goref: Для дальнейшего анализа команда применила инструмент goref, позволяющий картировать граф ссылок объектов в куче, что подтвердило отсутствие живых объектов, удерживающих утекшие данные, и указало на проблему в самом рантайме Go.​

- Обнаружение блокировки в go-smb2: В конечном итоге было выявлено, что блокировка в пакете go-smb2 приводила к остановке горутины финализатора, что вызывало утечку памяти.​
Cyolo

- Результаты и рекомендации: Команда сообщила о найденной проблеме сообществу Go, предложив улучшить документацию по финализаторам и внедрить метрики для обнаружения медленных или заблокированных очередей финализаторов.​

Статья подчеркивает важность тщательного анализа и командной работы при решении сложных проблем в программировании, а также необходимость понимания внутренних механизмов используемого языка и его инструментов.

📌 Читать

👣 «Карты конкурентности в Go» автор предлагает оригинальный подход к обучению конкурентному программированию в Go, используя метафору карточной игры.

Каждая "карта" представляет собой ключевую концепцию или инструмент, связанный с конкурентностью в Go.​

🃏 Основные "карты" конкурентности в Go
Горутины (goroutines): Лёгкие потоки, позволяющие выполнять функции параллельно.​

Каналы (channels): Средство коммуникации между горутинами, обеспечивающее безопасный обмен данными.​

Селекторы (select): Позволяют горутине ждать нескольких операций с каналами одновременно.​

Мьютексы (mutexes): Механизм синхронизации, предотвращающий одновременный доступ к общим ресурсам.​

Пулы воркеров (worker pools): Шаблон для управления группой горутин, выполняющих задачи из общей очереди.​

Автор подчеркивает важность понимания этих концепций для эффективного использования конкурентности в Go. Он также обсуждает типичные ошибки и подводные камни, такие как гонки данных и блокировки, и предлагает стратегии их избегания.​

Статья рекомендуется для разработчиков, стремящихся углубить свои знания в области конкурентного программирования на Go.

▪ Читать

👣 Как одной Go‑службе легко выдержать 200000 RPS на одной машине

В свежей статье Никиты Бурова разбирается практический кейс: без шардирования, без десятков реплик и без магии облака — всего за счёт правильных оптимизаций Go‑сервис на одном MacBook Pro M3 достигает 200000 запросов в секунду с медианным P50 < 1 мс. Вот главные приёмы:

1⃣ Сводим работу «горячего» пути к минимуму
- Статический преподготовленный фид — из памяти, без БД/API.
- Ноль аллокаций — никаких new/make в горячем пути.

2⃣ net/http → fasthttp
- Быстрее TCP, буферы, заголовки.
- ×8–10 прирост RPS.

3⃣ Pool объектов + явный сброс
- sync.Pool для структур.
- Отказ от defer.

4⃣ Tюнинг GOMAXPROCS + GOGC
- GOMAXPROCS= ядра.
- GOGC=200–300.

5⃣ Профилирование pprof benchstat

Результат: один инстанс держит 200000 RPS с P50 < 1мс и P99 < 2мс.

🔗 Полная статья: https://medium.com/@nikitaburov/how-to-easily-handle-200k-rps-with-golang-8b62967a01dd

👣 Без излишеств: изящная архитектура Go‑проекта

Как часто вы ловите себя на вопросе: «Как лучше организовать структуру репозитория Go‑проекта?» В беседах на Gopher Slack и телеграм чатах подобные вопросы возникают вновь и вновь.

Впрочем, в сети так много устаревших или чрезмерно запутанных гайдов, что порой сложно найти по-настоящему удручающе простое решение.

Одна из краеугольных идей философии Go — стремление к максимальной простоте.

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

Что говорит официальная документация
На сайте go.dev можно найти рекомендации от авторов языка:

«В больших проектах или монолитных приложениях бывает полезно вынести часть функциональности в поддерживающие пакеты, помещая их в каталог internal. Код внутри internal/ недоступен для стороннего импорта, что позволяет нам без опасений рефакторить API и перестраивать структуру».

Заметьте, слова — «больших» и «бывает» — подчёркнуты не случайно.

Большинству небольших или средних проектов вовсе не нужен internal/: достаточно просто не экспортировать те функции, которые не предназначены для внешнего использования.

Идея «сначала создайте internal/, потом думайте о дизайне» кажется чрезмерной. Но зачастую, разумнее сперва выпустить полезный функционал, а уже потом, по мере роста проекта, скорректировать структуру.

Что не стоит копировать вслепую
Наверняка вы слышали о репозитории «golang-standards/project-layout», который многие называют «стандартом». На деле это скорее набор идей, вокруг которых бурно дискутируют, нежели непреложное правило.

Не позволяйте чужим конвенциям диктовать ваш рабочий процесс: возможность импортировать из internal/ или раскладывать всё по папкам cmd/, pkg/ и т. д. — далеко не обязательный шаблон для каждого проекта.

Рекомендации из практики
Пакет main
Если ваш проект — это одно единственное приложение, вполне логично держать main.go в корне. Команда

go install github.com/you/project@latest

сработает без лишних телодвижений. Если же вы развиваете и библиотеку, и отдельный исполняемый файл, можно вынести main в подпапку (например, app/) — но не более того.

Каталог internal/
Применяйте его лишь в том случае, когда ваш код действительно потребляют десятки сторонних проектов. Для большинства библиотек и приложений довольно размещать «внутренние» пакеты там, где они логически принадлежат, просто не экспортируя нежелательные символы.

Каталог pkg/
Когда-то pkg/ помогал отделять библиотеки от «прочего» кода. Теперь, после появления internal/, он утратил былую нужность. Любой пакет из pkg/ можно без труда перенести в корень, не нарушив логику проекта.

Утилиты util/, common/, shared/
«Утильные» каталоги зачастую превращаются в свалку беспорядочных функций. Лучше дать такому набору ясное название или разместить функции непосредственно рядом с их точкой использования.

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

Примеры
🔸 github.com/fortio/ — сервер, библиотеки и CLI в одном репозитории

🔸 github.com/fortio/proxy — отдельный HTTP‑прокси

🔸 github.com/fortio/multicurl — консольный инструмент

🔸 github.com/fortio/terminal — два пакета + CLI

🔸 github.com/grol-io/grol — Go с WebAssembly

Сосредоточтесь на действительно важных вещах — написании кода.

👣 “Cheating the Reaper in Go” от Miguel Young

В этой подробной статье автор показывает, как «обмануть» сборщик мусора Go и создать свой собственный arena-аллокатор на чистом Go, получая существенный прирост производительности.

📌 Что внутри:
- Краткий обзор GC Go: как используются pointer bits и shapes для точного сбора мусора.

- Реализация простого bump-аллокатора Arena, сводящего Alloc к смещению указателя.

- Бенчмарки: до 2×–4× ускорения при малых аллокациях и почти 7× для массивов из 64 элементов ( arena – 7370 MB/s vs new – 2865 MB/s )
mcyoung.xyz
.

- Оптимизация через sync.Pool и финализаторы для повторного использования и ускоренного обнуления памяти.

- Безопасный метод Reset() для мгновенной очистки арены без дорогостоящего выделения заново.

Заготовка примитивного Realloc(), позволяющая расширять последние аллокации «на месте».

Полный код, подробное объяснение и советы по дальнейшим оптимизациям — по ссылке:
https://mcyoung.xyz/2025/04/21/go-arenas/

@golang_books

👣 Graceful Shutdown in Go

Любое приложение должно при завершении работы:

1. Закрыть точку входа (HTTP-сервер, очередь сообщений и т.д.), но сохранить исходящие соединения (БД, кэш) активными.
2. Дождаться окончания всех текущих запросов, и при превышении допустимого времени вернуть корректную ошибку.
3. Освободить критические ресурсы (соединения с БД, файловые блокировки, слушатели). :contentReference[oaicite:0]{index=0}

## 1. Обработка сигналов

В Unix-системах сигналы (`SIGTERM`, SIGINT, SIGHUP`) — это программные прерывания, уведомляющие процесс о необходимости завершения или перезагрузки конфигурации. По умолчанию Go-рантайм ловит многие сигналы, но для «мягкой» остановки обычно интересуют только `SIGTERM и SIGINT. :contentReference[oaicite:1]{index=1}

func main() {
    // 1) Создаем канал для сигналов
    signalChan := make(chan os.Signal, 1)
    signal.Notify(signalChan, syscall.SIGINT, syscall.SIGTERM)

    // 2) Запускаем сервер и другую работу здесь...

    // 3) Ждем сигнала
    <-signalChan
    fmt.Println("Received termination signal, shutting down…")
}

2. Таймаут для завершения
В Kubernetes по умолчанию даётся 30 секунд на грациозную остановку (terminationGracePeriodSeconds). Хорошей практикой является резервирование 20 % времени (примерно 6 секунд) на «подстраховку» завершения.

timeout := 25 * time.Second
ctx, cancel := context.WithTimeout(context.Background(), timeout)
defer cancel()

if err := server.Shutdown(ctx); err != nil {
    log.Fatalf("Server forced to shutdown: %v", err)
}

3. Остановка приёма новых запросов
Метод http.Server.Shutdown закрывает слушатели и не принимает новые соединения, при этом дожидаясь окончания активных хэндлеров. Однако в контейнеризированных окружениях нужно сначала «провалить» readiness-пробу, чтобы снять под из балансировщика, и только затем вызывать Shutdown.
VictoriaMetrics

var shuttingDown atomic.Bool

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    if shuttingDown.Load() {
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }
    w.WriteHeader(http.StatusOK)
})

// При получении сигнала:
shuttingDown.Store(true)
// Ждем несколько секунд, пока traffic прекратится
time.Sleep(5 * time.Second)
server.Shutdown(ctx)

4. Обработка активных запросов
После вызова Shutdown(ctx) сервер ждет либо завершения всех соединений, либо истечения контекста. Чтобы уведомить свои хэндлеры о «скоро закрытии», используйте контекст:

a) Middleware с каналом отмены

func WithGracefulShutdown(next http.Handler, cancelCh <-chan struct{}) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        ctx, cancel := WithCancellation(r.Context(), cancelCh)
        defer cancel()
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

b) BaseContext для всего сервера

ongoingCtx, cancelFn := context.WithCancel(context.Background())
server := &http.Server{
    Addr:        ":8080",
    Handler:     yourHandler,
    BaseContext: func(_ net.Listener) context.Context { return ongoingCtx },
}
// После готовности к остановке:
cancelFn()
VictoriaMetrics

5. Освобождение ресурсов
Не закрывайте ресурсы сразу при получении сигнала — хэндлеры могут ими ещё пользоваться. Лучше дождаться окончания работы (или таймаута), а затем в обратном порядке инициализации вызвать Close. Стандартный приём в Go — defer:

db := connectDB()
defer db.Close()

cache := connectCache()
defer cache.Close()

ОС сама освободит память и файловые дескрипторы при завершении процесса, но для внешних систем (БД, брокеры сообщений) рекомендуются явные Close()/Flush() для корректного завершения транзакций и избежания потерь данных.
VictoriaMetrics

➡️ Таким образом, грациозная остановка Go-приложения сводится к трём шагам:

- Ловим нужные сигналы и переключаемся на собственную логику.
- Останавливаем приём новых запросов через Shutdown и/или провал readiness-пробы.
- Ждём завершения активных запросов в пределах таймаута и закрываем ресурсы в обратном порядке.

@golang_books

📚 Организация middleware в Go без сторонних зависимостей

Если ты пишешь веб-приложения на Go и хочешь избавиться от внешних зависимостей вроде alice, статья от Алекса Эдвардса — must read:
https://www.alexedwards.net/blog/organize-your-go-middleware-without-dependencies

📌 В чем суть:

• Проблема: стандартная библиотека Go не даёт удобного способа цепочечного подключения middleware
• Цель: избежать дублирования кода и сделать middleware масштабируемыми без сторонних пакетов

💡 Решение — создать собственный тип chain, который позволяет «наматывать» middleware на обработчики:

type chain []func(http.Handler) http.Handler

func (c chain) then(h http.Handler) http.Handler {
    for i := len(c) - 1; i >= 0; i-- {
        h = c[i](h)
    }
    return h
}

func (c chain) thenFunc(h http.HandlerFunc) http.Handler {
    return c.then(h)
}

Теперь ты можешь описывать цепочки middleware так:

mux := http.NewServeMux()

baseChain := chain{requestID, logRequest}
adminChain := append(baseChain, authenticateUser, requireAdminUser)

mux.Handle("GET /", baseChain.thenFunc(home))
mux.Handle("GET /admin", adminChain.thenFunc(showAdminDashboard))

Этот подход:
• Простой
• Без зависимостей
• Легко расширяется

Полная статья и объяснения тут:

@golang_books

✅ Beelzebub Honeypot - платформа для анализа киберугроз, специализирующуюся на выявлении и изучении криптоджекинга — скрытого майнинга криптовалюты на чужих устройствах без ведома владельцев.

🔍 Как работает Beelzebub Honeypot
Beelzebub — это низкокодовая honeypot-фреймворк, позволяющая быстро развернуть ловушки для киберпреступников. Особенность проекта — интеграция с моделью GPT-4o, что обеспечивает реалистичное поведение системы и привлекает злоумышленников для более глубокого анализа их действий.

💰 Исследование криптоджекинга
В рамках одного из экспериментов Beelzebub была зафиксирована атака, при которой злоумышленник использовал вредоносное ПО для:

- Удаления конкурирующих майнеров с системы жертвы.

- Установки собственного майнера xmrig через скрипт с сервера c3pool.org.
beelzebub-honeypot.com

- Майнинга криптовалюты Monero (XMR) на свой кошелек.


За короткий период злоумышленнику удалось добыть 20 XMR, что эквивалентно примерно $4126.

🛡️ Противодействие угрозам
После обнаружения атаки команда Beelzebub:

- Заблокировала вредоносный кошелек в пуле c3pool.
beelzebub-honeypot.com

- Удалили все связанные с ним майнеры, предотвращая дальнейшее распространение угрозы.

📌 Основные преимущества Beelzebub
Быстрая настройка honeypot-серверов через YAML-конфигурации.

- Интеграция с LLM (GPT-4o) для реалистичного взаимодействия с атакующими.

- Открытый исходный код и активное сообщество разработчиков.

- Поддержка различных протоколов (SSH, HTTP, TCP) и интеграция с Docker и Kubernetes.

Beelzebub Honeypot — мощный инструмент для специалистов по кибербезопасности, позволяющий не только выявлять, но и глубоко анализировать современные угрозы, такие как криптоджекинг, и эффективно им противодействовать.

https://beelzebub-honeypot.com/blog/how-cybercriminals-make-money-with-cryptojacking/