使用Erlang Application模块动态维护全局状态的弊端及疑问

我有一个处理HTTP请求的模块，维护着一组HTTP请求处理器，希望通过应用环境（application env）注册和获取这些处理器，示例代码如下：

start() ->
  % Init default handlers
  application:set_env(?REQUEST_HANDLER_MODULES, [foo_handler, bar_handler]).

add_http_request_handler(Module) ->
  % Register handler at runtime
  Modules = application:get_env(?REQUEST_HANDLER_MODULES),
  application:set_env(?REQUEST_HANDLER_MODULES, [Module|Modules]).

handle_request(Req) ->
  Modules = application:get_env(?REQUEST_HANDLER_MODULES),
  handle_request(Req, Modules, {}).

handle_request(Req, [], Agg) ->
  Agg;
handle_request(Req, [M|L], Agg) ->
  handle_request(Req, L, M:handle(Req, Agg)).

请问：

1. 使用application:get_env / application:set_env动态维护全局状态存在哪些弊端？
2. 每次调用application:get_env是否需要与应用进程进行一次往返通信？
3. 这种实现方式是否属于函数式编程反模式？

回答 #

1. 动态维护全局状态的弊端 #

• 竞态条件风险：多个进程同时调用add_http_request_handler时，会触发读取-修改-写入的竞态问题，导致处理器列表丢失更新。比如进程A和B同时读取到相同的初始列表，各自添加新模块后写入，最终只会保留其中一个进程的修改结果。
• 无事务支持：application:set_env不提供事务能力，若更新过程中出现异常，无法回滚到之前的状态，可能导致状态不一致。
• 调试追踪困难：全局状态的变更分散在各个进程中，没有统一的变更记录入口，出现问题时很难定位是哪个进程、在什么时机修改了状态。
• 扩展性差：如果后续需要对处理器列表做复杂操作（比如按优先级排序、批量删除），直接操作应用环境会让逻辑变得混乱，难以维护。
• 破坏可测试性：模块行为依赖外部全局环境，无法保证相同输入得到相同输出，增加了单元测试的复杂度。

2. application:get_env的通信机制 #

是的，每次调用application:get_env都会与**应用的根进程（application master）**进行一次进程间通信。应用环境的状态由应用进程维护，其他进程要获取或修改该状态，必须通过发送消息与应用进程交互，频繁调用会带来一定性能开销，高并发场景下可能成为瓶颈。

3. 是否属于函数式编程反模式 #

这种实现确实属于函数式编程的反模式，核心原因如下：

• 引入可变全局状态：函数式编程推崇不可变数据与纯函数，全局可变状态会让代码行为变得不可预测，难以推理。
• 违反引用透明性：handle_request的输出依赖外部环境状态，相同的请求输入可能因环境变化得到不同结果，破坏了引用透明性原则。
• 限制并行安全：全局状态的存在需要额外处理同步逻辑，而函数式编程的优势之一就是天然支持安全并行处理。

更符合函数式风格的做法是将处理器列表封装在专用的服务器进程（如gen_server）中，通过消息传递处理状态的查询与更新，既保证状态修改的原子性，也让状态变更逻辑集中可控。

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