8 сентября 2026Команда Сарнас

Каналы в Go: как горутины общаются друг с другом

Введение: проблема обмена данными между потоками

Взгляните на классический пример из мира Java или C++: вы опрашиваете список URL-адресов. Данные приходится защищать мьютексом, а функция Poller разбухает до целой страницы кода — и это ещё без самой логики опроса! Вы блокируете структуру, ищете нужный ресурс, снимаете блокировку, потом снова блокируете для обновления. Хрупко, многословно, а главное — вы постоянно думаете о том, кто и когда имеет доступ к данным.

Go предлагает радикально иной подход. Вместо блокировок — каналы, по которым горутины передают друг другу ссылки на данные. Ключевая идея сформулирована в Effective Go как «Do not communicate by sharing memory; instead, share memory by communicating» — не общайтесь через разделяемую память, а разделяйте память через общение. В этой модели только одна горутина владеет данными в конкретный момент времени, и блокировки просто не нужны.

Посмотрите, как преображается тот же Poller на Go:

type Resource string

func Poller(in, out chan *Resource) {
    for r := range in {
        // опрос URL
        out <- r
    }
}

Вместо страницы кода — несколько строк. Вся служебная логика синхронизации исчезла, осталось только существенное. Но как именно работает эта передача данных, и какие возможности она открывает для построения конкурентных программ? Разберём по шагам.

Традиционный подход: разделяемая память и блокировки

Сравним два подхода на одном примере — журналировании опроса списка ресурсов. Языки вроде Java, C++ или Python традиционно полагаются на разделяемую память: структура данных плюс мьютекс, который защищает доступ к ней. В исходном коде на Java или C++ подобный Poller превращается в функцию примерно на страницу кода, и это только управление доступом, без самой логики опроса URL.

Что здесь происходит шаг за шагом? Сначала берём блокировку и ищем самый старый по времени опроса ресурс. Помечаем его флагом «идёт опрос». Снимаем блокировку. Затем опрашиваем URL. Потом снова берём блокировку, чтобы скорректировать метку времени и сбросить флаг. И так в цикле.

На каждом из этих шагов вы программируете не логику задачи, а дисциплину доступа. Забыли блокировку перед чтением — получили гонку данных. Удерживаете блокировку слишком долго — снизили параллелизм. Реализация очереди в Python через потокобезопасные структуры вроде Queue упрощает жизнь, но не устраняет проблему: вы по-прежнему думаете о том, кто владеет данными в конкретный момент.

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

Идиома Go: передавайте данные через каналы

Парадигма Go формулируется одной фразой из Effective Go: «Do not communicate by sharing memory; instead, share memory by communicating». Это не просто лозунг, а практический принцип проектирования, который меняет саму структуру конкурентного кода.

В традиционных языках (Java, C++, Python) конкурентность строится вокруг разделяемой памяти: несколько потоков обращаются к общим структурам данных, а доступ к ним регулируется блокировками. Каждый поток «владеет» мьютексом, прежде чем трогать данные. Такой подход порождает множество нюансов: конкуренция за блокировки, тонкости их удержания и риск взаимных блокировок (deadlocks). Программист вынужден думать не только о логике задачи, но и о дисциплине синхронизации.

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

Чтобы понять разницу, сравните объем кода. Классический Poller на Java или C++ занимает около страницы: захват мьютекса, поиск свободного ресурса, обновление полей, освобождение блокировки. Вся эта логика — только управление доступом, а сама операция опроса URL занимает всего пару строк. В Go та же функция сокращается до пяти строк: получаете ресурс из канала in, обрабатываете его, отправляете в канал out. Книжные данные (polling, lastPolled) просто исчезают — они не нужны, потому что нет конфликтов доступа.

Альтернативы, вроде потокобезопасных структур данных из стандартных библиотек Python или собственных пулов потоков, тоже требуют настройки и аккуратности. Они лишь маскируют проблему, но не устраняют её — вы всё равно думаете о синхронизации, просто на более высоком уровне абстракции.

Структура Resource и синхронизация с мьютексом

В классическом Java- или C++-коде конкурентная программа, опрашивающая список URL-адресов, строится на структурах, которые инкапсулируют и данные, и служебную информацию о доступе к ним. Типичное объявление выглядит так: структура Resource хранит сам URL, булев флаг polling (идёт ли сейчас опрос) и время последней проверки lastPolled. Но это ещё не всё. Отдельно объявляется контейнер Resources, внутри которого лежит слайс указателей на Resource и мьютекс lock. Зачем мьютекс в контейнере? Потому что без него несколько потоков-опросчиков Poller, работающих одновременно, начнут читать и менять поля Resource параллельно — а это гонка данных.

Посмотрим, во что превращается функция Poller при таком подходе. Она запускается в нескольких потоках, и каждый цикл её работы состоит из трёх этапов. Сначала поток блокирует мьютекс, чтобы эксклюзивно пройтись по всему слайсу: найти Resource с наименьшим lastPolled и одновременно не занятый другим потоком (проверить флаг polling). Только под блокировкой можно безопасно перебирать список. Найденный элемент помечается как polling = true, и мьютекс освобождается — иначе другие потоки будут ждать, пока идёт сам сетевой запрос, что бессмысленно. После завершения опроса поток снова берёт блокировку — теперь уже для записи: сбросить флаг и обновить время. Как видите, даже в таком упрощённом примере мьютекс захватывается два раза за одну итерацию, а сама функция без логики сетевого запроса разрастается почти на страницу кода.

Обратите внимание на одну деталь: половина полей в Resource — это не про саму задачу, а про координацию потоков. Поле polling вообще не несёт бизнес-смысла; оно существует исключительно для того, чтобы два разных Poller не взяли один и тот же URL одновременно. Дисциплина синхронизации — ручная и хрупкая: забыли снять блокировку в одном месте — получите взаимную блокировку; сняли слишком рано — получите гонку. Каждая мысль о том, как структурировать данные, автоматически превращается в мысль о том, как защитить их от конкурентного доступа. И эти две проблемы приходится решать одновременно, в одном и том же объявлении типа.

Функция Poller с мьютексом: сложности и ограничения

Посмотрите на условие if r == nil { continue }. Оно выглядит безобидно, но скрывает серьёзный дефект. Когда пул ресурсов исчерпан, поток просто прокручивает пустой цикл, захватывая и освобождая мьютекс в холостую. Такое «активное ожидание» сжигает CPU и не даёт другим потокам продуктивно работать. Хуже того, в реальном коде это условие часто вообще отсутствует — и тогда разыменование r при r == nil роняет программу по panике.

Вторая проблема — громоздкость. Только для выбора ресурса и пометки его занятым требуется:

Захватить мьютекс.
Пройти по всем Resource, сверяя lastPolled и пропуская те, где polling == true.
Установить флаг polling.
Освободить мьютекс.

Затем — отдельный цикл захвата для обновления полей после опроса. И это не считая самого кода опроса URL, который «сам по себе занял бы всего несколько строк» — как точно подмечает автор в статье. Итог: около страницы кода, где логика опроса URL тонет в синхронизационной обвязке. А оптимизации вроде сортировки по lastPolled пришлось бы добавлять прямо в критическую секцию — мьютекс был бы занят ещё дольше.

Сравните это с тем, сколько логики реально нужно: «возьми URL из канала, опроси, отправь результат в другой канал». Аналогия из жизни: вместо того чтобы самому вести очередь в поликлинике и следить, кто зашёл в кабинет, вы просто ждёте, когда вас позовут по номерку. Канал работает как этот номерок — он сам гарантирует, что каждый ресурс обработает ровно один Poller, без явной синхронизации и без риска опустевшего пула.

Реализация Poller с каналами: простота и надёжность

Теперь посмотрите, как тот же функционал выглядит в идиоматичном Go. Вместо структуры с полями-флагами и мьютексом внутри — два канала и функция на шесть строк:

type Resource string

func Poller(in, out chan *Resource) {
    for r := range in {
        // опрос URL
        out <- r
    }
}

Вся деликатная логика исчезла. Нет ни одного условного перехода для выбора ресурса, нет пометок занятости. Resource превратился из структуры с bookkeeping-полями в простой строковый тип — а точнее, в ссылку на данные. Канал сам гарантирует, что в каждый момент времени ресурсом владеет ровно одна горутина.

Сравните объём кода: прежняя версия занимала около страницы и требовала доработки. Здесь остались только важные части: получить ресурс из канала, опросить, отправить обратно. Всё.

Ключевой сдвиг мышления: вы не _координируете_ доступ через блокировки — вы _передаёте_ владение. Это работает, потому что природа задачи последовательная: ресурс либо ожидает опроса, либо опрашивается. Каналы выражают это напрямую, без промежуточных состояний, которые надо защищать.

Этот пример даёт намёк на силу простых языковых конструкций. Но остаются открытые вопросы: как масштабировать пул ресурсов, когда число воркеров меняется динамически? Как корректно закрыть каналы при завершении? Полный разбор идиоматичной программы с этими идеями доступен в Codewalk по теме, а в конце статьи вернёмся к общим выводам.

Практический пример и дальнейшее чтение

Примеры выше умышленно сокращены: в них нет обработки ошибок, таймаутов и завершения работы. Если хотите увидеть полную программу с теми же принципами — откройте официальный Codewalk «Share Memory By Communicating» на go.dev. Там разбирается законченный пример с идиоматичной структурой программы.

Полезно также уточнить разницу между concurrency и parallelism. На практике их постоянно путают, хотя понятия разные: concurrency — про структуру программы из независимо выполняющихся процессов, а parallelism — про одновременное выполнение вычислений. Чтобы разобраться, посмотрите слайды одноимённого доклада Роба Пайка с конференции Heroku Waza — ссылка на них есть на go.dev.

Для систематического изучения самих примитивов — паттернов работы с горутинами и каналами — обратите внимание на доклад «Go concurrency patterns» с видео на YouTube и набором слайдов. Он описывает общие конструкции, которые вы сможете переиспользовать в своих проектах.

Заключение: ключевые выводы и практический совет

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

Сравните сами: в традиционном подходе код опроса URL занимает около страницы и требует аккуратности с блокировками. Версия на каналах умещается в несколько строк и — что важнее — состоит только из логики, которая действительно нужна. Вся служебная работа по координации исчезает, потому что структура данных перестаёт носить в себе флаги состояния.

Практический совет: начните с малого. Возьмите любую задачу, где сейчас используется мьютекс, и попробуйте переписать её через каналы. Вы сразу заметите, как упрощается код. Если чувствуете, что застреваете — откройте Codewalk «Share Memory By Communicating» на go.dev. Там показан законченный пример, на котором удобно сверять своё понимание.

Спасибо всем, кто читал и дополнял статью. Мы учли замечания в комментариях и внесли уточнения о разнице между concurrency и parallelism, а также добавили ссылки на материалы для дальнейшего изучения.