Erlang 并发：OTP 与 gen_server

Erlang 是一门为并发而生的语言。它的并发模型不同于传统的操作系统线程，而是一种轻量级的"Actor 模式"——每个进程都有独立的内存空间，进程之间通过消息传递通信。这种设计让 Erlang 程序天然具备高容错、高可扩展的特性。

OTP（Open Telecom Platform）是 Erlang 的应用平台，它提供了一套成熟的设计模式和抽象库，让开发者无需从零构建并发应用。其中，gen_server 是 OTP 框架中最核心的行为模式之一，专门用于实现"客户端-服务器"架构的进程。

为什么需要 OTP 和 gen_server

如果你直接用 Erlang 的 spawn 函数创建进程当然也可以，但很快会遇到一堆问题：如何处理进程崩溃？如何实现超时机制？如何保证代码结构的可维护性？OTP 框架正是为了解决这些痛点而生的。

gen_server 将通用逻辑封装成框架代码，你只需要专注于实现业务回调。它提供了一套标准的接口：init、handle_call（同步调用）、handle_cast（异步调用）、handle_info（处理其他消息）。这种分离让代码既整洁又易于测试。

第一个 gen_server：计数器实现

让我们从一个完整的例子开始——实现一个简单的计数器服务，支持增加、减少、查询三个操作。

1. 定义回调模块

-module(my_counter).
-behaviour(gen_server).

% API
-export([start/0, increment/0, decrement/0, get/0]).

% gen_server 回调
-export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2]).

start() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

increment() ->
    gen_server:cast(?MODULE, increment).

decrement() ->
    gen_server:cast(?MODULE, decrement).

get() ->
    gen_server:call(?MODULE, get).

init([]) ->
    {ok, 0}.  % 初始状态为 0

handle_cast(increment, State) ->
    {noreply, State + 1};

handle_cast(decrement, State) ->
    {noreply, State - 1}.

handle_call(get, _From, State) ->
    {reply, State, State};

handle_call(_Request, _From, State) ->
    {reply, ok, State}.

handle_info(_Info, State) ->
    {noreply, State}.

terminate(_Reason, _State) ->
    ok.

2. 编译并测试

c(my_counter).
{ok, Pid} = my_counter:start().
my_counter:increment().
my_counter:increment().
my_counter:get().  % 返回 2
my_counter:decrement().
my_counter:get().  % 返回 1

整个过程只需十几行代码，你就拥有了一个支持并发的计数器服务。多个进程可以同时调用 increment/0 和 get/0，Erlang 的进程调度器会自动处理并发安全问题——因为每个 gen_server 进程都是顺序处理消息的。

深入理解 gen_server 的消息处理流程

gen_server 的核心是一个消息队列。当你调用 gen_server:call/2 或 gen_server:cast/2 时，请求被发送到目标进程的邮箱。gen_server 内部的主循环每次从邮箱取出一条消息，根据消息类型调用对应的回调函数。

理解这个流程非常重要。当你需要实现一个异步通知机制时，可以直接向 gen_server 进程发送消息：

Pid = whereis(my_counter),
Pid ! {reset, self()}.

然后在 handle_info 中处理这个消息：

handle_info({reset, Caller}, State) ->
    Caller ! {reset_done, State},
    {noreply, 0}.

错误处理与监督树

OTP 的真正强大之处在于它与监督树（Supervision Tree）的无缝集成。在真实项目中，你不会单独启动一个 gen_server，而是将它放在一个监督者（Supervisor）的管控之下。

-module(my_sup).
-behaviour(supervisor).

-export([start_link/0, init/1]).

start_link() ->
    supervisor:start_link({local, ?MODULE}, ?MODULE, []).

init([]) ->
    SupFlags = #{strategy => one_for_one, intensity => 10, period => 60},
    ChildSpecs = [#{id => my_counter, start => {my_counter, start, []}}],
    {ok, {SupFlags, ChildSpecs}}.

这个监督者配置了 one_for_one 策略——如果计数器进程崩溃，监督者会自动重启它。更复杂的场景可以采用 one_for_all（一个子进程崩溃，全部重启）或 rest_for_one（崩溃进程之后的进程重启）。

这种"让它崩溃"（Let It Crash）的哲学是 Erlang 设计的精髓。开发者不需要编写大量防御性代码，而是假设进程随时可能失败，由 OTP 框架负责恢复。

性能优化与最佳实践

在实际应用中，需要注意几个关键点。

超时控制是必须设置的。gen_server:call 默认会无限等待，如果对端进程挂起，调用方将永远阻塞。安全的做法是设置超时时间：

gen_server:call(Pid, get, 5000).  % 最多等待 5 秒

批量操作能显著提升性能。如果你需要一次性增加 100 次计数器，不要调用 100 次 cast，而是设计一个批量接口：

increment_by(N) ->
    gen_server:cast(?MODULE, {increment_by, N}).

handle_cast({increment_by, N}, State) ->
    {noreply, State + N}.

状态序列化在分布式场景下尤为重要。gen_server 的状态只存在于单个 Erlang 节点内存中，如果需要跨节点共享，需要考虑使用 ets 表或 mnesia 数据库。

总结

OTP 框架和 gen_server 行为模式将 Erlang 的并发优势转化为可复用的工程实践。通过遵循 OTP 的设计约定，你可以快速构建出容错能力强、易于维护的并发系统。从一个简单的计数器开始，逐步扩展到复杂的监督树架构——这就是 Erlang 思维方式的魅力所在。