避免子进程达max_restarts时DynamicSupervisor停止运行

这问题我之前做后台任务集群的时候也碰到过，确实挺闹心的——就因为某个子进程反复崩溃，整个DynamicSupervisor直接退出，把其他正常跑的任务全给带停了。分享几个我亲测有效的解决办法，你可以根据自己的场景选：

1. 调大监督者的重启阈值（最简单快速） #

DynamicSupervisor本质是Supervisor的子类，默认在5秒内重启超过3次就会触发自我终止。你可以在启动时把这个阈值调得宽松一些，比如把重启次数设高、时间窗口拉长，这样很难触发监督者退出：

{:ok, supervisor_pid} = DynamicSupervisor.start_link(
  strategy: :one_for_one,
  restart: :transient,  # 保留你的原重启策略
  max_restarts: 100,    # 1小时内允许重启100次
  max_seconds: 3600
)

这个办法适合那些子进程只是偶尔崩溃、不是无限循环挂掉的场景，优点是不需要改业务代码，几分钟就能搞定。

2. 让子进程以“正常退出”的方式结束（从根源减少重启计数） #

:transient策略下，只有子进程异常退出（退出原因不是:normal、:shutdown或{:shutdown, _}）时，监督者才会重启它。所以如果你的子进程是因为预期内的错误崩溃，不如直接让它以:normal退出，这样既不会被重启，也不会积累重启次数：

defmodule MyBackgroundWorker do
  use GenServer

  def start_link(task_args) do
    GenServer.start_link(__MODULE__, task_args)
  end

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

  @impl true
  def handle_info(:execute_task, state) do
    try do
      # 执行你的业务任务
      run_business_task(state)
      {:noreply, state}
    rescue
      e in ExpectedError ->
        # 预期内的错误，标记为正常退出
        {:stop, :normal, state}
    end
  end

  defp run_business_task(state) do
    # 你的任务逻辑
  end
end

这样即使任务失败，子进程是“正常退出”，监督者不会重启它，自然也不会触发重启次数超限的问题。

3. 手动接管重启逻辑（最灵活可控） #

如果上面两种办法都不符合你的需求，比如你需要精确控制每个子进程的重启次数，那可以完全接管重启逻辑：把DynamicSupervisor的重启策略改成:temporary（让它不自动重启任何子进程），然后自己写一个监控模块来管理子进程的退出和重启：

第一步：启动DynamicSupervisor时用:temporary #

{:ok, supervisor_pid} = DynamicSupervisor.start_link(
  strategy: :one_for_one,
  restart: :temporary,  # 禁用自动重启
  name: MyApp.DynamicSupervisor
)

第二步：写一个WorkerManager来监控和重启子进程 #

defmodule MyApp.WorkerManager do
  use GenServer

  def start_link(_opts) do
    GenServer.start_link(__MODULE__, %{}, name: __MODULE__)
  end

  # 对外提供启动子进程的接口
  def start_worker(task_args) do
    GenServer.call(__MODULE__, {:start_worker, task_args})
  end

  @impl true
  def init(_) do
    # 存储子进程的重启计数和启动参数
    {:ok, %{restart_counts: %{}, worker_args: %{}}}
  end

  @impl true
  def handle_call({:start_worker, args}, _from, state) do
    case DynamicSupervisor.start_child(MyApp.DynamicSupervisor, {MyBackgroundWorker, args}) do
      {:ok, pid} ->
        # 监控子进程，存储它的启动参数
        Process.monitor(pid)
        new_state = state
                    |> put_in([:worker_args, pid], args)
                    |> put_in([:restart_counts, pid], 0)
        {:reply, {:ok, pid}, new_state}
      error ->
        {:reply, error, state}
    end
  end

  @impl true
  def handle_info({:DOWN, ref, :process, pid, reason}, state) do
    Process.demonitor(ref, [:flush])
    args = Map.get(state.worker_args, pid)
    current_count = Map.get(state.restart_counts, pid, 0)

    cond do
      # 正常退出，清理记录
      reason in [:normal, :shutdown, {:shutdown, _}] ->
        new_state = state
                    |> Map.update!(:worker_args, &Map.delete(&1, pid))
                    |> Map.update!(:restart_counts, &Map.delete(&1, pid))
        {:noreply, new_state}

      # 重启次数未达上限，重新启动
      current_count < 3 ->
        case DynamicSupervisor.start_child(MyApp.DynamicSupervisor, {MyBackgroundWorker, args}) do
          {:ok, new_pid} ->
            Process.monitor(new_pid)
            new_state = state
                        |> Map.delete(:worker_args, pid)
                        |> Map.put(:worker_args, new_pid, args)
                        |> Map.delete(:restart_counts, pid)
                        |> Map.put(:restart_counts, new_pid, current_count + 1)
            {:noreply, new_state}
          _ ->
            # 启动失败，清理记录
            new_state = state
                        |> Map.update!(:worker_args, &Map.delete(&1, pid))
                        |> Map.update!(:restart_counts, &Map.delete(&1, pid))
            {:noreply, new_state}
        end

      # 重启次数超限，不再重启
      true ->
        new_state = state
                    |> Map.update!(:worker_args, &Map.delete(&1, pid))
                    |> Map.update!(:restart_counts, &Map.delete(&1, pid))
        {:noreply, new_state}
    end
  end
end

这个方案完全由你控制每个子进程的重启次数，DynamicSupervisor永远不会因为重启次数过多而退出，其他正常子进程也能继续运行，适合复杂的后台任务场景。

内容的提问来源于stack exchange，提问作者Svilen