基于Python C API重启Python解释器的问题及方案咨询

我开发了一个C++/Qt应用，在主进程内运行Python解释器会话，并基于QPlainTextEdit组件构建了Python控制台，通过Python C API处理解释器的输入输出，目的是让Python能直接访问主应用内的数据。目前一切正常，但我希望无需退出主应用就能结束当前解释器会话并重启。

我当前尝试的常规方式如下：

Py_Initialize();
// Run the main session...
Py_FinalizeEx();

// Restart the session
Py_Initialize();

查阅相关资料及Python文档后得知，解释器终止后重新加载部分模块可能存在内存泄漏问题，在我的场景中确实如此：重新导入numpy等模块会触发异常并失败，但sys等模块无此问题。

请问是否有可行的规避方案？例如，创建子解释器后终止并重启，是否会遇到同样的问题？我原本想避免的方案是让Python进程外运行，这样可通过终止并重启进程实现解释器重启，希望能得到相关策略建议。

可行解决方案 #

1. 子解释器的局限性 #

子解释器（通过Py_NewInterpreter()创建）无法彻底解决问题：

• 子解释器共享全局模块状态，numpy这类依赖C扩展的模块，其内部全局变量、内存分配不会随子解释器销毁完全清理，重启后再次导入仍可能触发异常或内存泄漏。
• 仅纯Python模块能在子解释器间实现较好隔离，C扩展模块大多不支持真正的隔离，这是Python的设计限制。

2. 进程外运行：最可靠的方案 #

这是彻底解决问题的最优选择，具体实现思路：

• 将Python解释器会话放在独立子进程中，主进程通过Qt的QProcess、共享内存或自定义socket等IPC方式与子进程交互，实现数据共享。
• 需要重启会话时，直接终止当前子进程并启动新进程，完全规避主进程内的模块残留问题。
• 主应用数据的访问可通过序列化（如JSON、msgpack）或共享内存传递，虽然比进程内调用多一层开销，但换来了彻底的隔离与稳定性。

3. 临时缓解方案：模块预加载与手动清理 #

若暂时不想采用进程外方案，可尝试以下手段缓解问题：

• 预加载C扩展模块：在首次Py_Initialize()后立即导入numpy等模块，后续重启解释器时不再重新导入，复用已加载的模块状态。但此方式无法清理会话状态，仅能避免导入异常，内存泄漏仍会存在。
• 手动清理全局状态：调用Py_FinalizeEx()前，手动删除全局变量、清空sys.modules缓存，但无法清理C扩展模块的内部状态，仅为治标之法。

4. 解释器内的进程隔离 #

在主进程的Python解释器中，使用multiprocessing.Process创建独立Python进程运行会话，每次重启销毁旧进程并创建新进程。这种方式与进程外运行逻辑类似，但Python层面交互更便捷，仍需处理C++主应用数据的跨进程传递。

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