Erlang进程message queue存不匹配消息是否会引发轻微内存泄漏？

Great question — 这绝对是Erlang开发里很容易踩的一个坑，咱来掰扯清楚：

结论先行：是的，这种情况不仅会引发轻微内存泄漏，放任不管的话还会演变成严重的系统故障

为什么会泄漏？ #

Erlang每个进程的消息队列就是个实打实的内存缓冲区，只要消息没被匹配处理，就会一直待在队列里占着内存。如果你的进程持续接收它根本处理不了的消息（比如模式匹配完全不搭的消息），队列只会越来越长，进程占用的内存也会持续飙升。

举个直观的例子：假设你写了个进程，只处理{greet, Name}格式的消息，结果别的进程一个劲给它发{farewell, Id}或者乱码二进制数据。你用erlang:process_info(Pid, message_queue_len)查一下，会看到队列长度一直在涨；再用erlang:process_info(Pid, memory)看进程内存，绝对是一路走高的。

怎么避免这个问题？ #

给你几个实用的解决方案：

• 加兜底匹配模式：在进程的消息循环最后加一个_ -> handle_unexpected_msg()的分支，要么直接丢弃不匹配的消息，要么打个日志再清掉。比如：

  loop() ->
      receive
          {greet, Name} -> io:format("Hello ~p!~n", [Name]), loop();
          _ -> % 兜底处理所有不匹配的消息
              error_logger:warning_msg("Received unexpected message~n"),
              loop()
      end.
  

• 设置队列长度上限：用erlang:process_flag(message_queue_len_limit, Limit)给进程设个队列阈值，当队列长度超过这个值时，新消息会被自动丢弃（高版本Erlang还支持自定义回调逻辑）。
• 从源头管控：尽量保证发送消息的进程只发送目标进程能处理的消息类型，比如在发送前做类型检查，或者约定好消息协议。

额外提醒 #

有时候这种泄漏是“隐性”的——比如进程偶尔收到几条不匹配的消息，短期内看不出问题，但跑几个月后队列会慢慢膨胀到离谱的大小，某天突然把节点内存撑爆。所以从设计阶段就把这种情况考虑进去，比事后救火靠谱多了。

内容的提问来源于stack exchange，提问作者Alex. Smith