链接与监视器详解
区分链接与监视器，并理解它们在进程监管和传播退出信号中的作用。
链接与监视器详解 是 CoddyKit 上的免费 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程共包含 4 节课。
本课时的部分内容尚未翻译，以英文显示。
Introduction to Process Faults
Erlang processes are designed to be isolated. But what happens when one process crashes? How do other processes know, and how can they react?
Understanding how failures propagate is key to building fault-tolerant systems in Erlang. This lesson introduces two fundamental mechanisms: links and monitors.
Process Linking Explained
A link is a bidirectional connection between two Erlang processes. It's like holding hands: if one process goes down (exits), it sends an exit signal to all linked processes.
- Links are created with
spawn_link/1,2,3,4. - If a process linked to another process exits normally, the exit signal is
normal. - If it exits with an error, the exit signal carries the reason for the crash.
Linking: Default Crash Propagation
By default, if a process receives an exit signal (other than normal) from a linked process, it will also terminate with the same reason. This is known as crash propagation.
Try running this example. The child process crashes, and because the parent is linked, it also crashes!
-module(link_example).
-export([start/0]).
start() ->
ParentPid = self(),
io:format("Parent (~p) starting...~n", [ParentPid]),
ChildPid = spawn_link(fun() -> child_process(ParentPid) end),
io:format("Parent (~p) linked to child (~p).~n", [ParentPid, ChildPid]),
timer:sleep(5000), % Wait for child to crash
io:format("Parent (~p) still alive (this won't print if it crashed).~n", [ParentPid]).
child_process(ParentPid) ->
io:format("Child (~p) started, linked to Parent (~p).~n", [self(), ParentPid]),
timer:sleep(1000), % Simulate some work
io:format("Child (~p) crashing now!~n", [self()]),
exit(i_crashed). % Child exits with an errorTrapping Exits: Handling Failures
While crash propagation is useful for simple 'all or nothing' scenarios, often you want a process to *handle* a linked process's crash, not just die with it. This is where trapping exits comes in.
By setting process_flag(trap_exit, true), a process will convert incoming exit signals from linked processes into {'EXIT', Pid, Reason} messages, which it can then receive and process.
Trapping Exits in Code
Here, the parent process traps exits. When the child crashes, the parent receives an 'EXIT' message instead of crashing itself. This is fundamental for building supervisors!
-module(trap_exit_example).
-export([start/0]).
start() ->
ParentPid = self(),
io:format("Parent (~p) starting and trapping exits...~n", [ParentPid]),
process_flag(trap_exit, true),
ChildPid = spawn_link(fun() -> child_process(ParentPid) end),
io:format("Parent (~p) linked to child (~p).~n", [ParentPid, ChildPid]),
receive
{'EXIT', ChildPid, Reason} ->
io:format("Parent (~p) caught exit from child (~p) with reason: ~p~n", [ParentPid, ChildPid, Reason]);
_ ->
io:format("Parent (~p) received unexpected message.~n", [ParentPid])
after 5000 ->
io:format("Parent (~p) timed out waiting for exit message.~n", [ParentPid])
end.
child_process(ParentPid) ->
io:format("Child (~p) started, linked to Parent (~p).~n", [self(), ParentPid]),
timer:sleep(1000),
io:format("Child (~p) crashing now!~n", [self()]),
exit(i_crashed_trapped).Process Monitoring Explained
A monitor is a unidirectional connection. It allows one process to observe another process for its termination without affecting its own lifecycle.
- Monitors are created using
erlang:monitor(process, Pid). - If the monitored process exits, the monitoring process receives a
{'DOWN', MonitorRef, process, Pid, Reason}message. - The monitoring process does NOT crash by default, even if it doesn't trap exits.
Monitoring in Action: No Crash Propagation
In this example, the parent monitors the child. When the child crashes, the parent receives a 'DOWN' message, but the parent itself remains active and doesn't crash.
-module(monitor_example).
-export([start/0]).
start() ->
ParentPid = self(),
io:format("Parent (~p) starting...~n", [ParentPid]),
ChildPid = spawn(fun() -> child_process() end),
MonitorRef = erlang:monitor(process, ChildPid),
io:format("Parent (~p) monitoring child (~p). Monitor ref: ~p~n", [ParentPid, ChildPid, MonitorRef]),
receive
{'DOWN', MonitorRef, process, ChildPid, Reason} ->
io:format("Parent (~p) received DOWN message for child (~p) with reason: ~p~n", [ParentPid, ChildPid, Reason]);
_ ->
io:format("Parent (~p) received unexpected message.~n", [ParentPid])
after 5000 ->
io:format("Parent (~p) timed out waiting for DOWN message.~n", [ParentPid])
end,
io:format("Parent (~p) finished, still alive!~n", [ParentPid]).
child_process() ->
io:format("Child (~p) started, will crash soon.~n", [self()]),
timer:sleep(1000),
io:format("Child (~p) crashing now!~n", [self()]),
exit(i_crashed_monitored).Links vs. Monitors: Key Differences
Choosing between links and monitors depends on your fault tolerance strategy. Here's a quick comparison:
- Links: Bidirectional, default crash propagation, used for tightly coupled processes (e.g., parent-child in a supervision tree).
- Monitors: Unidirectional, send
'DOWN'messages only, no default crash propagation, used for loosely coupled processes or temporary observation. - Links are for when you want processes to 'live or die together' (unless trapping exits). Monitors are for when you just want to 'know if it died'.
When to Use Which?
Links are the foundation of Erlang's supervision trees, where a supervisor is linked to its children and traps exits to restart them. Monitors are often used for situations like checking if a remote service is still active, or for resource cleanup after a process exits.
You can also create a link using erlang:link(Pid) and remove it with erlang:unlink(Pid). Similarly, you can remove a monitor with erlang:demonitor(MonitorRef).
Question: Link or Monitor?
Imagine you are building an Erlang application. In which of the following scenarios would using a monitor be more appropriate than a link?
Recap: Links and Monitors
In this lesson, you've learned about Erlang's core fault tolerance primitives:
- Links: Bidirectional connections that propagate exit signals, causing default crash propagation.
- Trapping Exits: A mechanism for linked processes to convert exit signals into messages, allowing them to handle failures.
- Monitors: Unidirectional connections that send
'DOWN'messages upon termination of the monitored process, without default crash propagation.
These mechanisms are fundamental for building robust, self-healing Erlang applications, forming the bedrock of OTP supervision trees.
用 AI 导师学习 Erlang — 免费
在浏览器中编写并运行真实代码，获得全天候 AI 导师的即时帮助，并在网页或应用中继续学习。
- 课程
- 12
- 课程
- 48
常见问题解答
「链接与监视器详解」课时是免费的吗？
是的 — 「链接与监视器详解」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程的其余内容，请升级到 CoddyKit PRO。 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程共包含 4 节课。
「链接与监视器详解」这节课中我会学到什么？
区分链接与监视器，并理解它们在进程监管和传播退出信号中的作用。 你通过在浏览器中直接运行的动手代码来练习 Erlang OTP: Distributed & Fault-Tolerant Systems Programming，全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 需要有经验吗？
无需任何先前经验。CoddyKit 上的 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。
「链接与监视器详解」课时需要多长时间？
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。
我能在这节 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课中编写并运行代码吗？
能。每节 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。
此课程中的所有课时
- 链接与监视器详解
- 健壮的错误处理
- 面向崩溃优先进行设计
- “任其崩溃”理念