Мьютексы и примитивы синхронизации

sync.Mutex даёт взаимное исключение: только одна goroutine удерживает блокировку одновременно, защищая критическую секцию. Вызовите Lock до секции и Unlock после — обычно через defer. Нулевое значение — это разблокированный, готовый к работе мьютекс.

sync.WaitGroup ждёт завершения набора goroutine. Add(n) повышает внутренний счётчик, каждая goroutine вызывает Done, уменьшая его, а Wait блокируется, пока счётчик не достигнет нуля. Add должен выполниться до запуска goroutine, которую он учитывает.

sync.RWMutex допускает много одновременных читателей RLock ЛИБО одного писателя Lock. Он выигрывает на read-heavy нагрузке, где читателей намного больше писателей. Цена — более тяжёлая блокировка: медленнее sync.Mutex при низкой конкуренции, и ожидающий писатель блокирует новых читателей.

sync предоставляет низкоуровневые примитивы конкурентности: Mutex и RWMutex для взаимного исключения, WaitGroup для ожидания группы горутин, Once для однократной инициализации, Cond для ожидания по условию, Map для конкурентной map и Pool для переиспользования временных объектов. Подпакет sync/atomic добавляет атомарные операции без блокировок.

Состояние гонки (data race) — это две goroutine, одновременно обращающиеся к одной памяти, где хотя бы одна пишет, без синхронизации, что даёт неопределённый результат; ловите его детектором -race и устраняйте через sync.Mutex, канал или atomic. Deadlock — это goroutine, каждая из которых ждёт ресурс, удерживаемый другой, так что ни одна не движется; предотвращайте его согласованным порядком взятия блокировок.

sync.Once.Do(f) выполняет f ровно один раз для всех вызывающих. Он использует атомарный флаг done для дешёвого быстрого пути и мьютекс для медленного: первый вызывающий выполняет f под блокировкой, конкурентные вызывающие ждут её завершения, а поздние вызовы видят флаг и сразу возвращаются.

sync.Map держит две внутренние map — преимущественно читаемую read, обслуживаемую без блокировки через атомики, и dirty под Mutex для записи. Чтение уже присутствующих ключей вовсе обходится без блокировки. Она выигрывает только на read-mostly или write-once-read-many нагрузках; для обычного смешанного чтения/записи обычная map под RWMutex быстрее.

Встроенные map не безопасны для конкурентного доступа. Конкурентные записи аварийно завершают программу с fatal error: concurrent map writes — даже чтение с записью одновременно может упасть. Исправление — защищать каждый доступ sync.Mutex/RWMutex либо использовать sync.Map под конкуренцией.

wg.Add(1) вызывается внутри горутины, но планировщик может не запустить ни одну горутину до того, как main дойдёт до wg.Wait(). Если Wait видит нулевой счётчик, он сразу возвращается, и программа может выйти до запуска горутин. Исправление — вызывать wg.Add(1) в цикле перед запуском каждой горутины.

sync.Mutex — локальная переменная, поэтому каждый вызов блокирует свою копию, а общий cache ничем не защищён — конкурентные вызовы гоняются и падают с fatal error: concurrent map writes. Ещё value = cache[key] перезаписывает аргумент, поэтому путь создания сохраняет "", а снятие блокировки между чтением и записью делает get-or-create неатомарным. Исправление: один общий замок — RWMutex, раз чтений больше, — удерживаемый на всём check-then-set, и не затирать value.

RWMutex в Go не реентрантен. A держит read-блокировку и вызывает B, который запрашивает write-Lock. Если другая горутина уже ждёт Lock, runtime блокирует новых читателей, чтобы избежать голодания писателя — поэтому B ждёт read-блокировку, которую всё ещё держит A. Документация запрещает рекурсивный RLock; берите блокировку один раз на верхнем уровне.

В mu &sync.RWMutex{} пропущен := — нужно mu := &sync.RWMutex{}. В остальном дисциплина блокировок верна: updater переприсваивает rates под Lock, хендлеры читают под RLock, поэтому каждый доступ защищён. Проверку != http.ErrServerClosed на ListenAndServe оставьте.

Храните записи в map с ключом User.ID, у каждой — момент истечения, под защитой sync.RWMutex. Set пишет значение и now+ttl под Lock; Get берёт RLock и считает запись с истёкшим сроком промахом. Фоновая goroutine-чистильщик выметает истёкшие ключи, чтобы нетронутые записи не оставались; метод Close останавливает её, чтобы она не утекала.