Redis обрабатывает команды в одном потоке — и при этом отдаёт сотни тысяч операций в секунду. Разбираем, почему single-threaded не значит медленно: событийный цикл, I/O-мультиплексирование, threaded I/O в новых версиях, пайплайнинг. И честно про обратную сторону: где один поток становится узким местом и откуда берётся хвостовая latency.
Go 1.27 добавил профиль утёкших горутин — он выделяет именно те, что навсегда заблокированы на примитиве синхронизации. Что новый профиль видит, чего не видят pprof/goroutine и goleak, на воспроизводимых классах утечек, и как встроить его в мониторинг.
Flaky-тест не «случайный» — у каждого мигания детерминированная причина: гонка, время, порядок выполнения, обход map, sleep вместо синхронизации. Разбираем пять классов на живом Go-стенде с реальной частотой мигания и настоящим детектором гонок, чиним каждый детерминизмом — а не ретраями
Как ловить конкурентные баги в Go: race detector по-настоящему (как читать отчёт, оверхед, место в CI), поиск утечек горутин через goleak и pprof, дедлоки и встроенный детектор, профили блокировок и мьютексов
Рабочие паттерны конкурентности в Go: pipeline с отменой и очисткой, fan-in/fan-out, worker pool с ограничением параллелизма, semaphore, errgroup, singleflight и батчинг — и когда паттерн лишний
Что на самом деле гарантирует модель памяти Go: отношение happens-before, публикация данных через каналы, мьютексы и атомики, переупорядочивание операций и почему гонка данных делает программу некорректной — модель памяти перестаёт давать нужные гарантии, а не просто «изредка возвращает неверное значение»
Когда каналов мало: Mutex и RWMutex (и почему RW не всегда быстрее), Once, Cond, WaitGroup, sync.Map и sync.Pool, атомарные операции и их семантика — с честным разбором цены контеншена и false sharing
Как в Go на самом деле устроена конкурентность: дешёвые горутины и M:N-планировщик, каналы против мьютексов, context для отмены, рабочие паттерны (worker pool, fan-in/out, pipeline) и типичные подводные камни — гонки, утечки горутин и дедлоки
Reactive-стек на JVM после Loom: как работает Project Reactor и WebFlux, что даёт backpressure, и честный ответ на вопрос, когда virtual threads делают reactive ненужным, а когда нет
Три модели конкурентности на JVM: virtual threads (Loom), корутины Kotlin и reactive (Project Reactor) — как они устроены, чем платят и когда какая уместна
