cmd.SysProcAttr = &syscall.SysProcAttr{
    // Запустить потомка под другим пользователем (сброс привилегий).
    Credential: &syscall.Credential{Uid: 1000, Gid: 1000},

    // Новая группа процессов — чтобы можно было убить всё дерево разом.
    Setpgid: true,

    // Отправить SIGKILL потомку, если РОДИТЕЛЬ умрёт (защита от сирот).
    Pdeathsig: syscall.SIGKILL,

    // САМОЕ ИНТЕРЕСНОЕ: новые namespaces. Это основа контейнеров (часть XII).
    Cloneflags: syscall.CLONE_NEWNS | // новое пространство монтирования
        syscall.CLONE_NEWPID | // новое пространство PID — потомок станет PID 1
        syscall.CLONE_NEWNET | // новый сетевой стек
        syscall.CLONE_NEWUTS,  // свой hostname
}

Одно поле Cloneflags превращает os/exec в примитивный container runtime — мы этим воспользуемся в части XII, чтобы написать docker run в тридцать строк.

5.5 Зомби, сироты и waitpid

Когда процесс завершается, он не исчезает мгновенно. Ядро сохраняет его «огрызок» — код возврата и статистику — до тех пор, пока родитель не заберёт эту информацию через wait/waitpid. Процесс в этом состоянии называется зомби (zombie, Z в выводе ps). Зомби не потребляет ресурсов, кроме одной записи в таблице процессов, — но если родитель никогда не делает wait, зомби копятся и в итоге исчерпывают таблицу процессов (нельзя создать новый процесс — EAGAIN).

Мораль: на каждый запущенный процесс должен быть свой Wait. В os/exec это cmd.Wait() (или cmd.Run(), который включает Wait). Забыли Wait после Start — сделали зомби.

Обратная ситуация — сирота (orphan): родитель умер раньше потомка. Такого потомка «усыновляет» init (PID 1), который регулярно делает wait и подчищает зомби. В контейнерах это важная деталь: если ваш процесс — PID 1 в контейнере, вы становитесь этим «усыновителем» и обязаны подчищать чужих зомби (иначе они копятся). Поэтому в контейнеры часто ставят крошечный init вроде tini.

// Идиома «запустить и не ждать» с корректной уборкой:
cmd := exec.Command("worker")
cmd.Start()
go func() {
    cmd.Wait() // в отдельной горутине — заберём статус, не создадим зомби
}()

5.6 Демонизация и почему в Go она не такая, как в C

В классическом C демон (фоновый сервис) создаётся ритуалом: fork (родитель выходит), setsid (новая сессия, отвязка от терминала), второй fork, chdir("/"), закрытие 0/1/2, перенаправление в /dev/null. Всё это — чтобы процесс пережил закрытие терминала и не имел управляющего tty.

В Go этот ритуал не работает — из-за проблемы fork из 5.2 (многопоточность рантайма). Поэтому в Go-мире демонизацию не делают внутри программы. Вместо этого:

• Полагаются на систему инициализации (systemd, runit, s6). Ваша программа остаётся обычным foreground-процессом, пишет логи в stdout/stderr, а systemd сам делает её сервисом, отвязывает от терминала, перезапускает при падении, собирает логи в journald. Это современный и правильный путь.
• Если демонизация всё же нужна без systemd, программа перезапускает сама себя через os/exec с нужными атрибутами (Setsid: true), а первый экземпляр выходит. Существуют библиотеки-хелперы, но по сути они делают именно это.

Философски это отражает сдвиг: раньше программа сама заботилась о своей «фоновости», теперь это ответственность оркестратора (systemd на хосте, Kubernetes в кластере). Ваш Go-сервис должен быть простым foreground-процессом с graceful shutdown по сигналу — а сигналы это следующая часть.

---

Часть VI. Сигналы: асинхронные уведомления

6.1 Что такое сигнал и откуда он берётся

Сигнал — это программное прерывание, способ ядра (или другого процесса) сказать вашему процессу «случилось событие» асинхронно, вне зависимости от того, что процесс сейчас делает. Это древнейший и самый примитивный механизм IPC в Unix: сигнал несёт ровно один бит информации — свой номер. Никаких данных, только «произошло событие типа N».

Откуда прилетают сигналы:

• От пользователя через терминал. Ctrl+C шлёт SIGINT, Ctrl+\ — SIGQUIT (с дампом), Ctrl+Z — SIGTSTP (приостановка).
• От других процессов через kill(pid, sig). Утилита kill в шелле — это просто обёртка над этим системным вызовом.
• От ядра при аппаратных событиях. Обращение по неверному адресу → SIGSEGV. Деление на ноль → SIGFPE. Запись в закрытый pipe → SIGPIPE.
• От системы инициализации при остановке. systemd/Kubernetes при выключении сервиса шлют SIGTERM, а через grace-period — SIGKILL.
• От таймеров и дочерних процессов. SIGALRM (будильник), SIGCHLD (потомок завершился).

6.2 Важнейшие сигналы

| Сигнал | № | Дефолтное действие | Смысл | | --- | --- | --- | --- | | SIGINT | 2 | завершить | прерывание с клавиатуры (Ctrl+C) | | SIGQUIT | 3 | завершить + core | Ctrl+\, для отладки | | SIGKILL | 9 | завершить | неперехватываемый, мгновенная смерть | | SIGSEGV | 11 | завершить + core | обращение к неверной памяти | | SIGPIPE | 13 | завершить | запись в канал без читателя | | SIGTERM | 15 | завершить | вежливая просьба завершиться (по умолчанию у kill) | | SIGSTOP | 19 | приостановить | неперехватываемая пауза | | SIGCONT | 18 | продолжить | возобновить после STOP | | SIGCHLD | 17 | игнорировать | потомок изменил состояние | | SIGHUP | 1 | завершить | «повесили трубку»; по традиции — «перечитай конфиг» | | SIGUSR1/2 | 10/12 | завершить | свободны для нужд приложения |

Два сигнала стоят особняком: SIGKILL (9) и SIGSTOP (19) нельзя ни перехватить, ни проигнорировать, ни переопределить. Это гарантия ядра, что систему всегда можно вернуть под контроль. Когда вы делаете kill -9, процесс не получает шанса ничего сделать — ядро просто вычёркивает его. Поэтому «graceful» реакция возможна только на другие сигналы (SIGTERM, SIGINT): их вы можете перехватить и корректно завершиться. SIGKILL — это когда терпение кончилось.

6.3 Почему сигналы и Go — сложные соседи

В программах на C сигнал обрабатывается обработчиком сигнала (signal handler) — функцией, которую ядро вызывает, прерывая нормальное исполнение в произвольной точке. И это ад: обработчик может прерваться в середине любой операции, поэтому внутри него можно вызывать только тот самый узкий список async-signal-safe функций. Нельзя брать мьютексы (вдруг прервали в момент, когда мьютекс уже взят — deadlock), нельзя выделять память (аллокатор мог быть в середине работы), нельзя почти ничего.

Go решает эту проблему элегантно: рантайм ставит свои низкоуровневые обработчики сигналов, но не даёт вашему коду исполняться в опасном контексте. Вместо этого пойманный сигнал превращается в обычное значение, которое отправляется в канал. Ваш код читает этот канал из нормальной горутины — в безопасном контексте, где можно всё. Асинхронный, опасный сигнал становится синхронным, ручным сообщением в канале. Это прекрасный пример философии Go «превратить сложное асинхронное в простое синхронное через каналы».

6.4 os/signal: ловим сигналы правильно

package main

import (
    "fmt"
    "os"
    "os/signal"
    "syscall"
)

func main() {
    // Канал для сигналов. Буфер >= 1 ОБЯЗАТЕЛЕН: доставка неблокирующая,
    // и если канал полон в момент сигнала, сигнал ПОТЕРЯЕТСЯ.
    sigCh := make(chan os.Signal, 1)

    // Подписываемся на конкретные сигналы. Без указания — ловятся все ловимые.
    signal.Notify(sigCh, syscall.SIGINT, syscall.SIGTERM, syscall.SIGHUP)

    fmt.Println("работаю, PID:", os.Getpid())
    fmt.Println("пошлите сигнал: kill -HUP", os.Getpid())

    for sig := range sigCh {
        switch sig {
        case syscall.SIGHUP:
            fmt.Println("SIGHUP: перечитываю конфигурацию...")
            // reloadConfig() — и продолжаем работать
        case syscall.SIGINT, syscall.SIGTERM:
            fmt.Println("завершаюсь по", sig)
            // gracefulShutdown()
            return
        }
    }
}

Три правила signal.Notify, нарушение которых порождает трудноуловимые баги:

1. Буфер канала минимум 1. Доставка сигнала в канал неблокирующая: рантайм пытается положить сигнал и, если канал полон, молча выбрасывает. Небуферизованный канал, в который никто не читает в точный момент сигнала, — гарантированная потеря. 2. Подписывайтесь на конкретные сигналы. signal.Notify(ch) без аргументов ловит всё, включая SIGCHLD и прочий шум, который забьёт канал. 3. signal.Stop(ch) для отписки, когда канал больше не нужен, чтобы рантайм перестал в него слать.

6.5 signal.NotifyContext: современная идиома

С Go 1.16 появился способ ещё изящнее — сразу превратить сигнал в отмену контекста. Это стыкует сигналы со всей экосистемой context (и с graceful shutdown из гайда по конкурентности):

func main() {
    // ctx отменится при первом SIGINT/SIGTERM.
    ctx, stop := signal.NotifyContext(context.Background(),
        syscall.SIGINT, syscall.SIGTERM)
    defer stop()

    srv := &http.Server{Addr: ":8080"}
    go srv.ListenAndServe()

    <-ctx.Done() // ждём сигнал
    stop()       // ВАЖНО: восстанавливаем дефолтное поведение сигналов —
                 // теперь ВТОРОЙ Ctrl+C убьёт процесс мгновенно (правильный UX:
                 // если graceful shutdown завис, пользователь может «донажать»)

    shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
    defer cancel()
    srv.Shutdown(shutdownCtx)
}

Пара «первый сигнал ловим — второй пропускаем к дефолту» — важная деталь хорошего сервиса. Первый SIGTERM запускает вежливое завершение; если оно зависло, второй должен убить процесс, а не быть снова проглоченным. NotifyContext + stop() дают это бесплатно.

6.6 Сигналы, которые Go обрабатывает по-своему

Рантайм Go перехватывает некоторые сигналы для собственных нужд, и об этом надо знать:

• SIGPIPE. Запись в закрытый на том конце сокет/pipe по умолчанию убивает процесс. Go подавляет SIGPIPE для своих дескрипторов и вместо этого возвращает ошибку EPIPE из Write — гораздо цивилизованнее. (Исключение — если вы пишете напрямую в дескрипторы 1/2, унаследованные от шелла.)
• SIGSEGV, SIGBUS, SIGFPE. Рантайм ловит их, чтобы превратить в панику Go с осмысленным стектрейсом (например, разыменование nil-указателя — это SIGSEGV, который вы видите как panic: runtime error: invalid memory address).
• SIGURG. С Go 1.14 рантайм использует его для асинхронной вытеснительной планировки: чтобы прервать горутину, застрявшую в длинном цикле без вызовов функций, рантайм шлёт потоку SIGURG. Именно поэтому в strace вы видите поток SIGURG-ов — это не баг, это планировщик работает. И именно поэтому системные вызовы могут прерываться (EINTR), а рантайм их автоматически перезапускает.
• SIGQUIT (Ctrl+\) заставляет Go-программу вывалить стектрейсы всех горутин и упасть — бесценно для отладки зависаний. Управляется переменной GOTRACEBACK.

6.7 Отправка сигналов из Go

// Найти процесс и послать сигнал.
proc, err := os.FindProcess(pid) // на Unix всегда «успешно» — не проверяет существование
if err == nil {
    proc.Signal(syscall.SIGTERM) // вот здесь уже узнаем, жив ли он (ESRCH если нет)
}

// Убить дерево процессов: если потомок создан с Setpgid,
// отрицательный PID шлёт сигнал всей группе.
syscall.Kill(-pgid, syscall.SIGTERM)

// Сигнал самому себе — иногда нужно (например, «доиграть» дефолтное поведение).
syscall.Kill(os.Getpid(), syscall.SIGSTOP)

Тонкость Unix: os.FindProcess на Unix-системах не проверяет, существует ли процесс, — он всегда возвращает объект. Реальная проверка происходит при отправке сигнала: если процесса нет, Signal вернёт ошибку. А ещё есть классическая гонка: между тем, как вы узнали PID, и тем, как послали сигнал, процесс мог умереть, а его PID — достаться другому процессу (PID reuse). Современное решение — pidfd (unix.PidfdOpen): дескриптор, привязанный к конкретному процессу, а не к переиспользуемому номеру.

---

Часть VII. IPC: как процессы общаются

7.1 Карта средств межпроцессного взаимодействия

Процессы изолированы друг от друга — в этом весь смысл процессов. Но иногда им надо общаться, и Linux предлагает целый арсенал механизмов межпроцессного взаимодействия (IPC), каждый со своей нишей:

• Сигналы (часть VI) — один бит «событие произошло». Минимум информации, максимум асинхронности.
• Pipe (канал) — однонаправленный поток байт между родственными процессами. Основа шелловских конвейеров.
• FIFO (именованный канал) — то же, но с именем в файловой системе, для неродственных процессов.
• Сокеты Unix-домена — двунаправленный канал, самый гибкий; умеет передавать даже дескрипторы.
• Разделяемая память — самый быстрый способ: два процесса видят один участок памяти. Общаются без копирования и без ядра на горячем пути.
• Очереди сообщений и семафоры (System V / POSIX IPC) — структурированные сообщения и синхронизация. В современном Go-коде встречаются редко, поэтому упомянем кратко.

Пройдём по главным.

7.2 Pipe: конвейер

Pipe — это однонаправленная труба в ядре с двумя концами: пишущим и читающим. Данные, записанные в пишущий конец, читаются из читающего в том же порядке (FIFO). Классически используется между родственными процессами: родитель создаёт pipe до fork, дескрипторы копируются потомку, и теперь один процесс пишет, другой читает.

package main

import (
    "fmt"
    "os"
)

func main() {
    // os.Pipe возвращает пару связанных *os.File: читающий и пишущий концы.
    r, w, err := os.Pipe()
    if err != nil {
        panic(err)
    }

    go func() {
        defer w.Close() // ЗАКРЫТЬ пишущий конец — сигнал EOF читателю!
        fmt.Fprintln(w, "сообщение через pipe")
        fmt.Fprintln(w, "второе сообщение")
    }()

    buf := make([]byte, 256)
    for {
        n, err := r.Read(buf)
        if n > 0 {
            os.Stdout.Write(buf[:n])
        }
        if err != nil {
            break // io.EOF, когда пишущий конец закрыт И буфер вычитан
        }
    }
}

Три свойства pipe, которые определяют его поведение и порождают все связанные грабли:

1. EOF наступает при закрытии всех пишущих концов. Читатель получит io.EOF только когда закрыты все дескрипторы на запись. Если забыть закрыть пишущий конец (например, он остался открытым в родителе после fork), читатель зависнет навсегда, ожидая данные, которые не придут. Это причина №1 зависаний с pipe. 2. Запись в pipe без читателей → SIGPIPE/EPIPE. Если читающий конец закрыт, а вы пишете — ядро шлёт SIGPIPE (в Go это EPIPE, см. 6.6). Так шелл узнаёт, что head в producer | head закрылся, и останавливает producer. 3. Буфер ограничен (обычно 64 КБ). Когда буфер полон, write блокируется, пока читатель не разгребёт. Это естественный backpressure: быстрый писатель притормаживает под медленного читателя.

Внутри Go pipe между горутинами — это io.Pipe (чисто в памяти, без ядра), а os.Pipe — настоящий системный pipe с дескрипторами (нужен, когда один конец отдаётся внешнему процессу через exec).

7.3 FIFO: pipe с именем

Обычный pipe существует только пока живы держащие его процессы и доступен только родственникам. FIFO (named pipe) решает это: он имеет имя в файловой системе, и любой процесс с правами может его открыть.

import "golang.org/x/sys/unix"

// Создать FIFO в файловой системе (как mkfifo).
unix.Mkfifo("/tmp/mypipe", 0o644)

// Процесс-писатель (в одном терминале):
w, _ := os.OpenFile("/tmp/mypipe", os.O_WRONLY, 0)
// ВНИМАНИЕ: OpenFile на FIFO для записи БЛОКИРУЕТСЯ, пока кто-то не откроет на чтение!
fmt.Fprintln(w, "привет через FIFO")

// Процесс-читатель (в другом терминале):
r, _ := os.OpenFile("/tmp/mypipe", os.O_RDONLY, 0)
io.Copy(os.Stdout, r)

Ключевая особенность и грабля: открытие FIFO блокируется до появления процесса на другом конце. Открыли на запись — ждёте читателя; открыли на чтение — ждёте писателя. Это фича (синхронизация «встречи»), но она удивляет. Обойти можно флагом O_NONBLOCK.

FIFO — простой способ связать две несвязанные программы через файловую систему без сети. Но для серьёзного IPC чаще берут Unix-сокеты.

7.4 Unix-domain сокеты: гибкий и быстрый IPC

Unix-domain сокеты (UDS) — это сокеты, живущие в пределах одной машины. По API они почти идентичны сетевым (тот же net.Dial/net.Listen), но данные не уходят в сетевой стек — они копируются в ядре напрямую между процессами. Отсюда — они быстрее TCP по localhost (нет накладных расходов TCP/IP), и это стандартный способ общения локальных сервисов: так работают Docker (/var/run/docker.sock), PostgreSQL, systemd, X11.

// Сервер:
ln, err := net.Listen("unix", "/tmp/echo.sock")
if err != nil { panic(err) }
defer ln.Close() // удаляет файл сокета

for {
    conn, err := ln.Accept()
    if err != nil { break }
    go func(c net.Conn) {
        defer c.Close()
        io.Copy(c, c) // эхо
    }(conn)
}

// Клиент:
conn, _ := net.Dial("unix", "/tmp/echo.sock")
conn.Write([]byte("привет"))

Обратите внимание: интерфейс — тот же net.Conn, что и для TCP. Ваш код обработки соединения не отличает Unix-сокет от сетевого. Красота единого интерфейса.

Суперспособность UDS — передача файловых дескрипторов между процессами. Через специальное «вспомогательное сообщение» (SCM_RIGHTS) один процесс может отправить другому открытый дескриптор. Дескриптор — это индекс в таблице конкретного процесса (см. 4.2), но ядро при передаче создаёт эквивалентную запись в таблице получателя. Так работает, например, graceful restart сетевых серверов с нулевым простоем: старый процесс передаёт слушающий сокет новому, и ни одно соединение не теряется.

// Отправка дескриптора (упрощённо):
rights := unix.UnixRights(int(file.Fd()))
unix.Sendmsg(sockFd, nil, rights, nil, 0)
// На приёме — unix.Recvmsg + unix.ParseSocketControlMessage + unix.ParseUnixRights

7.5 Разделяемая память и mmap

Самый быстрый IPC — вообще без копирования: два процесса отображают один и тот же участок физической памяти в свои адресные пространства и работают с ним как с обычным срезом байт. Ядро участвует только при настройке; дальше обмен идёт на скорости памяти.

Механизм — mmap. Он же используется для отображения файлов в память (memory-mapped files), что полезно и вне IPC.

package main

import (
    "fmt"
    "os"

    "golang.org/x/sys/unix"
)

func main() {
    f, _ := os.OpenFile("/tmp/shared.dat", os.O_CREATE|os.O_RDWR, 0o644)
    defer f.Close()

    const size = 4096
    f.Truncate(size) // задать размер файла

    // mmap: отобразить файл в память.
    //   PROT_READ|PROT_WRITE — читать и писать через память;
    //   MAP_SHARED — изменения видны другим процессам и попадают в файл
    //                (MAP_PRIVATE — приватная копия, изменения не расшариваются).
    data, err := unix.Mmap(int(f.Fd()), 0, size,
        unix.PROT_READ|unix.PROT_WRITE, unix.MAP_SHARED)
    if err != nil {
        panic(err)
    }
    defer unix.Munmap(data)

    // Теперь data — это []byte, напрямую отображённый на файл/память.
    // Запись в срез = запись в файл, БЕЗ вызовов write.
    copy(data, []byte("данные в разделяемой памяти"))

    // Другой процесс, сделавший mmap того же файла с MAP_SHARED,
    // увидит эти байты немедленно. Для гарантии сброса на диск — unix.Msync.
    fmt.Println("записано через отображённую память")
}

Чем mmap-файл лучше обычного read/write для больших файлов: во-первых, нет копирования из страничного кеша ядра в буфер программы — вы работаете с кешем напрямую; во-вторых, ядро подгружает страницы лениво, по мере обращения (page fault), и умно вытесняет неиспользуемые. Поэтому mmap любят БД и поисковые движки (так работает, например, значительная часть Bolt/bbolt).

Грабли mmap, о которых надо знать: обращение за пределы отображения или к «дырке» в разреженном файле даёт SIGBUS (не панику Go, а честный сигнал, который свалит процесс); отображённая память не участвует в подсчёте кучи Go, и сборщик мусора о ней не знает — вы управляете ей вручную через Munmap; для анонимной разделяемой памяти (без файла) используют MAP_ANONYMOUS|MAP_SHARED или, современнее, memfd_create (unix.MemfdCreate) — анонимный файл, живущий только в памяти.

7.6 eventfd, timerfd, signalfd: события как дескрипторы

Отдельно упомяну красивое семейство Linux-специфичных механизмов, воплощающих принцип «всё есть файл» до предела: они превращают события в читаемые дескрипторы, чтобы их можно было ждать через epoll вместе с сокетами и файлами.

• eventfd — счётчик-семафор в виде дескриптора. Один процесс/поток пишет в него число, другой читает — простейшая межпоточная нотификация. Внутри рантайма Go похожая идея используется для пробуждения netpoller.
• timerfd — таймер как дескриптор: когда таймер срабатывает, дескриптор становится «читаемым». Позволяет ждать таймеры и сокеты одним epoll.
• signalfd — сигналы как дескриптор: вместо асинхронного обработчика вы читаете сигналы из дескриптора синхронно. (В Go это не нужно — рантайм уже даёт сигналы через каналы, см. 6.3 — но концептуально это тот же приём.)

Эти примитивы — фундамент событийных циклов на Linux. Go прячет их за netpoller'ом, но если вы пишете что-то экзотическое (свой event loop поверх epoll), они ваши друзья.

---

Часть VIII. Мультиплексирование ввода-вывода

8.1 Проблема: один поток, много соединений

Вот фундаментальная задача сетевого сервера. У вас тысяча открытых соединений. В любой момент данные могут прийти по любому из них — а могут и не прийти. Как их обслуживать?

Наивный подход «поток на соединение с блокирующим read» упирается в стоимость потоков: тысяча потоков ОС — это гигабайты стеков и убийственные накладные расходы на переключение. Наивный подход «крутить цикл, опрашивая каждое соединение неблокирующим read» сжигает процессор впустую (busy-wait), проверяя тысячу молчащих сокетов миллион раз в секунду.

Нужен способ сказать ядру: «вот тысяча дескрипторов; усыпи меня и разбуди, когда хоть на одном появятся данные». Это и есть мультиплексирование ввода-вывода (I/O multiplexing). Linux предлагает три поколения таких механизмов.

8.2 Три поколения: select, poll, epoll

select (1983) — древнейший. Вы передаёте ядру три битовые маски дескрипторов (ждём чтения / записи / ошибок), ядро блокируется и возвращает, когда что-то готово. Проблемы: жёсткий лимит FD_SETSIZE (обычно 1024 дескриптора — потолок); маски надо пересоздавать на каждый вызов; ядро линейно сканирует все дескрипторы — O(n) на каждый вызов. Для маленьких наборов ещё жив, для тысяч соединений непригоден.

poll (1997) — убрал лимит на 1024 (передаётся массив, а не битовая маска), но осталась главная беда: O(n) сканирование всего набора на каждый вызов. При 100 000 соединений, из которых активны 10, ядро всё равно проверяет все 100 000. Не масштабируется.

epoll (2002, Linux-специфичный) — решение «C10k problem» (как обслужить 10 000 соединений). Ключевая идея — разделить регистрацию и ожидание. Вы один раз регистрируете дескрипторы в объекте epoll (epoll_ctl), а потом много раз ждёте события (epoll_wait). Ядро хранит зарегистрированный набор у себя и возвращает только готовые дескрипторы — не весь набор. Сложность epoll_wait — O(число готовых событий), а не O(общего числа дескрипторов). Это и делает возможными миллионы соединений на одной машине.

select/poll: «проверь ВСЕ эти дескрипторы»  → ядро сканирует все → O(n) каждый раз
epoll:       «я заранее дал тебе набор»     → ядро следит сам
             «дай ГОТОВЫЕ»                    → возвращает только их → O(готовых)

8.3 Как работает epoll: три вызова

// Это иллюстрация механики. В реальном Go-коде так писать НЕ НАДО —
// всё это спрятано внутри runtime netpoller (см. часть X). Но понимать полезно.
import "golang.org/x/sys/unix"

// 1. epoll_create1: создать epoll-инстанс, получить его дескриптор.
epfd, _ := unix.EpollCreate1(0)
defer unix.Close(epfd)

// 2. epoll_ctl: зарегистрировать дескриптор сокета для слежения.
//    EPOLLIN — интересуют события «доступно чтение».
//    EPOLLET — edge-triggered режим (см. ниже).
event := unix.EpollEvent{Events: unix.EPOLLIN | unix.EPOLLET, Fd: int32(connFd)}
unix.EpollCtl(epfd, unix.EPOLL_CTL_ADD, connFd, &event)

// 3. epoll_wait: заснуть, пока не появятся готовые дескрипторы.
events := make([]unix.EpollEvent, 128)
for {
    n, err := unix.EpollWait(epfd, events, -1) // -1 = ждать бесконечно
    if err == unix.EINTR {
        continue
    }
    for i := 0; i < n; i++ {
        fd := events[i].Fd
        // на fd готовы данные — читаем их неблокирующим read до EAGAIN
        handleReadable(int(fd))
    }
}

8.4 Level-triggered vs edge-triggered

У epoll есть два режима уведомления, и путаница между ними — источник тонких багов.

Level-triggered (LT, по умолчанию) — «пока есть данные, я буду напоминать». epoll_wait возвращает дескриптор как готовый всякий раз, пока в нём остаются непрочитанные данные. Можно прочитать часть и вернуться в цикл — на следующей итерации дескриптор снова придёт как готовый. Проще и прощает ошибки.

Edge-triggered (ET, флаг EPOLLET) — «я скажу только в момент появления новых данных, дальше сам». Дескриптор возвращается как готовый только когда состояние меняется (пришли новые данные). Если вы не вычитали всё за один раз, о остатке вам больше не напомнят — он «зависнет». Поэтому с ET обязательно читать в цикле до EAGAIN (пока read не скажет «данных больше нет»). ET эффективнее (меньше вызовов epoll_wait), но требует дисциплины.

Go в своём netpoller использует edge-triggered epoll — и всю дисциплину «читать до EAGAIN» рантайм берёт на себя, а вам отдаёт простой блокирующий conn.Read. В этом и суть следующих частей: epoll — сложный, но вы его не видите, потому что между ним и вами стоит планировщик Go. Чтобы понять, как именно, надо сначала разобрать сам планировщик.

---

Часть IX. runtime: планировщик, память, сборщик мусора

Это концептуальное сердце книги. Здесь сходится всё: почему системные вызовы не останавливают программу, почему миллион горутин — это нормально, откуда берётся и куда девается память. Рантайм Go — это маленькая операционная система внутри вашего процесса, надстроенная над настоящей ОС.

9.1 Зачем вообще нужен планировщик пользовательского уровня

Вернёмся к конфликту из части VIII: потоки ОС — дорогие. Стек потока — мегабайты; создание — системный вызов; переключение между потоками — переход в ядро и обратно (микросекунды). Если бы каждая горутина была потоком ОС, миллион горутин потребовал бы терабайты памяти и утопил бы систему в переключениях контекста.

Идея Go: сделать два уровня планирования. Есть небольшое число потоков ОС (их планирует ядро), и поверх них рантайм Go мультиплексирует тысячи горутин (их планирует сам рантайм, в user space, без обращения к ядру). Переключение горутины — это просто смена нескольких регистров и указателя стека внутри процесса, наносекунды, без входа в ядро. Стек горутины стартует с ~2 КБ и растёт по необходимости. Отсюда — дешевизна, ради которой всё и затевалось.

Такую модель называют M:N-планированием: M горутин на N потоках ОС. Реализована она через три сущности — G, M, P.

9.2 Модель G-M-P

        P (логический процессор, GOMAXPROCS штук)
        │  локальная очередь готовых G
        │  ┌──┬──┬──┬──┐
        │  │G3│G7│G2│  │  ← runnable-горутины ждут своей очереди
        │  └──┴──┴──┴──┘
        ▼
   ┌─────────┐        ┌─────────┐
   │    M    │◀──────▶│    G    │  ← M исполняет G, «стоя» на P
   │ (поток  │  runs  │(горутина)│
   │  ОС)    │        └─────────┘
   └─────────┘
        ▲
        │ M должен «держать» P, чтобы исполнять Go-код

   Глобальная очередь G  (общая, для переполнения и балансировки)
   ┌──┬──┬──┐
   │G9│G5│..│
   └──┴──┴──┘

• G (goroutine) — сама горутина: её стек, указатель инструкций, состояние. Дешёвая структура, их могут быть миллионы. Бывает в состояниях: исполняется, готова к исполнению (runnable, ждёт в очереди), заблокирована (ждёт канал, мьютекс, сеть, системный вызов).

• M (machine) — поток ОС. Именно M физически исполняет код на процессоре. Их немного. M может исполнять Go-код, только когда «держит» P.

• P (processor) — логический процессор, разрешение на исполнение Go-кода и контекст для него. Число P равно GOMAXPROCS (по умолчанию — числу ядер CPU). У каждого P есть локальная очередь готовых горутин и локальный кеш памяти (mcache — о нём в разделе про аллокатор). P — это то, что ограничивает параллелизм: сколько бы ни было потоков, одновременно исполнять Go-код могут только GOMAXPROCS из них, потому что P всего GOMAXPROCS.

Почему три сущности, а не две (горутина + поток)? P — гениальное добавление (появилось в Go 1.1). Оно разрывает жёсткую связь «поток → работа». Когда M застревает в системном вызове (в ядре), он отдаёт свой P другому M — и тот продолжает крутить горутины. Ядро держит один поток заблокированным, но параллелизм Go-программы не страдает: освободившийся P тут же подхватывает свободный или новый M. Без P пришлось бы либо блокировать весь параллелизм на время syscall, либо плодить потоки бесконтрольно. Разберём это подробно — это и есть ответ на вопрос «почему системные вызовы не тормозят Go».

9.3 Жизненный цикл: как горутина исполняется

Когда вы пишете go f(), рантайм создаёт структуру G, кладёт её в локальную очередь текущего P (если та полна — половина очереди уезжает в глобальную, для балансировки). Дальше:

1. M, стоящий на P, закончив текущую горутину, берёт следующую G из локальной очереди своего P. 2. Если локальная очередь пуста — M пытается стащить работу: сначала заглядывает в глобальную очередь, потом делает work stealing — крадёт половину горутин из локальной очереди случайного другого P. Это балансирует нагрузку без центрального диспетчера: простаивающие P сами находят себе работу. 3. Исполняет G, пока та не завершится, не заблокируется или не будет вытеснена.

Кооперативная и вытесняющая планировка. Долгое время Go был чисто кооперативным: горутина уступала процессор только в «точках переключения» — при вызове функций (в прологе функции есть проверка), операциях с каналами, аллокациях. Это создавало проблему: горутина с плотным циклом без вызовов функций (for { x++ }) могла захватить P навечно, не давая другим работать, и даже подвесить сборку мусора. С Go 1.14 добавили асинхронную вытесняющую планировку: поток sysmon замечает горутину, работающую дольше ~10 мс, и посылает её M сигнал SIGURG (вот зачем он из 6.6!). Обработчик сигнала безопасно приостанавливает горутину и возвращает управление планировщику. Теперь ни один цикл не может монополизировать процессор.

9.4 Системные вызовы и планировщик — ключевой механизм

Вот кульминация, ради которой писались части I–VIII. Что происходит, когда горутина делает блокирующий системный вызов (скажем, read с диска, который займёт миллисекунды)?

Наивно поток M просто заблокировался бы в ядре, и его P простаивал бы всё это время — минус один процессор из GOMAXPROCS. Если так заблокируются все M, программа встанет, хотя горутин полно. Go этого не допускает. Механика:

1. Перед системным вызовом рантайм вызывает runtime.entersyscall. Он помечает: «M сейчас уйдёт в ядро». P отвязывается от M и переходит в состояние, где его может забрать другой M. 2. M выполняет инструкцию syscall и блокируется в ядре. Но его P свободен. 3. Специальный поток sysmon (или сам механизм handoff) замечает освободившийся P и передаёт его другому M (из пула простаивающих или создаёт новый). Этот M подхватывает P и продолжает исполнять другие горутины. Параллелизм сохранён: одно ядро занято заблокированным syscall'ом, но логический процессор P работает на другом потоке. 4. Когда системный вызов завершился, M выходит из ядра и вызывает runtime.exitsyscall. Он пытается снова заполучить P: если есть свободный — берёт и продолжает исполнять горутину; если все P заняты — горутина ставится в очередь готовых, а M паркуется в пул простаивающих потоков (или уничтожается, если их накопилось много).

Именно поэтому в 2.2 было так важно различать Syscall и RawSyscall: Syscall делает entersyscall/exitsyscall (сообщает планировщику, позволяет handoff), а RawSyscall — нет (для мгновенных вызовов, где handoff дороже самого вызова). Ошибочный RawSyscall на блокирующем вызове заблокирует M вместе с P — потерянный процессор.

Есть тонкость про два вида syscall'ов с точки зрения рантайма. Быстрые (возвращаются мгновенно) обрабатываются оптимистично: entersyscall не отвязывает P немедленно, а лишь помечает состояние; если вызов вернулся быстро, P никуда не уходил — экономия. Медленные (заблокировались надолго) ловит sysmon: увидев, что M торчит в syscall дольше порога, он принудительно отбирает у него P и отдаёт другому M (это называется handoff). Так система адаптируется: короткие вызовы не платят за handoff, длинные не держат P.

И отдельная, важнейшая ветка: сетевые операции вообще не блокируют M. Для них есть netpoller (часть X) — сетевой read не уходит в блокирующий syscall, а паркует только горутину, регистрируя дескриптор в epoll. M остаётся свободным и крутит другие горутины. Блокирующие syscall'ы (с отдачей P) — это в основном файловый ввод-вывод и вызовы к внешним библиотекам; сеть идёт мимо через epoll.

9.5 sysmon: демон-надзиратель

sysmon («system monitor») — служебный поток, запускаемый рантаймом, который работает без P (ему не нужно разрешение исполнять Go-код) и периодически просыпается (от 20 мкс до 10 мс). Его обязанности — фоновая гигиена планировщика:

• отбирать P у потоков, застрявших в долгих системных вызовах (handoff из 9.4);
• вытеснять горутины, работающие дольше 10 мс (посылать SIGURG);
• запускать сборку мусора, если она давно не запускалась;
• опрашивать netpoller, если это давно не делалось, и будить горутины, чьи сетевые операции готовы;
• возвращать неиспользуемую память ОС.

Это тот самый фоновый поток, из-за которого даже пустая Go-программа в strace показывает активность: sysmon живёт своей жизнью.

9.6 Память: стек и куча в мире Go

Память горутины делится на стек и кучу — как и везде, но с особенностями.

Стек. У каждой горутины свой стек, стартующий с крохотных ~2 КБ (в отличие от мегабайтных стеков потоков ОС). Стек растёт динамически: когда его не хватает, рантайм выделяет вдвое больший, копирует туда содержимое старого и переписывает указатели (contiguous stacks, с Go 1.4; раньше были сегментированные стеки с известной проблемой «hot split»). Может и сжиматься при сборке мусора. Именно управляемый рост стека делает возможным миллион дешёвых горутин.

Куча. Всё, что «убегает» за пределы стека, живёт в куче и управляется сборщиком мусора. Что именно попадает в кучу, решает escape analysis — анализ побега на этапе компиляции. Если компилятор докажет, что значение не переживёт функцию (не «убежит»), оно ляжет на стек (дёшево, освобождается автоматически при возврате). Если значение возвращается по указателю, кладётся в структуру, живущую дольше, или его адрес уходит в другую горутину — оно «убегает» в кучу.

# Посмотреть решения escape analysis:
go build -gcflags='-m' main.go
# ./main.go:10:2: moved to heap: x       ← убежало в кучу
# ./main.go:15:13: ... does not escape   ← осталось на стеке

Практический смысл: аллокации в куче нагружают сборщик мусора, стековые — бесплатны. Понимание escape analysis — основа оптимизации Go-программ по памяти. Классические причины побега: возврат указателя на локальную переменную, передача в interface{} (боксинг), захват переменной замыканием, которое живёт дольше функции, слишком большой объект.

9.7 Аллокатор: mcache, mcentral, mheap

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

• mcache — у каждого P свой. Кеш свободных блоков популярных размеров (size classes). Аллокация маленького объекта — это взять готовый блок из mcache своего P. Поскольку mcache привязан к P, а на P в каждый момент только один M, — никакой синхронизации не нужно, аллокация почти бесплатна.
• mcentral — центральный список блоков каждого size class, общий для всех P. Когда mcache опустел, он подтягивает блоки отсюда (уже с блокировкой, но это редко).
• mheap — вся куча целиком, запрашивает страницы у ОС через mmap. Большие объекты (>32 КБ) выделяются прямо здесь.

Объекты сгруппированы по ~70 классам размеров, чтобы бороться с фрагментацией: запрос на 100 байт округляется до ближайшего класса (112), и все блоки этого класса взаимозаменяемы. Память у ОС берётся большими кусками (арены по 64 МБ) и нарезается внутри — чтобы не дёргать mmap на каждый чих.

9.8 Сборщик мусора: конкурентный, трёхцветный, с барьером записи

GC в Go спроектирован под одну главную цель — малые паузы. Не максимальную пропускную способность, не минимальную память, а именно короткие остановки (обычно меньше миллисекунды), чтобы не дёргать латентно-чувствительные сервисы. Ради этого он конкурентный: работает одновременно с вашими горутинами, почти не останавливая их.

Алгоритм — трёхцветная пометка-очистка (tri-color mark-and-sweep), неперемещающая (объекты не двигаются в памяти — поэтому указатели стабильны, что важно для взаимодействия с C и unsafe) и не поколенческая (в отличие от JVM; для типичных Go-программ с их упором на стековые аллокации это оказалось разумным компромиссом).

Трёхцветная абстракция:

• Белые объекты — кандидаты на удаление (пока не доказано, что живые).
• Серые — живые, но их ссылки ещё не просмотрены.
• Чёрные — живые, и все их ссылки просмотрены.

GC начинает с корней (стеки горутин, глобальные переменные), красит их в серый, затем в цикле берёт серый объект, красит в чёрный, а всё, на что он ссылается, — в серый. Когда серых не осталось — всё живое чёрное, всё белое можно удалять (фаза sweep, тоже конкурентная и ленивая).

Проблема конкурентности и барьер записи. Пока GC красит объекты, ваши горутины продолжают менять указатели. Опасность: чёрный объект (уже просмотренный) получает ссылку на белый (ещё не помеченный), и одновременно исчезает последняя серая ссылка на этот белый — GC решит, что белый мёртв, и удалит живой объект. Катастрофа. Решение — барьер записи (write barrier): на время сборки компилятор вставляет перед каждой записью указателя маленькую проверку, которая «подкрашивает» задетые объекты, сохраняя инвариант «чёрный не ссылается на белый напрямую». Барьер работает только во время активного GC-цикла, в остальное время его нет.

Паузы Stop-The-World. Полностью без остановок не обойтись: есть два коротких STW — в начале цикла (включить барьер записи, просканировать корни) и в конце (финальная синхронизация пометки). Но они измеряются десятками микросекунд, а не миллисекундами, потому что основная работа идёт конкурентно.

9.9 Управление сборщиком: GOGC и GOMEMLIMIT

Когда запускается GC? По достижению порога роста кучи, задаваемого GOGC (по умолчанию 100):

GOGC=100 → GC стартует, когда куча выросла на 100% с последней сборки
           (то есть удвоилась). Меньше GOGC → чаще GC, меньше памяти, больше CPU.
           Больше GOGC → реже GC, больше памяти, меньше CPU.

GOGC=50 ./myapp    # агрессивнее собирать (экономим память ценой CPU)
GOGC=off ./myapp   # выключить GC вовсе (для короткоживущих батч-задач)

С Go 1.19 появился GOMEMLIMIT — мягкий лимит памяти. Он говорит рантайму «старайся не превышать N байт», и GC начинает работать активнее по мере приближения к лимиту, даже если порог GOGC ещё не достигнут. Это спасение для контейнеров: раньше Go-приложение, не знающее о лимите памяти cgroup, могло раздуть кучу и получить OOM-kill; теперь GOMEMLIMIT=500MiB держит его в рамках. Рекомендуемая практика в Kubernetes — ставить GOMEMLIMIT в ~90% от лимита памяти пода и GOGC оставить дефолтным (или выключить, положившись на memlimit).

Наблюдать за GC:

GODEBUG=gctrace=1 ./myapp
# gc 1 @0.012s 2%: 0.018+1.2+0.005 ms clock, ... → детали каждого цикла GC:
#   номер, время с старта, доля CPU на GC, фазы (STW+конкурентная+STW), размеры кучи

9.10 Наблюдаемость рантайма из кода

import "runtime"

runtime.NumGoroutine()   // сколько горутин живо (рост = возможная утечка)
runtime.NumCPU()         // ядер в системе
runtime.GOMAXPROCS(0)    // текущее число P (0 = только прочитать)

var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("куча: %d МБ, циклов GC: %d, пауза GC: %v\n",
    m.HeapAlloc/1024/1024, m.NumGC, time.Duration(m.PauseNs[(m.NumGC+255)%256]))

runtime.GC()             // принудительная сборка (для тестов/бенчмарков)

Для продакшена — runtime/pprof и net/http/pprof: профили CPU, кучи, горутин, блокировок. go tool pprof и go tool trace показывают жизнь рантайма в деталях — какие горутины чего ждут, где паузы GC, где конкуренция за локи. Это главный инструмент, когда «что-то тормозит, а что — непонятно».

---

Часть X. net: сокеты и netpoller

Теперь, когда планировщик разобран, можно раскрыть главную магию Go для серверов: почему вы пишете простой блокирующий сетевой код, а получаете производительность асинхронного event loop, как в nginx или Node.js, — но без единого колбэка.

10.1 Сокет как файловый дескриптор

Сетевое соединение в Unix — это сокет, а сокет — это файловый дескриптор (часть IV во всей красе). Классическая последовательность системных вызовов для TCP-сервера:

socket()  → создать сокет, получить дескриптор
bind()    → привязать к адресу и порту
listen()  → перевести в режим прослушивания
accept()  → принять входящее соединение → НОВЫЙ дескриптор на это соединение
read()/write() на дескрипторе соединения → обмен данными
close()   → закрыть

Клиент проще: socket() → connect() → read/write → close.

В Go всё это спрятано за net.Listen и net.Dial, но под ними — ровно эти вызовы. Можно увидеть в strace любого Go-сервера: socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK|SOCK_CLOEXEC, ...), bind, listen, accept4. Обратите внимание на флаг SOCK_NONBLOCK — вот первый ключ к магии: Go создаёт все сокеты неблокирующими.

10.2 Дилемма блокирующего и неблокирующего ввода-вывода

Сокет может работать в двух режимах.

Блокирующий (по умолчанию в C): read на сокете без данных усыпляет весь поток до прихода данных. Просто программировать («прочитай мне байты»), но не масштабируется — поток на соединение, см. 8.1.

Неблокирующий: read на сокете без данных немедленно возвращает EAGAIN («сейчас нечего, зайди позже»). Не блокирует поток, но программировать мучительно: приходится строить event loop вокруг epoll, вручную отслеживать состояние каждого соединения, дробить логику на колбэки (та самая «callback hell» из мира Node.js).

Go совершает фокус: берёт неблокирующие сокеты (для эффективности) и подаёт их программисту как блокирующие (для простоты). Разрыв между этими двумя мирами закрывает netpoller, работающий в связке с планировщиком.

10.3 netpoller: как это работает

Вот что происходит, когда ваша горутина вызывает conn.Read(buf) на TCP-соединении:

1. Рантайм пробует неблокирующий read на дескрипторе. Если данные уже есть — читает и сразу возвращает. Горутина даже не заметила, что сокет неблокирующий. 2. Если данных нет (read вернул EAGAIN), рантайм не блокирует поток. Вместо этого он:

• регистрирует дескриптор в epoll (epoll_ctl), если тот ещё не зарегистрирован, с интересом «доступно чтение»;
• паркует горутину (переводит G в состояние ожидания, связывая её с этим дескриптором) через gopark;
• M освобождается и берёт из очереди другую готовую горутину. Поток продолжает работать!

3. Когда данные приходят, ядро помечает дескриптор готовым в epoll. Кто-то вызывает netpoll (это делает планировщик при поиске работы, или sysmon, или специальный поток) — epoll_wait возвращает список готовых дескрипторов. 4. Рантайм находит горутины, припаркованные на этих дескрипторах, и переводит их обратно в готовые (goready). Они возвращаются в очереди планировщика и вскоре продолжат исполнение с того же conn.Read, который теперь успешно прочитает данные.

горутина: conn.Read(buf)
   │
   ├─ есть данные? → читаем, возврат ✓
   │
   └─ EAGAIN → регистрируем fd в epoll, ПАРКУЕМ горутину (gopark)
                        M свободен → крутит другие горутины
                              ⋮  (проходит время)
              ядро: данные пришли, fd готов в epoll
                        │
              netpoll: epoll_wait вернул fd → goready(горутина)
                        │
              горутина снова в очереди → M подхватывает → read успешен ✓

Итог: одна горутина на соединение — это дёшево. Заблокированная на сети горутина не держит поток ОС — она держит лишь свою маленькую структуру G и запись в epoll. Миллион соединений = миллион дешёвых горутин + один epoll + горстка потоков. Вы пишете прямолинейный синхронный код:

func handleConn(conn net.Conn) {
    defer conn.Close()
    buf := make([]byte, 4096)
    for {
        n, err := conn.Read(buf)  // «блокирующий» для вас, неблокирующий+epoll внутри
        if err != nil {
            return                // io.EOF или ошибка
        }
        process(buf[:n])
    }
}

// и запускаете горутину на соединение, не думая о масштабе:
for {
    conn, err := ln.Accept()
    if err != nil { break }
    go handleConn(conn)  // хоть миллион — рантайм разрулит
}

Никаких epoll, колбэков, машин состояний. Синхронный код + дешёвые горутины + невидимый netpoller = производительность event-loop-сервера с простотой блокирующего кода. Это, возможно, главная причина, почему Go так хорош для сетевых сервисов.

10.4 Таймауты и дедлайны

Раз чтение «блокирующее», как его прервать по таймауту? Через дедлайны — они реализованы всё тем же netpoller (дескриптор ждёт не только данные, но и срабатывание таймера):

conn.SetReadDeadline(time.Now().Add(5 * time.Second))
n, err := conn.Read(buf)
if err != nil {
    var netErr net.Error
    if errors.As(err, &netErr) && netErr.Timeout() {
        // дедлайн истёк — данные не пришли за 5 секунд
    }
}

conn.SetWriteDeadline(...) // отдельно на запись
conn.SetDeadline(...)      // на обе операции сразу

Дедлайн — не таймаут на операцию, а абсолютный момент времени, после которого операция провалится. Его нужно сдвигать перед каждой операцией (или периодически), иначе он «сгорит» один раз и все последующие чтения будут мгновенно падать. Это частый баг: поставили дедлайн один раз перед циклом чтения — второе чтение сразу упало с таймаутом.

В современном коде вместо ручных дедлайнов чаще используют context: http.Server и хорошие библиотеки БД/RPC сами проецируют отмену context на дедлайны сокета. Отсюда стык с частью про сигналы и graceful shutdown: SIGTERM → отмена корневого контекста → дедлайны на всех соединениях → чистое завершение.

10.5 Настройка сокетов: за пределами net

Иногда нужен контроль, которого net не даёт напрямую, — опции сокета через setsockopt. Правильный путь — через net.ListenConfig/net.Dialer с колбэком Control, который даёт доступ к дескриптору до привязки, не ломая netpoller:

lc := net.ListenConfig{
    Control: func(network, address string, c syscall.RawConn) error {
        return c.Control(func(fd uintptr) {
            // SO_REUSEPORT: несколько процессов слушают ОДИН порт,
            // ядро балансирует соединения между ними (zero-downtime деплой,
            // масштабирование на ядра). Классический приём для高-нагрузки.
            unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.SO_REUSEPORT, 1)
        })
    },
}
ln, err := lc.Listen(context.Background(), "tcp", ":8080")

Другие частые опции: TCP_NODELAY (отключить алгоритм Нейгла — важно для интерактивных протоколов с мелкими пакетами; Go, кстати, включает его по умолчанию), SO_KEEPALIVE (детект мёртвых соединений), SO_RCVBUF/SO_SNDBUF (размеры буферов).

10.6 Когда netpoller не помогает: файлы и DNS

Важная асимметрия: netpoller работает для сокетов и pipe, но не для обычных файлов на диске. Причина в Linux: epoll не поддерживает регулярные файлы (они «всегда готовы» с точки зрения epoll, но read с диска всё равно блокируется на время физического ввода-вывода). Поэтому дисковый read, промахнувшийся мимо страничного кеша, — это настоящий блокирующий syscall, который отдаёт P другому M (механизм 9.4). Обычно это не проблема (файловые операции быстры и редки по сравнению с сетевыми), но при интенсивном дисковом вводе-выводе можно увидеть рост числа потоков ОС — рантайм создаёт их, чтобы компенсировать заблокированные на диске M. (На горизонте — интеграция с io_uring, которая обещает асинхронный дисковый ввод-вывод и для Go; следите за развитием рантайма.)

DNS — отдельная история: у Go два резолвера. Чистый Go-резолвер (по умолчанию во многих конфигурациях) сам ходит по сети через netpoller — не блокирует потоки. Резолвер через cgo (libc getaddrinfo) уходит в блокирующий C-вызов и держит поток. Выбор управляется GODEBUG=netdns=go|cgo; для контейнеров и высокой конкуренции обычно предпочтителен чистый Go-резолвер.

---

Часть XI. unsafe: работа с памятью напрямую

11.1 Зачем нужен unsafe и чем он опасен

Go — язык с безопасной памятью: вы не можете случайно прочитать чужую память, выйти за границу среза без паники, перепутать типы. За это отвечает система типов и рантайм. Пакет unsafe — это официальная лазейка, отключающая эти гарантии. Его имя — честное предупреждение: используя unsafe, вы берёте на себя обязанности, которые обычно выполняет компилятор, и цена ошибки — не паника, а порча памяти, загадочные падения и уязвимости.

Зачем он вообще существует? Для системного программирования он незаменим в трёх сценариях:

• Разметка структур ядра. Системные вызовы принимают C-структуры с точной байтовой раскладкой; иногда нужно интерпретировать сырые байты как структуру или наоборот.
• Взаимодействие с C (cgo): C и Go по-разному видят память, и unsafe — мост между ними.
• Оптимизации без копирования. Превратить []byte в string без копирования, интерпретировать буфер как массив структур — там, где копирование недопустимо дорого.

Правило номер ноль: если можно без unsafe — делайте без unsafe. Он для тех редких мест, где действительно нельзя иначе.

11.2 Четыре инструмента пакета

Пакет unsafe крошечный — по сути четыре вещи:

unsafe.Pointer   // «универсальный указатель»: указатель на что угодно, без типа
unsafe.Sizeof(x) // размер значения в байтах (во время компиляции)
unsafe.Alignof(x)// требование выравнивания типа
unsafe.Offsetof(s.field) // смещение поля внутри структуры в байтах

Плюс с Go 1.17/1.20 добавили безопасные помощники, которыми и следует пользоваться вместо ручной арифметики:

unsafe.Add(ptr, offset)        // арифметика указателей корректно (вместо uintptr-хаков)
unsafe.Slice(ptr, len)         // сделать срез из указателя и длины
unsafe.SliceData(slice)        // указатель на нижележащий массив среза
unsafe.String(ptr, len)        // сделать string из указателя и длины
unsafe.StringData(str)         // указатель на байты строки

11.3 unsafe.Pointer и его отличие от uintptr

Это центральное и самое опасное место. Есть два «сырых» способа держать адрес, и путать их смертельно.

unsafe.Pointer — это указатель, который сборщик мусора видит и отслеживает. Если объект жив, пока на него есть unsafe.Pointer, GC его не удалит и (в неперемещающем GC Go) не сдвинет.

uintptr — это просто число, равное адресу. GC его не видит и не отслеживает. Для GC uintptr — обычное целое, а не ссылка.

Отсюда — смертельная ловушка: как только вы превратили unsafe.Pointer в uintptr, объект по этому адресу становится «невидим» для GC. Между строкой, где вы получили uintptr, и строкой, где снова его используете, сборщик может решить, что объект мёртв, и удалить его — а вы держите число-адрес, указывающее теперь в никуда (или на новый объект). Поэтому:

> Преобразование unsafe.Pointer → uintptr → unsafe.Pointer должно происходить в одном выражении, без промежуточного хранения uintptr в переменной. Разорвёте — GC может убрать объект прямо посреди.

// ПРАВИЛЬНО: всё в одном выражении, GC не успевает вклиниться.
p := unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + unsafe.Offsetof(s.field))

// ОПАСНО: uintptr «живёт» в переменной — GC может убрать объект между строк.
addr := uintptr(unsafe.Pointer(&s)) // s теперь невидим для GC!
// ... тут может случиться сборка ...
p := unsafe.Pointer(addr + off)     // addr, возможно, указывает в никуда

// СОВРЕМЕННО и БЕЗОПАСНО: unsafe.Add вместо ручной арифметики.
p := unsafe.Add(unsafe.Pointer(&s), unsafe.Offsetof(s.field))

11.4 Разрешённые паттерны

Документация пакета перечисляет закрытый список легальных способов использовать unsafe.Pointer. Всё, что вне списка, — потенциально неопределённое поведение, которое к тому же ловит go vet. Главные разрешённые паттерны:

1. Конвертация T1 → T2, если T1 и T2 совместимы по разметке (например, зеркальные структуры). p := (T2)(unsafe.Pointer(&t1)). 2. Арифметика указателей через unsafe.Add (или uintptr в одном выражении) — доступ к полю или элементу массива по смещению. 3. unsafe.Slice/unsafe.String — построение срезов/строк из указателя и длины. 4. Вызовы syscall.Syscall, где аргумент-uintptr получен из unsafe.Pointer прямо в списке аргументов вызова (рантайм это специально учитывает). 5. Работа с reflect через задокументированные соответствия.

// []byte → string без копирования (с Go 1.20).
func bytesToString(b []byte) string {
    if len(b) == 0 {
        return ""
    }
    return unsafe.String(unsafe.SliceData(b), len(b))
    // ОБЯЗАТЕЛЬСТВО: после этого нельзя менять b, пока используется строка!
    // Иначе нарушите неизменяемость строк — фундаментальный инвариант Go.
}

// string → []byte без копирования.
func stringToBytes(s string) []byte {
    if s == "" {
        return nil
    }
    return unsafe.Slice(unsafe.StringData(s), len(s))
    // ОБЯЗАТЕЛЬСТВО: полученный срез НЕЛЬЗЯ модифицировать — строки неизменяемы,
    // запись в этот срез — порча памяти или падение (строка может лежать в
    // read-only сегменте бинарника).
}

import "unsafe"

type Bad struct {
    a bool  // 1 байт
    b int64 // 8 байт — должен лежать по адресу, кратному 8
    c bool  // 1 байт
}
// Реальная раскладка: a(1) + padding(7) + b(8) + c(1) + padding(7) = 24 байта!
// unsafe.Sizeof(Bad{}) == 24

type Good struct {
    b int64 // 8
    a bool  // 1
    c bool  // 1
    // padding(6) в конце для выравнивания массива таких структур
}
// unsafe.Sizeof(Good{}) == 16 — то же содержимое, но на треть меньше

var s Bad
fmt.Println(unsafe.Sizeof(s))        // 24 — полный размер
fmt.Println(unsafe.Offsetof(s.b))    // 8 — где начинается b
fmt.Println(unsafe.Alignof(s.b))     // 8 — требование выравнивания int64

/*
#include <stdlib.h>
#include <string.h>
*/
import "C"
import "unsafe"

func useC() {
    // Go-строка → C-строка: C.CString ВЫДЕЛЯЕТ C-памятью (malloc),
    // GO НЕ УБЕРЁТ ЕЁ — освобождать вручную!
    cstr := C.CString("привет")
    defer C.free(unsafe.Pointer(cstr)) // иначе утечка C-памяти

    C.strlen(cstr)
}

package main

import (
    "fmt"
    "os"
    "os/exec"
    "syscall"
)

func main() {
    switch os.Args[1] {
    case "run":
        parent() // мы снаружи: создать namespaces и перезапустить себя
    case "child":
        child()  // мы уже внутри namespaces: донастроить и exec цель
    default:
        fmt.Println("usage: run|child <cmd> [args...]")
        os.Exit(1)
    }
}

// parent: запускает /proc/self/exe (саму эту программу) заново,
// но уже в новых namespaces.
func parent() {
    // /proc/self/exe — символическая ссылка на исполняемый файл текущего процесса.
    // Запуская его с аргументом "child", мы перезапускаем СЕБЯ внутри namespaces.
    cmd := exec.Command("/proc/self/exe", append([]string{"child"}, os.Args[2:]...)...)
    cmd.Stdin, cmd.Stdout, cmd.Stderr = os.Stdin, os.Stdout, os.Stderr

    cmd.SysProcAttr = &syscall.SysProcAttr{
        // Вот они — те самые namespaces:
        Cloneflags: syscall.CLONE_NEWUTS | // свой hostname
            syscall.CLONE_NEWPID | // потомок станет PID 1
            syscall.CLONE_NEWNS | // своё дерево монтирования
            syscall.CLONE_NEWNET, // свой сетевой стек (изолированный, без сети!)
        // Для rootless можно добавить CLONE_NEWUSER с UidMappings/GidMappings.
    }

    if err := cmd.Run(); err != nil {
        fmt.Println("ошибка:", err)
        os.Exit(1)
    }
}

// child: исполняется УЖЕ внутри namespaces. Настраиваем «мир» контейнера.
func child() {
    fmt.Printf("внутри контейнера, PID: %d\n", os.Getpid()) // напечатает 1!

    // Свой hostname (виден только внутри UTS namespace).
    syscall.Sethostname([]byte("container"))

    // Здесь в настоящем runtime были бы:
    //  - chroot/pivot_root в образ файловой системы контейнера;
    //  - монтирование своего /proc (mount -t proc proc /proc),
    //    чтобы ps показывал только процессы контейнера;
    //  - настройка сети (veth-пара, мост);
    //  - применение cgroups (см. 12.3);
    //  - сброс привилегий (capabilities), seccomp-фильтры.
    // syscall.Chroot("/path/to/rootfs"); os.Chdir("/")

    // Заменяем себя целевой командой (exec — тот самый из части V).
    cmd := exec.Command(os.Args[2], os.Args[3:]...)
    cmd.Stdin, cmd.Stdout, cmd.Stderr = os.Stdin, os.Stdout, os.Stderr
    if err := cmd.Run(); err != nil {
        fmt.Println("ошибка команды:", err)
        os.Exit(1)
    }
}

go build -o mycontainer main.go
sudo ./mycontainer run /bin/sh
# внутри контейнера, PID: 1        ← процесс думает, что он PID 1
# / # hostname                     ← "container", а не хост
# / # ps                          ← (после mount /proc) видит только себя

func applyCgroup(pid int) error {
    base := "/sys/fs/cgroup/mycontainer"

    // 1. Создать cgroup (просто mkdir — ядро само создаёт управляющие файлы).
    if err := os.MkdirAll(base, 0o755); err != nil {
        return err
    }

    // 2. Лимит памяти: 100 МБ. Превысит — процесс получит OOM-kill.
    if err := os.WriteFile(base+"/memory.max", []byte("104857600"), 0o644); err != nil {
        return err
    }

    // 3. Лимит CPU: "50000 100000" = 50 мс на каждые 100 мс = полъядра (0.5 CPU).
    if err := os.WriteFile(base+"/cpu.max", []byte("50000 100000"), 0o644); err != nil {
        return err
    }

    // 4. Поместить процесс в cgroup — записать его PID.
    //    Все потомки автоматически наследуют группу.
    return os.WriteFile(base+"/cgroup.procs",
        []byte(strconv.Itoa(pid)), 0o644)
}

// Информация о своём процессе:
data, _ := os.ReadFile("/proc/self/status")   // память, потоки, UID, capabilities...
cmdline, _ := os.ReadFile("/proc/self/cmdline") // аргументы (разделены \0)
data, _ = os.ReadFile("/proc/self/maps")       // карта памяти: что куда отображено

// Про любой процесс по PID:
data, _ = os.ReadFile(fmt.Sprintf("/proc/%d/stat", pid))

// Файловые дескрипторы процесса — директория символических ссылок:
fds, _ := os.ReadDir("/proc/self/fd") // сколько открыто, куда указывают — диагностика утечек fd!

// Общесистемное:
loadavg, _ := os.ReadFile("/proc/loadavg")     // средняя нагрузка
meminfo, _ := os.ReadFile("/proc/meminfo")     // память системы
cpuinfo, _ := os.ReadFile("/proc/cpuinfo")     // процессоры

func countOpenFDs() int {
    entries, err := os.ReadDir("/proc/self/fd")
    if err != nil {
        return -1
    }
    return len(entries) - 1 // минус сам дескриптор, открытый для чтения этой директории
}
// Растёт со временем при неизменной нагрузке → где-то забыт Close.

Ваш код (os.Open, net.Dial, go f())
   │
   ├─ os / net / io ─────── удобные, переносимые обёртки (III, X)
   │      │
   │      ├─ runtime ────── планировщик G-M-P, netpoller, GC, память (IX)
   │      │       делает системные вызовы неблокирующими для горутин
   │      │
   │      └─ x/sys/unix ─── типизированные обёртки над каждым syscall (II)
   │             syscall (заморожен) — легаси-уровень
   │                  │
   │                  └─ runtime·Syscall (ассемблер) ── инструкция SYSCALL (I, II)
   │                          │  entersyscall/exitsyscall — стык с планировщиком
   │                          ▼
   └──────────────────── ЯДРО LINUX (кольцо 0) ──────────────────────
          файлы (IV), процессы (V), сигналы (VI), IPC (VII),
          epoll (VIII), namespaces + cgroups (XII), /proc (XIII)
                                   │
                          unsafe (XI) — лазейка вбок,
                          когда нужно тронуть память напрямую