Поля hchan

• В qcount и dataqsiz лежат число элементов и вместимость буфера (это и есть len/cap).
• buf указывает на массив dataqsiz * elemsize байт; у небуферизированного канала массива нет, но и nil там не лежит: buf указывает на собственное поле, этот адрес нужен race-детектору.
• sendx и recvx: индексы записи и чтения в кольце.
• recvq и sendq держат двусвязные списки sudog: горутины, стоящие на приёме и на отправке.
• А в lock mutex лежит обычный runtime.mutex. Канал не lock-free.
• closed uint32, elemtype, elemsize.

Внутри sudog лежит всё про ожидание: указатель на g, указатель elem на место, откуда взять или куда положить значение, флаг success, ссылки на соседей. У одной горутины бывает несколько sudog сразу, ровно это происходит в select, где она встаёт в очереди сразу нескольких каналов. Кэшируются sudog в P и в глобальном пуле, чтобы не аллоцировать на каждой блокировке.

Главная оптимизация - прямая передача

Если при отправке в recvq кто-то есть, значение не кладётся в буфер: send вызывает sendDirect и копирует значение прямо в стек получателя, минуя буфер вообще. Это экономит одну копию и, что важнее, оставляет данные горячими в кэше. Симметрично работает приём с непустой sendq.

Тут проверяют не память, а умение разложить механизм. Отвечай по нарастающей: сначала наивная версия, потом настоящая.

Шаг 1: наивная версия

Структура: mutex, слайс-очередь, sync.Cond для отправителей и второй для получателей. Send: лок, пока очередь полна висим на cond.Wait(), кладём, condRecv.Signal(), анлок. Это рабочий канал, его правда можно написать на собесе за пять минут. Минусы: два лишних пробуждения на каждую передачу, нет прямой передачи, и select по нескольким каналам так не сделать.

Шаг 2: что добавляет рантайм

• Свои очереди вместо Cond. Нужен явный список ожидающих (sudog), чтобы будить конкретную горутину, а не всех, и чтобы соблюдать FIFO-справедливость.
• gopark/goready вместо futex. Блокировать надо горутину, а не поток: поток должен уйти выполнять другую работу. Обычной библиотеке такое недоступно, отсюда и вывод, что каналы обязаны жить в рантайме.
• Прямая передача. Если ждущий уже есть, копируем ему в стек и не трогаем буфер.
• Поддержка select. Горутина должна уметь стоять в нескольких очередях сразу, и ровно один из каналов должен её «выиграть»: это делается через g.selectDone с CAS.
• Кольцевой буфер вместо слайса: фиксированный размер, никаких реаллокаций, индексы вместо сдвигов.

Практический критерий выбора

• Буфер 0 берут, когда нужна синхронизация и обратное давление. Продюсер физически не может обогнать консьюмера. Это дефолт, с которого стоит начинать.
• Буфер 1 работает как «почтовый ящик»: отправитель кладёт и уходит, гарантированно не зависая. Канал ответа в RPC, канал ошибки, сигнальный канал.
• Буфер N сглаживает рывки, когда средняя скорость потребителя выше средней скорости продюсера, а пики короткие. Число надо обосновать (например, «столько же, сколько воркеров»), а не «поставим 100, пусть будет».

Почему именно так - логика, а не произвол

• nil блокирует, а не паникует, чтобы в select можно было отключать ветку присваиванием ch = nil. Свойство спроектированное, а не побочный эффект.
• close паникует на nil, потому что закрывает владелец, а владелец обязан знать, что канал создан. Молчаливое «ничего не делаем» скрыло бы ошибку.
• Send в закрытый паникует, потому что закрытие означает «данных больше не будет». Тихо проглотить значение значит потерять данные, а это хуже паники.
• Recv из закрытого не паникует, потому что получателей может быть много, они узнают о конце асинхронно, и это нормальный путь завершения, а не ошибка.
• Повторный close паникует: значит, владельцев у канала несколько, то есть где-то ошибка в архитектуре.

ch := make(chan int, 3)
ch <- 1
ch <- 2
close(ch)

v, ok := <-ch   // 1, true
v, ok = <-ch    // 2, true
v, ok = <-ch    // 0, false: буфер пуст, канал закрыт
v, ok = <-ch    // 0, false, и так бесконечно

// range делает то же самое и выходит сам, но здесь канал уже вычерпан
// четырьмя строками выше, поэтому цикл ничего не напечатает и сразу завершится:
for v := range ch { fmt.Println(v) }   // ни одной строки

// А вот если бы range шёл сразу после close, не читая вручную:
ch2 := make(chan int, 3)
ch2 <- 1
ch2 <- 2
close(ch2)
for v := range ch2 { fmt.Println(v) }  // 1
                                       // 2

Механика

В chanrecv проверка выглядит так: «если канал закрыт и qcount == 0, вернуть zero и false». Оба условия вместе. Пока в кольцевом буфере что-то есть, работает обычная ветка: скопировать из buf[recvx], сдвинуть recvx, уменьшить qcount. closechan при этом трогает только флаг closed и очереди ожидающих, а буфер не очищает.

Пошагово, что делает рантайм

1. chansend берёт лок канала, видит пустую recvq и dataqsiz == 0.
2. Достаёт sudog из кэша, кладёт в него указатель на отправляемое значение (значение остаётся в стеке отправителя, копии пока нет) и ставит его в sendq.
3. Вызывает gopark: статус _Gwaiting, причина chan send, лок канала отпускается.
4. Управление уходит в schedule(). Поток M не блокируется, он подбирает следующую runnable-горутину и продолжает жечь процессор.
5. Когда придёт получатель, chanrecv найдёт наш sudog, скопирует значение напрямую из нашего стека в свой и вызовет goready.

«Блокировка по существу»

Так называют настоящую, семантическую блокировку: горутина не может продолжить, потому что логически ждёт события. Есть ещё «блокировка по реализации», это когда встал поток ОС. В Go на канале, мьютексе, WaitGroup и сетевом I/O блокируется только горутина: планировщик её снимает и переиспользует поток. А вот блокирующий syscall к диску, вызов через cgo или runtime.LockOSThread блокируют настоящий поток: P у него отберёт sysmon, но сам M будет стоять.

recvq устроен как обычный двусвязный список, а dequeue() берёт голову. Значит, при отправке одного значения его получит горутина, которая раньше всех припарковалась на этом канале. Отсюда канал и работает распределителем работы: N воркеров в for job := range jobs разберут задачи без дублей и без дополнительной синхронизации.

jobs := make(chan int)
for w := 1; w <= 3; w++ {
    go func(id int) {
        for j := range jobs {          // трое читают из одного канала
            fmt.Println("worker", id, "job", j)
        }
    }(w)
}
jobs <- 42        // ровно одну строку напечатает какой-то один worker
close(jobs)       // а вот это увидят все трое: broadcast через close

Вариант 1: close - сигнал «всем, один раз»

done := make(chan struct{})
// N горутин делают <-done и все просыпаются от одного close
close(done)

Работает мгновенно и для тех, кто ещё не успел подписаться: чтение из закрытого канала возвращается сразу. Упирается всё в одноразовость: повторно «раззакрыть» нельзя, данные передать нельзя (только факт). Именно так устроен ctx.Done(). Чтобы передать вместе с сигналом ещё и значение, используют пару: сначала записать значение в поле под мьютексом, потом закрыть канал. Читатель после пробуждения гарантированно увидит запись (close happens-before приём из закрытого канала).

Вариант 2: fan-out - по каналу на подписчика

type Broker[T any] struct {
    mu   sync.RWMutex
    subs map[chan T]struct{}
}

func (b *Broker[T]) Subscribe() (<-chan T, func()) {
    ch := make(chan T, 16)                 // буфер, чтобы медленный подписчик не тормозил всех
    b.mu.Lock()
    b.subs[ch] = struct{}{}
    b.mu.Unlock()
    return ch, func() {                    // отписка
        b.mu.Lock()
        delete(b.subs, ch)
        b.mu.Unlock()
        close(ch)
    }
}

func (b *Broker[T]) Publish(v T) {
    b.mu.RLock()
    defer b.mu.RUnlock()
    for ch := range b.subs {
        select {
        case ch <- v:                      // отправили
        default:                           // подписчик не успевает: дропаем, а не блокируем всех
        }
    }
}

select {
case ch <- v:
    // приняли
default:
    // не приняли: дропаем, считаем метрику, кладём в overflow
}

Почему select, а не len

select с default компилируется в selectnbsend → chansend(c, v, block=false): рантайм берёт лок канала и в одной критической секции и проверяет готовность, и выполняет отправку. Между «проверил» и «отправил» ничего вклиниться не может. Вариант if len(ch) < cap(ch) { ch <- v } распадается на две разные операции: между ними другая горутина заполнит буфер, и ты заблокируешься именно там, где обещал не блокироваться.

Таймаут на операцию с каналом

select {
case v := <-ch:
    return v, nil
case <-time.After(5 * time.Second):
    return zero, context.DeadlineExceeded
}

// В сервисе почти всегда лучше наследовать таймаут от вызывающего:
ctx, cancel := context.WithTimeout(parent, 5*time.Second)
defer cancel()
select {
case v := <-ch:
    return v, nil
case <-ctx.Done():
    return zero, ctx.Err()
}

Обёртка над функцией, которая не умеет отменяться

func withTimeout[T any](ctx context.Context, f func() (T, error)) (T, error) {
    type res struct {
        v   T
        err error
    }
    done := make(chan res, 1)          // буфер 1: горутина не зависнет, если мы ушли
    go func() {
        v, err := f()
        done <- res{v, err}
    }()
    select {
    case r := <-done:
        return r.v, r.err
    case <-ctx.Done():
        var zero T
        return zero, ctx.Err()         // а f() продолжает работать в фоне
    }
}

Цикл for v := range ch компилятор разворачивает ровно в for { v, ok := <-ch; if !ok { break }; ... }. Никаких других способов выйти у него нет: ни len(ch) == 0, ни таймаут его не завершат. Отсюда два практических следствия.

• Если канал не закрыть, горутина с range останется навсегда. Типовая утечка, и часто её не замечают, потому что программа продолжает работать.
• Если выходить надо ещё и по отмене контекста, range не подходит, нужен select.

// range: выход только по close
for v := range ch {
    process(v)
}
// сюда попадём, лишь когда
// кто-то сделает close(ch)

// select: выход по close или по отмене
for {
    select {
    case v, ok := <-ch:
        if !ok { return }
        process(v)
    case <-ctx.Done():
        return
    }
}

Правило закрытия и почему оно именно такое

Закрытие утверждает: «данных больше не будет». Знать это может только тот, кто данные производит. Если получатель закроет канал, любой продолжающий писать отправитель получит панику. Отсюда полный свод:

1. Писатель один: он и закрывает, обычно defer close(ch).
2. Писателей много: никто из них не закрывает, закрывает координатор после wg.Wait() в отдельной горутине.
3. Надо остановить писателя: шли отдельный канал done/ctx в обратную сторону, а не закрывай канал данных получателем.
4. Канал вообще можно не закрывать, если он больше не нужен: GC соберёт его вместе с hchan. Закрытие нужно только как сигнал.

Почему проверка не работает

// Так не работает: между проверкой и отправкой гонка.
if !isClosed(ch) {
    ch <- v      // между if и этой строкой канал могли закрыть -> panic
}

Более того, встроенного isClosed вообще нет. Узнать о закрытости можно единственным способом: попробовать прочитать, а это разрушающая операция.

Работающие подходы, по возрастанию надёжности

1. Дисциплина владения (правильный ответ). У канала один владелец: он создаёт, пишет и закрывает. Наружу отдаётся <-chan T, так что чужой код физически не может ни писать, ни закрывать. 90% проблем исчезает на этом шаге.
2. Отдельный done-канал. Сигнал остановки идёт навстречу потоку данных. Отправитель проверяет его в том же select, что и отправку:

   select {
   case ch <- v:
   case <-done:      // нам сказали остановиться: выходим, не закрывая ch
       return
   }

   Запомни: закрывается done, а не ch. Канал данных вообще может остаться незакрытым, его соберёт GC.
3. sync.Once на close. Если по архитектуре закрыть канал может несколько мест, остаётся один корректный вариант: обернуть закрытие:

   type SafeChan struct {
       ch   chan int
       once sync.Once
   }
   func (s *SafeChan) Close() { s.once.Do(func() { close(s.ch) }) }

   Это убирает панику «close of closed channel», но не убирает панику «send on closed channel»: отправитель по-прежнему может писать в уже закрытый канал.
4. Мьютекс вокруг отправки и закрытия. Полностью безопасно, но убивает саму идею канала: RWMutex, отправка под RLock, закрытие под Lock с флагом. Годится как аварийный вариант в чужом легаси.
5. recover в отправителе. Работает, но это признание в проигрыше: паника уже разрушила инварианты, значение потеряно, и такой код не проходит ревью.

Что делают len и cap

len(ch) читает поле qcount, cap(ch) читает dataqsiz, и оба без взятия c.lock. Data race по букве memory model тут нет (это выровненное чтение одного слова, и рантайм читает его напрямую), но есть race condition на уровне логики: между твоей проверкой и действием состояние канала меняют другие горутины.

// Опасно: TOCTOU, классическая race condition
if len(ch) < cap(ch) {
    ch <- v          // здесь буфер уже могли забить, заблокируемся
}

// Правильно: проверка и отправка атомарны под локом канала
select {
case ch <- v:
default:
}

// Допустимо: метрики, где неточность не критична
metrics.QueueDepth.Set(float64(len(ch)))

Как дочитать канал до конца перед завершением (drain)

// 1. Отправитель закрыл канал, лучший случай:
for v := range ch {         // сам выйдет, когда буфер опустеет
    handle(v)
}

// 2. Канал не закрыт, забираем только то, что уже лежит:
for {
    select {
    case v := <-ch:
        handle(v)
    default:
        return              // готового больше нет, уходим
    }
}

// 3. Дренаж с дедлайном: забрать хвост, но не ждать вечно
t := time.NewTimer(2 * time.Second)
defer t.Stop()
for {
    select {
    case v, ok := <-ch:
        if !ok { return }
        handle(v)
    case <-t.C:
        return              // хвост не успели: потерю принимаем осознанно
    }
}

• chan T двунаправленный, можно всё, включая close.
• chan<- T умеет отправку и close. Чтение не компилируется.
• <-chan T: только приём. Ни отправка, ни close не компилируются: invalid operation: cannot close receive-only channel.

Приведение работает только в сторону сужения и делается неявно при передаче аргумента. Обратно не выйдет даже через явный каст: chan<- int в chan int не приводится. Это и делает гарантию настоящей: получив <-chan T, вернуть себе право писать нельзя.

// Сигнатура сама документирует роль каждой стороны.
func produce(out chan<- Job)        { defer close(out); ... }  // может закрыть
func consume(in  <-chan Job)        { for j := range in { ... } }  // не может испортить
func pipe(in <-chan int) <-chan int { ... }                    // стадия конвейера

ch := make(chan Job)
go produce(ch)     // ch неявно сузился до chan<- Job
consume(ch)        // и до <-chan Job

Канал в канале

Тип chan chan T абсолютно легален, и на нём стоят два рабочих паттерна: «канал ответа внутри запроса» (см. схему выше) и «канал подтверждения остановки». Второй выглядит так:

// Просим воркер остановиться и ждём подтверждения, что он закончил.
type stopReq struct{ ack chan struct{} }

stop := make(chan stopReq)

go func() {                                  // воркер
    for {
        select {
        case r := <-stop:
            cleanup()
            close(r.ack)                     // «я всё, можешь идти дальше»
            return
        case j := <-jobs:
            handle(j)
        }
    }
}()

ack := make(chan struct{})
stop <- stopReq{ack}
<-ack                                        // синхронная остановка с подтверждением

Почему struct{}, а не bool

• unsafe.Sizeof(struct{}{}) == 0. В буферизированном канале на 1000 элементов буфер займёт 0 байт полезных данных вместо 1000; все нулевые значения указывают на runtime.zerobase, и memmove копирует 0 байт. Экономия честная, но в 99% случаев неважная.
• Важнее семантика. chan bool заставляет читателя гадать: а что значит false? «Остановись» или «не останавливайся»? С chan struct{} вопроса не возникает: значение неинформативно по типу, информативен только факт получения (или закрытия).
• Это идиома стандартной библиотеки: ctx.Done() <-chan struct{}, http.Server.Shutdown, все внутренние сигнальные каналы рантайма. map[T]struct{} как множество работает на той же идее.

Почему нельзя

makechan считает размер один раз: если elemsize == 0 или size == 0, выделяется только hchan; иначе hchan и буфер size * elemsize: если в элементах нет указателей, одной аллокацией подряд в памяти, иначе двумя. Поменять размер значило бы перевыделить буфер, переложить элементы, поправить sendx/recvx под локом и заодно испортить указатели sudog.elem. Команда Go сознательно оставила канал примитивом с фиксированной ёмкостью: неограниченная очередь прячет отсутствие backpressure, а это чаще баг, чем фича.

Если очень нужно

Два входных и выходных канала плюс горутина-диспетчер со слайсом. Весь трюк в том, чтобы выключать ветку отправки через nil-канал, когда очередь пуста (код выше, в теории главы). Свойства такой конструкции:

• in никогда не блокирует отправителя, очередь растёт в куче;
• порядок FIFO сохраняется;
• цена такая: лишняя горутина, лишняя передача через канал и неограниченный рост памяти, если потребитель медленнее продюсера.

Что важнее размера - владение

Отправляя указатель, ты отдаёшь владение объектом. Контракт должен быть явным: после ch <- p отправитель к *p не прикасается ни на чтение, ни на запись. Нарушишь, получишь гонку, которую race-детектор поймает, только если оба доступа реально совпали по времени в тестовом прогоне. То есть в проде она всплывёт через полгода. Со значением такого класса ошибок не существует физически.

// Опасно: буфер переиспользуется после отправки
buf := make([]byte, 4096)
for {
    n, _ := r.Read(buf)
    ch <- buf[:n]        // отправили заголовок слайса, массив общий
    // следующая итерация перезапишет то, что читает получатель
}

// Безопасно: копия на каждую отправку
for {
    n, _ := r.Read(buf)
    chunk := make([]byte, n)
    copy(chunk, buf[:n])
    ch <- chunk
}

// Безопасно и без аллокаций: буфер возвращается по второму каналу (пул)
free := make(chan []byte, 8)
b := <-free
n, _ := r.Read(b)
ch <- b[:n]              // получатель, закончив, вернёт b в free

type Request struct {
    Payload int
    Reply   chan<- Response          // направленный: воркер только пишет
}
type Response struct {
    Result int
    Err    error
}

type Pool struct {
    reqs chan Request
    wg   sync.WaitGroup
}

func NewPool(n int) *Pool {
    p := &Pool{reqs: make(chan Request)}
    p.wg.Add(n)
    for i := 0; i < n; i++ {
        go func() {
            defer p.wg.Done()
            for r := range p.reqs {      // выйдут все n, когда закроем reqs
                v, err := handle(r.Payload)
                r.Reply <- Response{v, err}   // не заблокируется: буфер 1
            }
        }()
    }
    return p
}

// Для вызывающего Call синхронный, внутри асинхронный.
func (p *Pool) Call(ctx context.Context, v int) (int, error) {
    reply := make(chan Response, 1)       // всё держится на буфере 1
    select {
    case p.reqs <- Request{v, reply}:
    case <-ctx.Done():
        return 0, ctx.Err()               // не смогли даже поставить задачу
    }
    select {
    case r := <-reply:
        return r.Result, r.Err
    case <-ctx.Done():
        return 0, ctx.Err()               // ушли, воркер допишет в буфер и освободится
    }
}

func (p *Pool) Close() { close(p.reqs); p.wg.Wait() }

Что здесь принципиально

• Буфер 1 у канала ответа. Без него брошенный по таймауту запрос навсегда подвешивает воркер. С ним воркер кладёт ответ в буфер, идёт за следующей задачей, а осиротевший канал забирает GC.
• Отмена на обоих select. Клиент может не успеть ни поставить задачу, ни дождаться ответа, поэтому отменяемы должны быть обе точки.
• Направленный тип chan<- Response в структуре: воркер физически не может закрыть чужой канал ответа.
• Закрытие reqs как сигнал остановки всем воркерам сразу, а wg.Wait() как гарантия, что все доработали.

// high приоритетнее low: сначала пытаемся забрать из high неблокирующе.
for {
    select {
    case v := <-high:
        handle(v)
    case v := <-low:
        // прежде чем обработать low, ещё раз проверим high
        select {
        case h := <-high:
            handle(h)
            // low-значение уже забрано из канала, «вернуть» его нельзя,
            // поэтому либо обработать позже, либо держать свою очередь
            handle(v)
        default:
            handle(v)
        }
    case <-ctx.Done():
        return
    }
}

Более чистый вариант - сначала дренаж high

for {
    // 1) выгребаем весь high, пока он не опустеет
    for {
        select {
        case v := <-high:
            handle(v)
            continue
        default:
        }
        break
    }
    // 2) high пуст, блокируемся на всём сразу
    select {
    case v := <-high:
        handle(v)
    case v := <-low:
        handle(v)
    case <-ctx.Done():
        return
    }
}

Что именно текло

time.After(d) = NewTimer(d).C. Наружу отдают только канал, ссылки на сам *Timer у тебя нет, значит Stop() вызвать невозможно. До Go 1.23 таймер лежал в per-P куче таймеров рантайма и удерживал канал до истечения d. Если select ушёл в другую ветку, таймер всё равно досиживал свой срок. При цикле в 10 000 итераций в секунду и time.After(time.Minute) в пике жило до 600 000 таймеров, а это больше сотни мегабайт (замер на go1.23, arm64, в режиме старых таймеров: ~150 МБ) и заметный рост стоимости операций с кучей таймеров. С Go 1.23 таймер с каналом стоит в куче, только пока на его канале кто-то ждёт: select ушёл в другую ветку, и таймер из кучи убирается, дальше это обычный мусор. Остаются лишние аллокации на каждой итерации (на go1.27 - три, около 250 байт).

// Плохо
for {
    select {
    case v := <-ch:
        handle(v)
    case <-time.After(time.Minute):
        return
    }
}

// Хорошо
t := time.NewTimer(time.Minute)
defer t.Stop()
for {
    select {
    case v := <-ch:
        handle(v)
        if !t.Stop() { <-t.C }
        t.Reset(time.Minute)
    case <-t.C:
        return
    }
}

Три штатные замены

1. Один time.Timer на цикл со Stop/Reset, если таймаут отсчитывается заново после каждого события (idle timeout).
2. context.WithTimeout берут, когда дедлайн общий на всю операцию и должен пробрасываться вглубь. ctx.Done() в select, один defer cancel(), никаких лишних таймеров: cancel честно останавливает внутренний таймер.
3. time.Ticker нужен для периодического такта, а не для однократного дедлайна. Привычка defer ticker.Stop() осталась с тех времён, когда неостановленный тикер будил рантайм вечно (до Go 1.23); теперь он будит рантайм, только пока его канал кто-то ждёт, но код со Stop корректен на любой версии.