1. 信号到底是什么为什么要用它如果你写过Linux下的服务程序或者哪怕只是用kill命令杀过几个进程那你其实已经和“信号”打过交道了。比如终端里按一下CtrlC前台进程立刻退出kill -9 pid把杀不掉的进程强制带走程序崩溃时 shell 里冒出一句Segmentation fault (core dumped)。这些场景背后全都是 Linux 进程信号在起作用。信号本质上是一种进程间异步通知机制。它不需要像管道、消息队列那样建立双向通道也不需要双方同时在线等着收发而是由一个进程或者内核直接向另一个进程发送编号化的“通知”告诉它“该停一下了”“你踩到非法内存了”“你的子进程退出了”对方收到后按约定的方式处理。这个模型很像日常生活中的来电你正在做手头的事电话响了你可以选择立刻接起来处理也可以先挂掉忙完再说对应阻塞甚至干脆拔掉电话线对应忽略。这篇文章主要讲信号的基础机制信号是什么、内核怎么管理它、标准信号和实时信号有什么差别、常见的信号怎么用、以及signal和sigaction这两套处理接口的差别。适合刚学完进程管理、想进一步理解 Linux 进程协作方式的读者也适合准备嵌入式或后端面试时想系统性梳理“进程间通信”这块知识的人。内容偏原理偏底层但我会尽量用实操验证的方式来拆让看完的你既能应付面试里“信号是什么”这类概念题也能在调程序时真正用得上。我自己刚学这块的时候最大的困惑是信号到底存在哪里、什么时候算“发出”、什么时候算“收到”这几个时间点总是理不清。后面用sleep kill ps反复做实验加上看内核的 task_struct 结构才算把这条链路彻底捋顺。下面我把这套东西一步步拆开讲。2. 信号的完整生命周期产生、未决、递送、处理2.1 什么时候算“收到”信号很多人以为kill -TERM pid敲下去那一刻进程就算“收到”信号了。严格说不对。信号的传递分三个阶段产生generation、未决pending、递送delivery。信号产生之后内核会在目标进程的进程控制块task_struct里挂一个信号记录但此时目标进程可能正在内核态做系统调用也可能正在用户态跑业务代码。真正要对信号做出响应必须等到该进程被调度、从内核态返回用户态的那个检查点。换句话说信号的“递送”发生在进程被切换回用户态之前。如果进程此刻压根没被调度比如处于睡眠状态那信号就一直在 pending 队列里躺着直到进程醒来。理解这个时序特别重要。比如你写了一个死循环程序里面没有任何系统调用那么它大部分时间都在用户态转悠信号送去之后要等内核抢占、处理完调度切换才会进入处理流程——这中间可能有几毫秒的延迟。反过来如果进程正在做文件读取这种内核操作信号反而会在系统调用返回的路上被快速检查到。2.2 内核里的三张“信号账本”Linux 内核为了管理每个进程的信号状态在 task_struct 里维护了好几个关键字段理解它们就理解了信号机制的一半signal_struct描述进程组、会话等信号相关属性的共享结构也记录了信号处理函数action表以及信号是否被屏蔽。pending当前未决信号集合记录“已经产生、但还没递送”的信号位图。每个进程有一个自己的 pending线程组还有一个共享的shared_pending。blocked信号屏蔽集合记录当前被阻塞的信号位图也就是进程暂时“不想处理”的信号集合。信号处理函数的注册表是一个数组下标就是信号编号默认情况下每个标准信号都有对应的默认行为终止、忽略、停止、继续或产生 core dump。你没写任何处理代码时内核就按默认行为帮你兜底。这三者的协作方式用一句话总结就是信号产生时在 pending 里置位递送时查 blocked 判断是否放行放行后查 action 表决定怎么处理。阻塞和忽略的区别也在这里忽略是“处理方式”设为不理会阻塞则是“根本不让你递送”一旦解除阻塞之前未决的信号会立刻递送。顺带说一句blocked和pending都是位图结构所以 Linux 里每个信号在任意时刻只有“有无”之分同样类型的信号不会排队堆积这正是标准信号最大的局限。2.3 标准信号为什么“不排队”标准信号1~31号在 pending 里只有一个 bit 位。也就是说连续发送 5 个SIGUSR1内核只记一次“有一个 SIGUSR1 未决”。等信号处理函数执行完队列清零后续那些同类型信号就丢了。实时信号34~64号不一样它们走的是排队机制不能合并每一个信号都有独立的记录。这个差异对普通程序影响不大但对“靠信号计数”的场景是致命的。我以前调一个多线程下载器的进度统计模块想用SIGUSR1通知主线程“某个分片下载完成”结果程序跑起来之后进度一会儿快一会儿慢原因就是连续到达的SIGUSR1被合并了计数丢了。后来改成用管道传消息才彻底解决。标准信号适合“通知事件发生”不适合“传递精确信息”这个边界一定要清楚。3. 信号家族谱标准信号 vs 实时信号3.1 常用标准信号速查表Linux 的标准信号编号是 1 到 31每一路信号都有固定的触发场景和默认动作。下面这是我在实际开发和面试准备中反复用到的一张速查表信号编号信号名触发场景默认动作2SIGINT终端按 CtrlC终止进程3SIGQUIT终端按 Ctrl\终止并 core dump6SIGABRTabort() 调用终止并 core dump8SIGFPE除零或浮点异常终止并 core dump9SIGKILLkill -9强制终止不可捕获不可阻塞11SIGSEGV非法内存访问终止并 core dump13SIGPIPE写管道但读端关闭终止进程14SIGALRMalarm() 定时器到期终止进程15SIGTERMkill 默认发送终止进程可捕获17SIGCHLD子进程状态改变忽略19SIGSTOPCtrlZ 或 kill -STOP暂停进程20SIGTSTP终端停止键暂停进程18SIGCONT继续被暂停的进程恢复运行这里重点说几个容易混的。SIGTERM和SIGKILL都是“终止”但前者可以捕获进程可以在退出前做资源清理、保存现场后者直接由内核强制释放进程连清理的机会都没有。所以服务治理规范里通常会先发SIGTERM做优雅停机等几秒没退再补SIGKILL。SIGSTOP和SIGTSTP也都容易看混前者是绝对的暂停信号程序无法拦截后者是终端发起的暂停可以被程序捕获用于在暂停前保存状态。SIGPIPE是我在写网络服务时踩坑最多的一路信号。默认行为是直接终止进程而且终端上经常看不到任何报错。比如你用curl测试一个 HTTP 服务服务端往已关闭的连接里写数据如果进程没处理SIGPIPE它会在某个瞬间莫名其妙地“消失”排查起来特别像内存泄漏导致的崩溃。所以长期跑的网络服务里几乎都会看到signal(SIGPIPE, SIG_IGN)这一步。3.2 实时信号带来了什么实时信号编号范围是 34 到 6432 和 33 被 NPTL 线程库保留用于内部机制最核心的改进有三个支持排队、支持携带整数或者指针数据、有优先级编号越小优先级越高。注意实时信号不使用“编号越小优先级越高”这个逻辑——恰好相反编号越大反而排在队列前面信号调度时按编号从大到小递送。这个细节我在面试中被问到过一次印象特别深。实时信号的数据载荷靠sigqueue()函数发送处理函数要从siginfo_t里取数据。比如设计一个简易的用户态任务通知机制生产者用sigqueue(pid, SIGRTMIN5, value)给消费者发消息消费者在信号处理函数里sigval字段就能拿到参数。这个用法在嵌入式场景里非常常见比如设备驱动上报事件给应用层。但说实话现代 Linux 开发里实时信号的实际应用场景在变少。原因很简单进程间要传结构化数据的话socketpair、管道、共享内存哪个都比信号方便信号处理函数里能调用的函数非常受限很多函数不是异步信号安全的一不小心就会死锁或者数据竞争。实时信号如今更多是作为一种“快速事件通知”手段在使用而不是完整的数据通道。3.3 信号编号可移植性这个坑我忍不住先提一下不要直接在代码里用数字编号。虽然上面表格里写了“信号编号”但那是 x86 上的编号ARM、MIPS 等架构不一定完全一致。比如 x86 上SIGBUS是 7有些架构上编号就不一样。写跨平台代码时请始终使用宏名SIGTERM等命令行操作时用kill -l可以查看当前系统的编号映射。每次在新的嵌入式板子上调试我都会第一时间跑一下kill -l防止把编号搞错。4. 信号的默认动作和 Core Dump4.1 为什么程序崩溃会留下 core 文件进程收到SIGSEGV、SIGABRT、SIGFPE这一类信号时系统默认动作除了终止进程还会尝试把进程当前的内存映像写进磁盘形成 core dump 文件。这个文件的名字默认是core也可能带 pid 后缀core.pid具体看系统的kernel.core_pattern配置。core dump 就是为了事后调试的。进程崩溃的现场太宝贵当时的栈回溯、寄存器值、内存数据全都凝聚在这个文件里gdb binary core.pid可以直接加载进去看崩溃线程的调用栈。很多线上偶现的段错误排查最有效的方式就是开着 core dump等下次崩了直接分析现场比加日志靠谱得多。不过这里有一个很常见的陷阱默认情况下很多系统会限制 core dump 的大小为 0也就是根本不产生 core 文件。如果发现程序崩了却没有 core 文件先执行ulimit -c unlimited再看。小内存的嵌入式板子上还要留意磁盘空间410MB 的 core 文件可能会直接把根分区塞满。4.2 信号处理函数注册的基本姿势要自定义某一路信号的处理方式最基础的方法是signal()函数原型很简单#include signal.h typedef void (*sighandler_t)(int); sighandler_t signal(int signum, sighandler_t handler);handler有三个取值SIG_IGN忽略、SIG_DFL恢复默认、或者一个自定义函数指针。比如忽略管道破裂信号signal(SIGPIPE, SIG_IGN);习惯上一定要检查返回值因为signal()失败时返回SIG_ERR如果没检查后续逻辑很可能在错误基础上跑出更隐蔽的问题。另外网上很多老代码用signal()做信号处理但它有两个广为人知的毛病一是不同 UNIX 版本的行为差异很大有的系统处理完一次后自动重置为默认动作二是处理信号期间如果又有新信号到达可能因为缺乏阻塞机制导致重复进入处理函数产生竞态。所以新代码我强烈建议直接用sigaction()它的行为在各平台下足够一致控制粒度也细得多。struct sigaction sa; sa.sa_handler handler; sigemptyset(sa.sa_mask); sa.sa_flags 0; sigaction(SIGTERM, sa, NULL);sa_mask字段的意思是在处理这个信号的期间额外阻塞哪些信号。比如处理SIGTERM时还想把SIGINT也一并挡住就把SIGINT加入sa_mask。sa_flags里我觉得最常用的标志有两个SA_RESTART让被信号打断的系统调用自动重启避免read()返回EINTRSA_SIGINFO启用带参数的信号处理函数配合siginfo_t使用。4.3 用 sigaction 验证“同一信号不排队”写一段简单的验证程序连续发送 10 个SIGUSR1给同一个进程看处理函数调用了几次#include stdio.h #include signal.h #include unistd.h #include stdlib.h static int count 0; void handler(int sig) { count; write(STDOUT_FILENO, sig\n, 4); } int main(void) { struct sigaction sa {0}; sa.sa_handler handler; sigemptyset(sa.sa_mask); sa.sa_flags 0; sigaction(SIGUSR1, sa, NULL); for (int i 0; i 10; i) { kill(getpid(), SIGUSR1); } sleep(1); printf(handler called: %d\n, count); return 0; }可能有读者看到write觉得奇怪为什么处理函数里不直接用printf原因很简单printf在信号处理上下文里不是异步信号安全的和主流程里的printf混在一起可能出问题。这里我用write做最小输出同时避免了缓冲区问题。编译运行后输出结果会落在“1 次”附近而不是 10 次。标准信号被合并这就是最直观的证明。如果把SIGUSR1换成某个实时信号比如SIGRTMIN1再跑一次计数就会接近 10。这一个实验就能把上面两节的理论全部验证一遍。5. 信号从哪来常见的产生方式和发送函数5.1 终端按键与硬件异常信号产生来源大致分为三类。第一类是用户主动从终端按键触发CtrlC产生SIGINTCtrl\产生SIGQUITCtrlZ产生SIGTSTP。这类信号发往整个前台进程组所以多条管道链上的进程都会被波及。第二类是硬件异常CPU 在执行指令时发现除零、非法内存访问、总线错误等异常由内核翻译成对应的信号发给当前进程。这类信号通常以SIGFPE、SIGSEGV、SIGBUS为代表默认行为基本都是“终止 core dump”。需要注意硬件异常信号产生于 CPU 内部不是像kill那样“外人主动发”这也是为什么它们往往来得非常突然进程完全没有准备。第三类就是显式调用函数。raise(sig)给当前进程发信号kill(pid, sig)给指定进程发abort()给自己发SIGABRT并 core dumpalarm(seconds)让内核在 seconds 秒后给你发SIGALRMsetitimer()则是更精细的定时器接口。嵌入式开发里alarm 常用于实现超时控制比如等待设备就绪时超过 3 秒还没响应就触发SIGALRM清理资源避免卡死主流程。5.2 kill 函数里 pid 参数的深刻含义kill()的第二个参数是信号编号好理解但第一个参数的坑我不止一次见人踩pid 0发送给指定 pid 的进程。pid 0发送给当前进程所在进程组的所有进程。这个在批量控制子进程时非常好用比如kill(0, SIGTERM)通知当前进程组全部退出。pid -1发送给当前进程有权限发送的所有进程除了 1 号进程init/systemd和当前进程自身。这招切莫乱用尤其不要直接搁在带 root 权限的脚本或程序里否则整个系统上能被杀到的进程都被你问候一遍。pid -1发送给进程组 id 等于-pid的所有进程用于按进程组精准管理。很多面试题会问“kill -9 -123 是什么意思”答案就是按进程组号发信号。如果只看过网上教程说“pid 填 -1 就能杀所有进程”十有八九会在这里卡壳。5.3 信号的“不可杀”特权SIGKILL 和 SIGSTOP这两路信号连 root 也只能说“我能发”但收信的进程本身无法屏蔽、无法捕获、无法忽略。发出去之后内核直接对 task_struct 执行停止或销毁的终审判决没有复议环节。为什么 Linux 要预留这么两路“上帝信号”因为系统必须有最后兜底的手段一个进程如果自己把自己所有信号都屏蔽了又没有心跳机制那就成了杀不死的僵尸级存在oss 软件出故障时kill -9是管理员手中最后一把破门锤。代价是它永远无法触发用户态逻辑所以优雅退出协议里SIGTERM是首选SIGKILL永远是底线。6. 屏蔽信号sigprocmask 与未决队列实战6.1 屏蔽不是忽略很多初学者把“屏蔽信号”理解成“让信号不起作用”其实不对。屏蔽的准确含义是“把信号挡在递送之前”信号一旦产生就留在 pending 集合里等屏蔽解除后再补送。这个机制非常有用典型场景是“临界区保护”。假设程序维护一个数据结构正在更新过程中如果此时来一个信号触发处理函数、而处理函数又访问同一份数据结构可能看到中间态而崩溃。正确做法是在更新前用sigprocmask把相关信号全部屏蔽更新完再解除屏蔽信号处理函数等更新结束后再执行避免数据竞争。6.2 一个亲手验证 pending 机制的小程序下面这段代码演示了“屏蔽 - 发信号 - 查询 pending - 解除屏蔽 - 处理函数执行”的完整链条#include stdio.h #include signal.h #include unistd.h #include stdlib.h void handler(int sig) { printf(got SIGUSR1\n); } int main(void) { struct sigaction sa {0}; sa.sa_handler handler; sigemptyset(sa.sa_mask); sa.sa_flags 0; sigaction(SIGUSR1, sa, NULL); sigset_t set, oldset, pending; sigemptyset(set); sigaddset(set, SIGUSR1); sigprocmask(SIG_BLOCK, set, oldset); kill(getpid(), SIGUSR1); sigpending(pending); if (sigismember(pending, SIGUSR1)) { printf(SIGUSR1 is pending\n); } sigprocmask(SIG_SETMASK, oldset, NULL); printf(unblocked, handler runs next\n); sleep(1); return 0; }编译跑一下预期输出顺序是先打印SIGUSR1 is pending解除屏蔽之后立刻打印got SIGUSR1。注意这里信号处理时用的printf仅仅是演示真实代码里建议使用 async-signal-safe 的write。我在写这段代码时踩过一个特别低级的坑sigprocmask第三个参数要传旧的信号集用来恢复现场。我只传了NULL导致后续想恢复时无从下手程序的行为变得不确定。所以养成习惯oldset该传就传恢复时用SIG_SETMASK精准还原。在 PThreads 环境里官方方案是每个线程用pthread_sigmask()而不是sigprocmask()多线程程序里不要混用否则信号屏蔽在线程间的传递行为会变得很诡异。6.3 pending 状态一眼看穿sigpending()只能告诉你某个信号是否 pending但如果想直观看到整个未决信号集合可以熟悉一下/proc/pid/status里的SigPnd、ShdPnd、SigBlk字段。它们是十六进制位图比如SigBlk: 0000000000000200表示屏蔽了 10 号信号0x200 512 1 9对应信号编号 10。写守护进程的调试工具时这种信息比盲目猜好使一百倍。我上个月还在一个现场问题里靠这个字段定位到“某个模块意外把 SIGTERM 屏蔽了”导致服务明明收到了停止指令却不退出。7. 进程退出瞬间的信号处理不算 bug 的竞态7.1 SIGCHLD 与子进程善后子进程退出时内核会给父进程发SIGCHLD。父进程注册处理函数后可以在里面调用waitpid()回收子进程的退出状态防止它变成僵尸。这也是实现“异步回收子进程”的经典手段。处理SIGCHLD时有三个细节要特别注意。第一信号处理函数里waitpid要用WNOHANG并以循环方式调用把能回收的子进程都回收掉只回收一个是很多人的第一版写法子进程一多就漏。第二处理函数返回后如果主流程里也在wait两边可能抢着收同一个子进程带来混乱所以要么只在一个地方回收要么用sigprocmask阶段性屏蔽。第三子进程可能因为SIGSTOP/SIGCONT暂停或恢复而触发SIGCHLD处理时要结合status判断到底是什么事件不能一律当“退出了”看待。7.2 pause 与 sleep 的信号打断问题pause()会让进程挂起直到收到信号处理函数执行完pause()返回 -1 并设置errno为EINTR。sleep()在收到信号后也会提前返回返回值为剩余秒数。这些“被打断”的行为早期被视为烦人但在设计事件循环时反而是特性你可以用信号来唤起一个空闲的 worker 去做清理、重新读取配置、或者检查外部状态。写网络服务时常见的EINTR处理套路是这样的read()返回 -1 且errno EINTR时不要当错误处理直接重试一次即可。这也是SA_RESTART标志为什么受欢迎——它帮你把很多系统调用自动重启了省去手写重试逻辑。但这并不意味着要无脑加SA_RESTART有些场景下你恰恰希望read()能被信号打断比如让阻塞读超时返回这时候就不应该设置这个标志。7.3 信号处理函数里到底能干什么这是信号编程里最“劝退”的一部分但也是面试最爱的追问点。信号处理函数运行在被打断的上下文中不是正常的函数调用流程它回去之后还要继续执行原来的代码。如果处理函数里调用了一个非异步信号安全的函数而这个函数内部又一次访问了被中断的资源死锁和缓冲区错乱是分分钟的事。官方认可的 async-signal-safe 函数在man signal-safety里有完整清单。基本原则是处理函数里优先用write()做简单输出用_exit()做立即退出用sig_atomic_t类型变量配合信号完成“值传递”比如置一个全局标志主循环里轮询这个标志位再做事。printf、malloc、lock这类函数一律不要碰。我见过有人在信号处理函数里free一个全局指针程序跑满一天在某个信号到达的瞬间直接段错误。这类问题极难复现往往线上先崩、本地怎么测都测不出来。8. 实战排查信号相关的常见问题和避坑清单8.1 程序莫名其妙退出查不到日志服务退出了但日志里没有异常信息第一反应应该看是不是被信号终止的。shell 里如果进程是被信号杀死的会提示Killed或Segmentation fault但如果用systemd托管打印结果就不那么直观。此时echo $?并不够用更好的方式是查看进程退出码的 shell 语义比如 128信号编号137 128 9表示被SIGKILL杀掉143 128 15表示被SIGTERM终止。这个规律值得记牢排查时一眼就能定位到信号类别。如果是在 Java 或 Python 服务里进程退出的同时还会打印signal相关的提示位但很多语言运行时会先把常用信号劫持走间接导致你以为“信号没生效”反而不容易定位。排查这类问题的第一步永远是确认目标进程收到的最后一个信号到底是什么。用strace -f -e tracesignal挂上去或者gdb跟一下信号处理流程比瞎猜高效得多。8.2 SIGPIPE 把网络服务干掉了这是新写网络服务最容易中的招。服务端往一个已经关闭的 socket 上写数据内核会发SIGPIPE默认动作是终止进程。日志里没有任何打印进程就“消失”了而且经常是在高并发压测时出现非常像资源耗尽的假象。标准解法就是服务启动时执行一句signal(SIGPIPE, SIG_IGN)然后自己处理和EPIPE相关的错误码。注意这里用sigaction时不要加SA_RESTART因为一次send()触发EPIPE后需要业务层感知连接已经断开并主动清理连接而不是被自动重启后继续往死链上写。我实际排过这个故障服务进程一夜之间被重启了 N 次加监控才看出是SIGPIPE干的。8.3 僵尸进程为什么阴魂不散父进程没有及时wait()子进程子进程退出后就会进入僵尸状态ps里能看到一堆defunct。常规的解法确实是注册SIGCHLD处理函数在里面用waitpid(-1, status, WNOHANG)循环回收。但有一种情况比较尴尬如果父进程自己也是个被托管的服务托管方对信号有一套自己的回收逻辑你再注册一套SIGCHLD处理两套回收逻辑会打架。这种情况下最稳妥的是在服务框架层统一处理——接收SIGCHLD后只做一次全局回收或者干脆交给托管框架内部waitpid逻辑。用 docker 跑后台任务时1 号进程如果不是专门的 init 程序也可能因为不回收孙进程而产生大量僵尸。我的经验是能用 init 系统解决的就别在业务代码里玩太多信号技巧必须自己处理时确保整个进程里只有一个人负责“收尸”。8.4 多线程程序里的信号屏蔽陷阱线程库NPTL下信号处理是“进程级注册、线程级屏蔽”。同一进程里某个线程用pthread_sigmask屏蔽了SIGUSR1另一个线程不屏蔽那么pthread_kill指定发给那个不屏蔽的线程时信号照样会被处理。但如果用kill发给进程信号的归属线程由内核挑一个未屏蔽它的线程具体谁处理不可预测。这个特性经常引出隐蔽的并发 bug。比如主线程里pthread_sigmask把SIGINT屏蔽了子线程没屏蔽用户按CtrlC时信号可能被任意一个没有屏蔽它的线程处理而不是你想的那个。所以多线程程序里处理信号的标准姿势是统一在主线程里屏蔽所有想统一处理的异步信号配合sigwait()用同步方式接收信号或者每个线程各自处理自己关注的那部分信号并严格控制发送对象。两条路都行但混着用就是给自己挖坑。9. 关于信号处理代码风格的几点个人体会这一节不算“新知识”但我特别想强调一下因为我见过太多人学会了 API 却在工程里写出一堆难维护的信号代码。首先永远不要假设信号处理函数会在哪条执行流上运行。它在哪个线程、打断了哪段代码都不受你控制。于是任何需要锁保护的全局状态在信号处理函数里碰都别碰真需要传数据用sig_atomic_t或者精心设计的无锁队列。其次把处理函数做得越小越好最理想的情况是做个标记就回来所有重活放到主循环里慢慢处理。这叫做“延迟处理”能避开九成以上的信号相关 bug。另外处理函数里要避免调用longjmp或者siglongjmp。虽然标准允许在有严格约束时使用但我实际操作中见过有人用它从信号处理函数跳出去绕过清理逻辑最后资源泄漏得莫名其妙。最后留一个小技巧调试信号问题最顺手的三件套是strace、gdb、/proc/pid/status。strace看系统调用层面信号在哪里产生、有没有EINTRgdb用handle SIGxxx print可以在信号送达进程前拦截它直接看信号参数/proc则适合短时间内快照进程的屏蔽和未决状态。这三招配起来大多数信号问题都能顺藤摸瓜找到源头。进程信号这块内容很多我这篇先把整体框架和关键机制捋清楚。信号的安全函数、竞争状态、与线程的协作、以及setjmp/longjmp这类偏底层的奇技淫巧放在下一篇继续拆。看完这篇建议你现在就打开终端用man signal、man sigaction、kill -l把环境和资料先翻一翻然后用上面几个小实验亲手验证一遍。动手跑过一轮之后信号在你心里就不再是“玄学”而是 Linux 下最直接的异步通知机制了。