CPython atexit 模块完全解析注册/注销退出清理函数与解释器终止生命周期【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpythonatexit是 CPython 标准库中专门用于**注册与注销解释器退出清理函数**的模块凡是正常终止流程能到达的地方注册过的函数都会被自动、按后注册先执行LIFO的顺序调用从而让模块无需依赖业务代码在退出时显式调用自己即可完成状态落盘、资源释放等收尾工作。本文以本仓库CPython 3.16.0a0 主线版本见 Include/patchlevel.h的 Doc/library/atexit.rst 为骨架逐条精讲register/unregister的语义与调用约束并结合 Modules/atexitmodule.c、Python/pylifecycle.c 以及 Lib/test/_test_atexit.py 等源码与测试讲清从注册到解释器最终化时触发的完整生命周期。读完后你既能写出正确、健壮的退出清理代码也能理解为什么标准库如site模块保存 readline 历史会借助它完成收尾。一、模块定位注册与自动执行清理函数按官方文档的定义atexit模块提供注册与注销清理函数的功能被注册的函数会在**解释器正常终止normal interpreter termination**时自动执行。模块在 Modules/atexitmodule.c 中实现该 C 模块由 2007 年 Collin Winter 从纯 Python 的atexit.py移植而来对外只暴露两个公开函数register与unregister另有_clear、_run_exitfuncs、_ncallbacks三个带下划线的内部接口。执行顺序是逆序的LIFO后进先出。文档给出直观示例若依次注册A、B、C解释器终止时实际执行顺序是C、B、A。之所以设计成逆序文档说明了设计前提lower level modules will normally be imported before higher level modules and thus must be cleaned up later.即底层模块通常先于高层模块被 import因此也应更晚清理——后注册的相对高层函数先跑先注册的底层清理函数后跑形成依赖方先销毁、被依赖方后销毁的天然顺序。什么情况下不会调用这些函数文档明确列出三条不触发路径即使注册了回调也不会执行程序被 Python未捕获处理的信号杀死时如SIGKILL、未安装 handler 的SIGTERM/SIGINT检测到Python 致命内部错误fatal internal error时代码里显式调用os._exit()时——os._exit()直接终止进程而不走 Python 解释器清理流程因此atexit回调、__del__析构等都一并跳过。另外文档给出一条重要警示在某个清理函数内部再去注册或注销其他清理函数其效果是未定义的undefined。因此不要把退出阶段动态调整回调表当成受支持的特性。这一点从 Modules/atexitmodule.c 的实现也能侧面印证——调用阶段会对回调列表先做拷贝就是为了规避遍历与修改并发导致的不确定性详见下文源码视角章节。与子解释器相关的版本变化3.7文档标注了.. versionchanged:: 3.7当配合 C-API 子解释器subinterpreter使用时注册的函数只归属于注册它的那个解释器。也就是说回调表不是全局共享的而是每个解释器实例各有一份主解释器中注册的清理函数不会在某个子解释器销毁时被调用反之亦然。这条语义直接对应下文源码中的PyInterpreterState.atexit按解释器隔离设计。二、核心 API 逐条精讲2.1atexit.register(func, *args, **kwargs)注册在终止时要被执行的函数func。任何需要传给func的可选位置参数与关键字参数都必须作为register的参数一并传入import atexit def goodbye(name, adjective): print(Goodbye %s, it was %s to meet you. % (name, adjective)) atexit.register(goodbye, Donny, nice) # 或等价地使用关键字参数 atexit.register(goodbye, adjectivenice, nameDonny)需要注意的语义细节同一个函数配相同参数可以注册多次It is possible to register the same function and arguments more than once届时退出时会按逆序被调用多次。在正常程序终止时例如调用了sys.exit()或主模块执行完毕自然结束时所有已注册函数按last in, first out后进先出顺序调用。这与上文 LIFO 语义一致——对应 Modules/atexitmodule.c 中PyList_Insert(state-callbacks, 0, callback)的实现每个新回调都被插入到列表头部下标 0执行时从头到尾遍历自然形成逆序。返回值是func本身因此可以直接用作装饰器见下文示例三。异常处理语义若某个退出处理器在执行中抛出了异常默认会打印 tracebackSystemExit除外并保存该异常信息等所有退出处理器都获得运行机会之后最后一次被抛出的异常会被重新抛出。也就是说单个处理器抛异常不会中断后续处理器的执行。线程/进程警示从注册的函数里启动新线程或调用os.fork可能造成竞态——主运行时线程正在释放线程状态thread state时内部threading例程或新进程却试图使用该状态可能导致崩溃而非干净退出。文档标注了.. versionchanged:: 3.12在注册函数中尝试启动新线程或os.fork新进程现在会直接抛出RuntimeError把曾经的可能崩溃升级为显式报错便于调用方在运行时尽早发现并规避。2.2atexit.unregister(func)把func从解释器关闭时要运行的函数列表中移除若func之前并未注册过unregister静默地什么都不做silently does nothing不会抛错。若func被注册过多次该函数在atexit回调栈中的所有出现都会被逐一移除。注销时内部使用相等比较因此不需要函数引用具有相同身份identity只要判定相等即可命中。这条按相等而非按身份匹配的规则在 Modules/atexitmodule.c 的atexit_unregister_locked()中落地它从列表尾部向前扫描通过PyObject_RichCompareBool(func, to_compare, Py_EQ)逐项比对找到后以PyList_SetSlice移除该槽位。正因使用如果某函数类型自定义了奇特的__eq__比如在比较过程中再去调用unregister/_clear实现还需额外防护——这正是 Lib/test/_test_atexit.py 中test_eq_unregister_clear与test_eq_unregister两个用例专门覆盖的边界场景。2.3 内部接口_run_exitfuncs/_clear/_ncallbacks这三个函数以下划线开头属于内部接口不保证长期稳定但在源码与测试中有明确定义见 Modules/atexitmodule.c接口作用实现位置atexit._run_exitfuncs()立即运行所有已注册的退出函数等价于把退出阶段提前手动触发Modules/atexitmodule.catexit._clear()清空之前注册的全部退出函数不执行它们Modules/atexitmodule.catexit._ncallbacks()返回当前已注册的退出函数数量Modules/atexitmodule.c_run_exitfuncs在测试中广泛使用如 Lib/test/_test_atexit.py 用它反复触发回调以断言调用顺序与参数透传。从模块方法表可以看出register支持METH_VARARGS|METH_KEYWORDSunregister是METH_O单参数_run_exitfuncs/_clear为METH_NOARGS。值得留意的是该 C 模块的 slot 声明了Py_MOD_PER_INTERPRETER_GIL_SUPPORTED与Py_MOD_GIL_NOT_USEDModules/atexitmodule.c支撑了自由线程free-threaded构建下的并发安全测试见下文测试章节。三、官方实战示例与用法扩展示例一模块自持状态退出即自动落盘官方文档给出的典型场景是一个模块在 import 时从文件初始化计数器并在程序终止时无需应用显式调用就自动把最新计数值写回文件try: with open(counterfile) as infile: _count int(infile.read()) except FileNotFoundError: _count 0 def incrcounter(n): global _count _count _count n def savecounter(): with open(counterfile, w) as outfile: outfile.write(%d % _count) import atexit atexit.register(savecounter)这个模式的精髓在于注册动作发生在 import 阶段应用代码只需调用incrcounter(n)正常累加退出时的持久化由解释器终止流程代为完成。你只需要保证atexit.register(savecounter)这行在模块顶层执行过一次即可。实际项目中若希望与with语句的显式语义结合也可以把savecounter内部改成f-string/str.format写法逻辑不变。示例二向清理函数透传位置/关键字参数def goodbye(name, adjective): print(Goodbye %s, it was %s to meet you. % (name, adjective)) import atexit atexit.register(goodbye, Donny, nice) # or: atexit.register(goodbye, adjectivenice, nameDonny)参数在注册时被打包、退出时原样传入。从实现看register把回调封装成三元组(func, args, kwargs)Modules/atexitmodule.c退出执行时用PyObject_Call(func, args, kwargs)调用因此闭包、绑定方法如atexit.register(conn.close)、可调用对象等只要PyCallable_Check通过都可注册register的第一个位置参数必须是可调用对象否则抛TypeError见 Modules/atexitmodule.c。示例三作为装饰器使用import atexit atexit.register def goodbye(): print(You are now leaving the Python sector.)因为register会把func原样返回Modules/atexitmodule.c 返回Py_NewRef(func)所以可以直接atexit.register修饰无参函数。注意这种写法只适用于不需要任何参数即可调用的函数——装饰后传入的func就是被注册目标本身无法附带额外参数。四、源码视角从注册到调用的完整生命周期4.1 回调表是每个解释器一份的运行时状态atexit的回调表并没有放在模块全局变量里而是挂在解释器状态上PyInterpreterState.atexit字段类型为struct atexit_state见 Modules/atexitmodule.c 的get_atexit_state()。atexit_state中除了一张 Python list 类型的callbacks表外还维护了一条供 C-API 使用的ll_callbacks单链表。这种状态归属解释器的布局正是文档 3.7 起子解释器中注册的函数仅属于该解释器语义的直接体现。4.2 解释器启动与最终化时 atexit 如何被挂接从 Python/pylifecycle.c 可以看到解释器初始化阶段会调用_PyAtExit_Init(interp)Modules/atexitmodule.c为每个解释器创建空的回调列表。而在退出流程中关键函数是 Python/pylifecycle.c 里的make_pre_finalization_calls()它会以循环方式依次等待非守护线程收尾 → 处理 pending calls → 调用_PyAtExit_Call(tstate-interp)第 2307 行之后再清理残留的子解释器、停止世界等。注释特别强调执行退出函数时解释器必须保持仍然完整可用因为退出函数可能依赖导入机制等设施Py_IsInitialized()仍须返回真。4.3 执行阶段的线程安全与异常处理atexit_callfuncs()Modules/atexitmodule.c在执行前先对回调列表做一份切片拷贝规避并发修改风险随后逐个解包(func, args, kwargs)并调用。若某个回调执行失败实现会调用PyErr_FormatUnraisable(Exception ignored in atexit callback %R, func)把异常交给sys.unraisablehook处理——模块方法表中_run_exitfuncs的 docstring 也明确写着 If a callback raises an exception, it is logged with sys.unraisablehookModules/atexitmodule.c。相应地官方文档所描述的打印 traceback、保存最后一个异常并最终重抛属于模块公开语义层面的历史表述就当前仓库的实现与 Lib/test/_test_atexit.py 的断言cm.unraisable.err_msg Exception ignored in atexit callback ...而言实际异常以 unraisable 方式记录不会中断后续处理器的执行。这一点在使用时值得留意不要把退出清理代码的关键逻辑寄托于异常能被上层捕获回调内应自行 try/except 兜底。4.4 面向嵌入器与子解释器的 C API除 Python 层两个公开函数外CPython 还向 C 扩展提供不稳定UnstableAPIPyUnstable_AtExit(PyInterpreterState *interp, void (*func)(void *), void *data)声明见 Include/cpython/pylifecycle.hC-API 文档见 Doc/c-api/interp-lifecycle.rst相关说明也出现在 Doc/c-api/sys.rst。与 Python 层的callbacks表不同这类带void*数据的回调被挂在state-ll_callbacks链表中并在解释器销毁时的_PyAtExit_Fini()Modules/atexitmodule.c里逐个释放并回调。仓库中的典型使用者包括 Modules/_interpchannelsmodule.c 与 Modules/_interpqueuesmodule.c——它们在解释器退出时注册clear_interpreter回调用于回收与解释器关联的通道/队列资源是用 atexit 保障子解释器资源自动释放的官方范本。五、测试与真实使用案例5.1 测试如何验证 LIFO 与参数透传Lib/test/test_atexit.py 中的test_shutdown直接在一个子进程内运行下述脚本并断言输出顺序import atexit def f(msg): print(msg) atexit.register(f, one) atexit.register(f, two)由于先注册one、后注册two按 LIFO 规则子进程退出时的 stdout 应为[two, one]。这正是一条可复制到本机验证的、最简洁的行为证据。更进一步Lib/test/_test_atexit.py 的test_order同时验证了位置参数与关键字参数的打包顺序依次注册func1, 1, 2、func2、func2, 3, keyvalue后实际调用顺序与参数完全符合后进先出 参数原样透传。5.2 子解释器相关测试test_callbacks_leak/test_callbacks_leak_refcycleLib/test/test_atexit.py在子解释器中注册回调其中一种还故意制造经atexit模块的引用环验证解释器销毁后回调不会泄漏到主解释器或造成引用泄漏——支撑了回调表按解释器独立、随解释器销毁而释放的实现。test_callback_on_subinterpreter_teardownLib/test/test_atexit.py通过管道验证子解释器销毁时其注册的回调确实被执行印证文档 3.7 语义中回调在注册它的那个解释器销毁时触发。5.3 标准库中的真实范例readline 历史文件的读写官方文档的 seealso 特别推荐阅读readline模块见 Doc/library/readline.rst称其为用 atexit 读写 readline 历史文件的典型样例。真正的落地实现就在site 模块中Lib/site.py 的register_readline()会在交互式启动钩子中加载历史文件并定义内部函数write_history()内含对家目录不存在、只读文件系统等异常的分支兜底最后执行atexit.register(write_history)这样每当交互式解释器正常退出write_history就会自动把本次会话的历史写入~/.python_history或PYTHON_HISTORY指定文件——你从未显式调用过它但历史总会被保存。这既是atexit模块内自注册、退出自动收尾模式的教科书级应用也解释了为什么 readline 历史跨会话不丢失。本仓库另有多处同类用法例如 Lib/multiprocessing/util.py、Lib/concurrent/futures/thread.py 等都注册了各自的清理逻辑。六、使用要点与最佳实践小结综合文档语义与源码实现使用atexit时有以下几点值得形成习惯顺序即契约回调按 LIFO 执行因此先创建的资源后释放应通过后注册释放函数来保证例如依赖库 A 的库 B 需要先清理 B、后清理 A就应先注册 A 的清理、再注册 B 的清理。参数在注册时绑定需要传参就写atexit.register(f, arg1, keyval)无参函数才适合atexit.register装饰器写法。清理函数内部务必短小、自包含不要在回调里启动新线程或os.fork3.12 起会直接RuntimeError也不要在回调里再register/unregister语义未定义回调抛出的异常通常以 unraisable 方式记录而不会被上层捕获核心收尾逻辑应当自带异常兜底。不要与os._exit()混用凡是想让 atexit 清理生效的路径都应使用正常的sys.exit()/返回退出而不是os._exit()被未处理信号杀死或致命内部错误时回调同样不会执行因此关键的持久化不能只依赖 atexit必要时应结合显式 flush/checkpoint双保险。理解边界在 C-API 子解释器场景下回调按解释器隔离而底层调用链_PyAtExit_Init→ 最终化时的_PyAtExit_Call→ 解释器销毁的_PyAtExit_Fini保证了主解释器正常退出时所有已注册回调都有机会在解释器设施仍可用时运行完毕。掌握了注册语义、LIFO 顺序、异常边界与底层生命周期之后你就能像标准库site、multiprocessing那样把退出即自动收尾的能力干净地内聚在自己的模块里。【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpython创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CPython atexit 模块完全解析：注册/注销退出清理函数与解释器终止生命周期
CPython atexit 模块完全解析注册/注销退出清理函数与解释器终止生命周期【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpythonatexit是 CPython 标准库中专门用于**注册与注销解释器退出清理函数**的模块凡是正常终止流程能到达的地方注册过的函数都会被自动、按后注册先执行LIFO的顺序调用从而让模块无需依赖业务代码在退出时显式调用自己即可完成状态落盘、资源释放等收尾工作。本文以本仓库CPython 3.16.0a0 主线版本见 Include/patchlevel.h的 Doc/library/atexit.rst 为骨架逐条精讲register/unregister的语义与调用约束并结合 Modules/atexitmodule.c、Python/pylifecycle.c 以及 Lib/test/_test_atexit.py 等源码与测试讲清从注册到解释器最终化时触发的完整生命周期。读完后你既能写出正确、健壮的退出清理代码也能理解为什么标准库如site模块保存 readline 历史会借助它完成收尾。一、模块定位注册与自动执行清理函数按官方文档的定义atexit模块提供注册与注销清理函数的功能被注册的函数会在**解释器正常终止normal interpreter termination**时自动执行。模块在 Modules/atexitmodule.c 中实现该 C 模块由 2007 年 Collin Winter 从纯 Python 的atexit.py移植而来对外只暴露两个公开函数register与unregister另有_clear、_run_exitfuncs、_ncallbacks三个带下划线的内部接口。执行顺序是逆序的LIFO后进先出。文档给出直观示例若依次注册A、B、C解释器终止时实际执行顺序是C、B、A。之所以设计成逆序文档说明了设计前提lower level modules will normally be imported before higher level modules and thus must be cleaned up later.即底层模块通常先于高层模块被 import因此也应更晚清理——后注册的相对高层函数先跑先注册的底层清理函数后跑形成依赖方先销毁、被依赖方后销毁的天然顺序。什么情况下不会调用这些函数文档明确列出三条不触发路径即使注册了回调也不会执行程序被 Python未捕获处理的信号杀死时如SIGKILL、未安装 handler 的SIGTERM/SIGINT检测到Python 致命内部错误fatal internal error时代码里显式调用os._exit()时——os._exit()直接终止进程而不走 Python 解释器清理流程因此atexit回调、__del__析构等都一并跳过。另外文档给出一条重要警示在某个清理函数内部再去注册或注销其他清理函数其效果是未定义的undefined。因此不要把退出阶段动态调整回调表当成受支持的特性。这一点从 Modules/atexitmodule.c 的实现也能侧面印证——调用阶段会对回调列表先做拷贝就是为了规避遍历与修改并发导致的不确定性详见下文源码视角章节。与子解释器相关的版本变化3.7文档标注了.. versionchanged:: 3.7当配合 C-API 子解释器subinterpreter使用时注册的函数只归属于注册它的那个解释器。也就是说回调表不是全局共享的而是每个解释器实例各有一份主解释器中注册的清理函数不会在某个子解释器销毁时被调用反之亦然。这条语义直接对应下文源码中的PyInterpreterState.atexit按解释器隔离设计。二、核心 API 逐条精讲2.1atexit.register(func, *args, **kwargs)注册在终止时要被执行的函数func。任何需要传给func的可选位置参数与关键字参数都必须作为register的参数一并传入import atexit def goodbye(name, adjective): print(Goodbye %s, it was %s to meet you. % (name, adjective)) atexit.register(goodbye, Donny, nice) # 或等价地使用关键字参数 atexit.register(goodbye, adjectivenice, nameDonny)需要注意的语义细节同一个函数配相同参数可以注册多次It is possible to register the same function and arguments more than once届时退出时会按逆序被调用多次。在正常程序终止时例如调用了sys.exit()或主模块执行完毕自然结束时所有已注册函数按last in, first out后进先出顺序调用。这与上文 LIFO 语义一致——对应 Modules/atexitmodule.c 中PyList_Insert(state-callbacks, 0, callback)的实现每个新回调都被插入到列表头部下标 0执行时从头到尾遍历自然形成逆序。返回值是func本身因此可以直接用作装饰器见下文示例三。异常处理语义若某个退出处理器在执行中抛出了异常默认会打印 tracebackSystemExit除外并保存该异常信息等所有退出处理器都获得运行机会之后最后一次被抛出的异常会被重新抛出。也就是说单个处理器抛异常不会中断后续处理器的执行。线程/进程警示从注册的函数里启动新线程或调用os.fork可能造成竞态——主运行时线程正在释放线程状态thread state时内部threading例程或新进程却试图使用该状态可能导致崩溃而非干净退出。文档标注了.. versionchanged:: 3.12在注册函数中尝试启动新线程或os.fork新进程现在会直接抛出RuntimeError把曾经的可能崩溃升级为显式报错便于调用方在运行时尽早发现并规避。2.2atexit.unregister(func)把func从解释器关闭时要运行的函数列表中移除若func之前并未注册过unregister静默地什么都不做silently does nothing不会抛错。若func被注册过多次该函数在atexit回调栈中的所有出现都会被逐一移除。注销时内部使用相等比较因此不需要函数引用具有相同身份identity只要判定相等即可命中。这条按相等而非按身份匹配的规则在 Modules/atexitmodule.c 的atexit_unregister_locked()中落地它从列表尾部向前扫描通过PyObject_RichCompareBool(func, to_compare, Py_EQ)逐项比对找到后以PyList_SetSlice移除该槽位。正因使用如果某函数类型自定义了奇特的__eq__比如在比较过程中再去调用unregister/_clear实现还需额外防护——这正是 Lib/test/_test_atexit.py 中test_eq_unregister_clear与test_eq_unregister两个用例专门覆盖的边界场景。2.3 内部接口_run_exitfuncs/_clear/_ncallbacks这三个函数以下划线开头属于内部接口不保证长期稳定但在源码与测试中有明确定义见 Modules/atexitmodule.c接口作用实现位置atexit._run_exitfuncs()立即运行所有已注册的退出函数等价于把退出阶段提前手动触发Modules/atexitmodule.catexit._clear()清空之前注册的全部退出函数不执行它们Modules/atexitmodule.catexit._ncallbacks()返回当前已注册的退出函数数量Modules/atexitmodule.c_run_exitfuncs在测试中广泛使用如 Lib/test/_test_atexit.py 用它反复触发回调以断言调用顺序与参数透传。从模块方法表可以看出register支持METH_VARARGS|METH_KEYWORDSunregister是METH_O单参数_run_exitfuncs/_clear为METH_NOARGS。值得留意的是该 C 模块的 slot 声明了Py_MOD_PER_INTERPRETER_GIL_SUPPORTED与Py_MOD_GIL_NOT_USEDModules/atexitmodule.c支撑了自由线程free-threaded构建下的并发安全测试见下文测试章节。三、官方实战示例与用法扩展示例一模块自持状态退出即自动落盘官方文档给出的典型场景是一个模块在 import 时从文件初始化计数器并在程序终止时无需应用显式调用就自动把最新计数值写回文件try: with open(counterfile) as infile: _count int(infile.read()) except FileNotFoundError: _count 0 def incrcounter(n): global _count _count _count n def savecounter(): with open(counterfile, w) as outfile: outfile.write(%d % _count) import atexit atexit.register(savecounter)这个模式的精髓在于注册动作发生在 import 阶段应用代码只需调用incrcounter(n)正常累加退出时的持久化由解释器终止流程代为完成。你只需要保证atexit.register(savecounter)这行在模块顶层执行过一次即可。实际项目中若希望与with语句的显式语义结合也可以把savecounter内部改成f-string/str.format写法逻辑不变。示例二向清理函数透传位置/关键字参数def goodbye(name, adjective): print(Goodbye %s, it was %s to meet you. % (name, adjective)) import atexit atexit.register(goodbye, Donny, nice) # or: atexit.register(goodbye, adjectivenice, nameDonny)参数在注册时被打包、退出时原样传入。从实现看register把回调封装成三元组(func, args, kwargs)Modules/atexitmodule.c退出执行时用PyObject_Call(func, args, kwargs)调用因此闭包、绑定方法如atexit.register(conn.close)、可调用对象等只要PyCallable_Check通过都可注册register的第一个位置参数必须是可调用对象否则抛TypeError见 Modules/atexitmodule.c。示例三作为装饰器使用import atexit atexit.register def goodbye(): print(You are now leaving the Python sector.)因为register会把func原样返回Modules/atexitmodule.c 返回Py_NewRef(func)所以可以直接atexit.register修饰无参函数。注意这种写法只适用于不需要任何参数即可调用的函数——装饰后传入的func就是被注册目标本身无法附带额外参数。四、源码视角从注册到调用的完整生命周期4.1 回调表是每个解释器一份的运行时状态atexit的回调表并没有放在模块全局变量里而是挂在解释器状态上PyInterpreterState.atexit字段类型为struct atexit_state见 Modules/atexitmodule.c 的get_atexit_state()。atexit_state中除了一张 Python list 类型的callbacks表外还维护了一条供 C-API 使用的ll_callbacks单链表。这种状态归属解释器的布局正是文档 3.7 起子解释器中注册的函数仅属于该解释器语义的直接体现。4.2 解释器启动与最终化时 atexit 如何被挂接从 Python/pylifecycle.c 可以看到解释器初始化阶段会调用_PyAtExit_Init(interp)Modules/atexitmodule.c为每个解释器创建空的回调列表。而在退出流程中关键函数是 Python/pylifecycle.c 里的make_pre_finalization_calls()它会以循环方式依次等待非守护线程收尾 → 处理 pending calls → 调用_PyAtExit_Call(tstate-interp)第 2307 行之后再清理残留的子解释器、停止世界等。注释特别强调执行退出函数时解释器必须保持仍然完整可用因为退出函数可能依赖导入机制等设施Py_IsInitialized()仍须返回真。4.3 执行阶段的线程安全与异常处理atexit_callfuncs()Modules/atexitmodule.c在执行前先对回调列表做一份切片拷贝规避并发修改风险随后逐个解包(func, args, kwargs)并调用。若某个回调执行失败实现会调用PyErr_FormatUnraisable(Exception ignored in atexit callback %R, func)把异常交给sys.unraisablehook处理——模块方法表中_run_exitfuncs的 docstring 也明确写着 If a callback raises an exception, it is logged with sys.unraisablehookModules/atexitmodule.c。相应地官方文档所描述的打印 traceback、保存最后一个异常并最终重抛属于模块公开语义层面的历史表述就当前仓库的实现与 Lib/test/_test_atexit.py 的断言cm.unraisable.err_msg Exception ignored in atexit callback ...而言实际异常以 unraisable 方式记录不会中断后续处理器的执行。这一点在使用时值得留意不要把退出清理代码的关键逻辑寄托于异常能被上层捕获回调内应自行 try/except 兜底。4.4 面向嵌入器与子解释器的 C API除 Python 层两个公开函数外CPython 还向 C 扩展提供不稳定UnstableAPIPyUnstable_AtExit(PyInterpreterState *interp, void (*func)(void *), void *data)声明见 Include/cpython/pylifecycle.hC-API 文档见 Doc/c-api/interp-lifecycle.rst相关说明也出现在 Doc/c-api/sys.rst。与 Python 层的callbacks表不同这类带void*数据的回调被挂在state-ll_callbacks链表中并在解释器销毁时的_PyAtExit_Fini()Modules/atexitmodule.c里逐个释放并回调。仓库中的典型使用者包括 Modules/_interpchannelsmodule.c 与 Modules/_interpqueuesmodule.c——它们在解释器退出时注册clear_interpreter回调用于回收与解释器关联的通道/队列资源是用 atexit 保障子解释器资源自动释放的官方范本。五、测试与真实使用案例5.1 测试如何验证 LIFO 与参数透传Lib/test/test_atexit.py 中的test_shutdown直接在一个子进程内运行下述脚本并断言输出顺序import atexit def f(msg): print(msg) atexit.register(f, one) atexit.register(f, two)由于先注册one、后注册two按 LIFO 规则子进程退出时的 stdout 应为[two, one]。这正是一条可复制到本机验证的、最简洁的行为证据。更进一步Lib/test/_test_atexit.py 的test_order同时验证了位置参数与关键字参数的打包顺序依次注册func1, 1, 2、func2、func2, 3, keyvalue后实际调用顺序与参数完全符合后进先出 参数原样透传。5.2 子解释器相关测试test_callbacks_leak/test_callbacks_leak_refcycleLib/test/test_atexit.py在子解释器中注册回调其中一种还故意制造经atexit模块的引用环验证解释器销毁后回调不会泄漏到主解释器或造成引用泄漏——支撑了回调表按解释器独立、随解释器销毁而释放的实现。test_callback_on_subinterpreter_teardownLib/test/test_atexit.py通过管道验证子解释器销毁时其注册的回调确实被执行印证文档 3.7 语义中回调在注册它的那个解释器销毁时触发。5.3 标准库中的真实范例readline 历史文件的读写官方文档的 seealso 特别推荐阅读readline模块见 Doc/library/readline.rst称其为用 atexit 读写 readline 历史文件的典型样例。真正的落地实现就在site 模块中Lib/site.py 的register_readline()会在交互式启动钩子中加载历史文件并定义内部函数write_history()内含对家目录不存在、只读文件系统等异常的分支兜底最后执行atexit.register(write_history)这样每当交互式解释器正常退出write_history就会自动把本次会话的历史写入~/.python_history或PYTHON_HISTORY指定文件——你从未显式调用过它但历史总会被保存。这既是atexit模块内自注册、退出自动收尾模式的教科书级应用也解释了为什么 readline 历史跨会话不丢失。本仓库另有多处同类用法例如 Lib/multiprocessing/util.py、Lib/concurrent/futures/thread.py 等都注册了各自的清理逻辑。六、使用要点与最佳实践小结综合文档语义与源码实现使用atexit时有以下几点值得形成习惯顺序即契约回调按 LIFO 执行因此先创建的资源后释放应通过后注册释放函数来保证例如依赖库 A 的库 B 需要先清理 B、后清理 A就应先注册 A 的清理、再注册 B 的清理。参数在注册时绑定需要传参就写atexit.register(f, arg1, keyval)无参函数才适合atexit.register装饰器写法。清理函数内部务必短小、自包含不要在回调里启动新线程或os.fork3.12 起会直接RuntimeError也不要在回调里再register/unregister语义未定义回调抛出的异常通常以 unraisable 方式记录而不会被上层捕获核心收尾逻辑应当自带异常兜底。不要与os._exit()混用凡是想让 atexit 清理生效的路径都应使用正常的sys.exit()/返回退出而不是os._exit()被未处理信号杀死或致命内部错误时回调同样不会执行因此关键的持久化不能只依赖 atexit必要时应结合显式 flush/checkpoint双保险。理解边界在 C-API 子解释器场景下回调按解释器隔离而底层调用链_PyAtExit_Init→ 最终化时的_PyAtExit_Call→ 解释器销毁的_PyAtExit_Fini保证了主解释器正常退出时所有已注册回调都有机会在解释器设施仍可用时运行完毕。掌握了注册语义、LIFO 顺序、异常边界与底层生命周期之后你就能像标准库site、multiprocessing那样把退出即自动收尾的能力干净地内聚在自己的模块里。【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpython创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考