pybind11中RAII添加回调后析构函数未调用的问题排查

核心问题拆解 #

你用pybind11封装的Stream类在带回调的Python脚本中，析构函数未执行、无输出，但以下场景可正常工作：

• 不添加回调时
• 在函数内创建Stream实例并调用函数时
• 程序退出前调用time.sleep()时

同时存在两个疑问，以及循环回调仅执行到主线程结束前内容的问题。

疑问1：Python退出时为何Stream析构函数未被调用？ #

Python退出时的GC流程并非按顺序销毁所有对象，而是有特殊的退出逻辑：

1. GIL提前释放：Python解释器退出时会先释放全局解释器锁（GIL），再启动对象销毁流程。如果你的回调在非主线程运行且持有Stream对象引用，此时GIL已释放，Python GC无法安全调用C++析构函数（析构可能涉及需要GIL的操作或线程同步问题），解释器会直接跳过这类对象的销毁，避免崩溃。
2. 循环引用与退出优先级：若回调和Stream对象间存在循环引用（比如双方互相持有引用），Python GC在退出阶段不会像正常运行时那样处理循环引用，直接放弃回收，导致析构函数不执行。
3. 非守护线程的影响：如果回调在非守护线程中执行，Python退出时不会等待非守护线程完成，直接终止这些线程。此时Stream对象可能还被线程持有引用，析构函数自然无法被调用。而time.sleep()能让主线程等待一段时间，给非守护线程完成回调的机会，同时让GC有时间处理对象销毁。

疑问2：脚本执行完最后一行后具体发生了什么？ #

Python脚本执行到最后一行后的流程是：

1. 执行剩余finally块：先处理所有未完成的try/finally结构。
2. 启动退出序列：解释器开始清理全局命名空间，按反向顺序销毁模块级对象（最后创建的对象先被销毁）。
3. 释放GIL：为让后台线程完成收尾（但Python不会等待非守护线程），解释器会先释放GIL。
4. GC尝试回收对象：此时GC会遍历剩余对象，但如果对象涉及跨线程引用、循环引用，或析构函数可能引发异常，解释器会直接跳过销毁，避免退出时崩溃。
5. 终止所有非守护线程：不管线程是否完成，直接终止后退出进程。

这就是带回调的Stream对象可能被跳过销毁的原因——线程还在运行、对象被引用，但解释器已放弃等待和回收。

循环回调仅执行到主线程结束前内容的原因 #

循环回调若运行在非守护线程中，当主线程执行完所有代码进入退出序列时，Python会直接终止非守护线程，不会等待循环完成，因此循环只能执行到主线程结束前的部分。如果把回调线程设为守护线程，主线程退出时会立刻终止它；如果是非守护线程，需在主线程中主动等待线程完成（比如调用thread.join()），但time.sleep()只是临时的妥协方案。

解决方案建议 #

1. 显式销毁对象：在脚本最后一行主动调用del stream_instance，再调用gc.collect()强制触发GC，确保对象被销毁。注意要先确保回调线程已经完成，否则仍可能失败。
2. 管理线程生命周期：在Stream类中封装线程管理，比如提供stop()方法，主动终止回调线程、释放相关引用，再销毁对象。脚本退出前显式调用stream.stop()。
3. 使用守护线程+显式等待：将回调线程设为守护线程，在脚本最后通过事件通知机制等待线程结束——在回调循环中检查停止标志，主线程设置标志后等待线程完成。
4. 避免循环引用：确保回调和Stream对象间无循环引用，比如用弱引用（weakref）持有对方引用，让GC能正常回收。

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