Что такое GenServer и какие callbacks он определяет?

Минимальный пример

defmodule Counter do
  use GenServer

  # --- Client API ---

  def start_link(initial \\ 0) do
    GenServer.start_link(__MODULE__, initial, name: __MODULE__)
  end

  def increment, do: GenServer.cast(__MODULE__, :increment)
  def get_value, do: GenServer.call(__MODULE__, :get)

  # --- Server Callbacks ---

  @impl true
  def init(initial) do
    {:ok, initial}
  end

  @impl true
  def handle_call(:get, _from, state) do
    {:reply, state, state}
  end

  @impl true
  def handle_cast(:increment, state) do
    {:noreply, state + 1}
  end

  @impl true
  def handle_info(:reset, _state) do
    {:noreply, 0}
  end
end

GenServer: что это и какие callbacks он определяет

GenServer (Generic Server) — это behaviour в OTP, который абстрагирует паттерн клиент-сервер на основе процессов. GenServer инкапсулирует состояние, сериализует доступ к нему и интегрируется с supervision tree. Под капотом это Erlang-процесс с бесконечным циклом receive.

Все callbacks GenServer

init/1

Вызывается при старте процесса. Получает аргумент из start_link/1. Должен вернуть начальное состояние.

@impl true
def init(args) do
  # Варианты возврата:
  {:ok, initial_state}
  {:ok, initial_state, {:continue, :load_data}}  # отложенная инициализация
  {:ok, initial_state, timeout_ms}                # timeout в миллисекундах
  :ignore                                          # не запускать процесс
  {:stop, reason}                                  # остановить с ошибкой
end

handle_call/3

Синхронный запрос. Клиент блокируется до получения ответа. Три аргумента: запрос, {pid, ref} отправителя, текущий state.

@impl true
def handle_call({:get_user, id}, _from, state) do
  user = Map.get(state.users, id)
  {:reply, user, state}
  # или {:reply, user, new_state, {:continue, :cleanup}}
end

handle_cast/2

Асинхронный запрос. Клиент не ждёт ответа. Используется для операций, результат которых не нужен немедленно.

@impl true
def handle_cast({:add_user, user}, state) do
  new_state = Map.put(state, user.id, user)
  {:noreply, new_state}
end

handle_info/2

Обрабатывает любые сообщения, отправленные через send/2 или Process.send_after/3, а также системные сообщения (DOWN, EXIT). Это «прочие сообщения».

@impl true
def handle_info(:tick, state) do
  # Периодическая задача
  Process.send_after(self(), :tick, 1_000)
  {:noreply, do_work(state)}
end

@impl true
def handle_info({:DOWN, _ref, :process, pid, reason}, state) do
  # Мониторинг упавшего процесса
  {:noreply, remove_worker(state, pid)}
end

handle_continue/2

Выполняется сразу после init/1 или другого callback, но до следующего сообщения из queue. Используется для тяжёлой инициализации без блокировки start_link.

@impl true
def init(_args) do
  {:ok, %{}, {:continue, :load_from_db}}
end

@impl true
def handle_continue(:load_from_db, state) do
  data = Repo.all(MyModel)
  {:noreply, %{state | data: data}}
end

terminate/2

Вызывается перед остановкой процесса (если причина не :normal/:shutdown и trap_exit включён). Используется для cleanup.

@impl true
def terminate(reason, state) do
  Logger.warning("Counter stopping: #{inspect(reason)}")
  :ok
end

code_change/3

Вызывается при горячем обновлении кода через :sys.change_code. Позволяет мигрировать старый state в новую структуру.

@impl true
def code_change(_old_vsn, state, _extra) do
  # Мигрировать старый state (map) в новую структуру (struct)
  {:ok, struct(NewState, state)}
end

Подводные камни

• handle_call блокирует весь GenServer на время выполнения — длинные операции (DB-запросы, HTTP) нужно делегировать в Task, иначе все вызовы встают в очередь.
• Не определённый handle_info/2 для всех типов сообщений — неожиданные сообщения накапливаются в inbox и вызывают утечку памяти.
• Тяжёлая инициализация в init/1 блокирует start_link и, соответственно, весь supervision tree — использовать handle_continue.
• Использование GenServer.call из самого GenServer (рекурсивный вызов) приводит к дедлоку — процесс ждёт ответа от себя.
• Забывают передать name: в start_link — без имени нельзя обратиться к GenServer по имени, только по PID, который меняется при рестарте.
• Дефолтный timeout в GenServer.call/3 — 5 секунд. При медленных операциях нужно явно задать timeout или использовать cast.
• Хранение больших данных в state GenServer — они копируются при каждом входящем сообщении, что создаёт нагрузку на GC.
• Игнорирование @impl true — без него компилятор не предупредит о неверной сигнатуре callback, и функция просто не будет вызвана.

• Сводить genserver callbacks к названию метода без lifecycle и failure path.
• Игнорировать модель runtime: Elixir компилируется в BEAM bytecode и наследует процессы, message passing, supervision и hot-code friendly модель Erlang VM.
• Не отделять validation, authorization, transaction boundary и business logic.

• Объясняет genserver callbacks через конкретную точку lifecycle в Elixir.
• Приводит корректный минимальный пример без вымышленных методов или callbacks.
• Называет edge cases: пустые значения, ошибки, транзакции, безопасность или concurrency.