Библиотека Go для собеса | вопросы с собеседований

❓ Как в Lock-Free алгоритмах борются с бесконечными повторными попытками Когда несколько потоков одновременно «крутят» CAS, часть из них может подолгу проваливать попытки и впустую жечь процессор. Чтобы этого избежать, применяют несколько приёмов: • Экспоненциальный бэкофф. Перед следующей попыткой CAS поток выжидает интервал, увеличивая его с каждой неудачей (обычно со случайным разбросом, чтобы потоки не синхронизировались). Это снижает конкуренцию и нагрузку на CPU. • Адаптивные алгоритмы. Поведение потоков подстраивается под метрики системы — уровень контеншена, загрузку процессора — и стратегия ожидания меняется на лету. • Ограничение по времени/попыткам (timed wait). Если CAS не удаётся за отведённое число попыток или время, поток прекращает спин и переходит на fallback-путь. • Гибридный подход (hybrid locking). В качестве резерва подключаются мьютексы или другие блокирующие примитивы, когда неблокирующий путь себя не оправдывает. Итог: цель всех этих механизмов — превратить «бесконечный спин» в контролируемое ожидание и не дать потокам молотить процессор вхолостую. 🐸 Библиотека Go для собеса

❓ Что особенного в chan struct{} chan struct{} — это канал, по которому передаётся не данные, а сам факт сигнала. Пустая структура struct{} не занимает памяти (0 байт), поэтому такой канал явно говорит читателю кода: «здесь важно только событие, а не его содержимое». Типичные сценарии: • Сигнал завершения / отмены. Закрытие канала (close(done)) разом оповещает всех, кто его слушает. • Синхронизация горутин. Одна горутина ждёт, пока другая пошлёт сигнал ch <- struct{}{}. • Семафоры и ограничение параллелизма, где важен сам факт занятости слота, а не передаваемое значение. done := make(chan struct{}) go func() { // ... работа ... close(done) // сигнализируем о завершении }() <-done // ждём сигнал Почему именно struct{}, а не, например, chan bool: булев канал намекает, что значение (true/false) несёт смысл, хотя на деле его игнорируют. chan struct{} выражает намерение точнее — «данных нет, есть только событие» — и не тратит память на само значение. 🐸 Библиотека Go для собеса

❓ Что будет, если вызвать time.Sleep(0) Вопреки распространённому мифу — практически ничего. time.Sleep с длительностью ≤ 0 сразу возвращает управление: горутина не «усыпляется» и не уступает планировщику. По сути это no-op. Часто думают, что time.Sleep(0) отдаёт управление планировщику Go и позволяет переключиться на другие горутины. Но за это отвечает другая функция: runtime.Gosched() // вот это уступает управление планировщику Gosched() снимает текущую горутину с процессора и ставит в очередь, давая шанс другим. А time.Sleep(0) этого не делает — если нужен именно yield, используйте runtime.Gosched(). 🐸 Библиотека Go для собеса

❓ Что делает CGO_ENABLED CGO_ENABLED — это переменная окружения, которая включает или выключает CGo при сборке Go-приложений. Принимает два значения: 1 (включено) и 0 (выключено). CGo — это механизм, позволяющий Go-коду взаимодействовать с C: вызывать C-функции и использовать C-библиотеки прямо из Go-программы. Зачем этим управлять: • CGO_ENABLED=0 даёт полностью статический бинарник без зависимостей от системных C-библиотек — удобно для минимальных Docker-образов (scratch, alpine) и упрощает кросс-компиляцию. • CGO_ENABLED=1 нужен, когда проект реально использует C-код или библиотеки, завязанные на cgo CGO_ENABLED=0 GOOS=linux go build -o app Важный нюанс: по умолчанию CGo включён, но при кросс-компиляции (когда GOOS/GOARCH отличаются от хостовых) Go автоматически отключает его, если не задан C-кросс-компилятор. 🐸 Библиотека Go для собеса

❓ Объясните разницу между безопасным доступом к байтам строки через срез и использованием unsafe Когда строку преобразуют в срез байтов, создаётся новая копия данных, и доступ к этим данным безопасен, но это также означает, что данные строки не изменяются. unsafe позволяет работать с указателями и памятью напрямую, что даёт больше гибкости, но это также приводит к неопределённому поведению, если использовать эти указатели для изменения данных. 🐸 Библиотека Go для собеса

❓ Какой максимальный размер бинарного файла можно собрать В Go нет встроенного ограничения на размер бинарника. Теоретический предел это ресурсы машины, на которой идёт компиляция: свободное место на диске и доступная память. Размер бинарника растёт из-за нескольких вещей: Статическая линковка. Go по умолчанию собирает всё в один файл — рантайм, стандартная библиотека, все зависимости. Никаких внешних .so или .dll. Это удобно при деплое, но увеличивает размер даже у простой программы. Встроенные ресурсы. Через //go:embed можно упаковать в бинарник статику, шаблоны, миграции. Добавили папку с фронтендом — бинарник вырос на её размер. Отладочная информация. По умолчанию Go включает в бинарник DWARF-символы и таблицы имён. Это нужно для профилировщика и стектрейсов, но добавляет вес. Если размер важен, его можно уменьшить флагами линковщика: go build -ldflags="-s -w" -o app . -s убирает таблицу символов, -w отключает DWARF. Бинарник становится меньше на 20–30%, но отладка по нему будет затруднена. Дополнительно можно прогнать через upx — утилита сжимает исполняемый файл, он распаковывается уже в памяти при запуске. 🐸Библиотека Go для собеса