Python3.12+CherryPy进程通信时线程创建异常的排查求助
问题背景
基于CherryPy开发的Web应用，通过独立进程运行matplotlib交互式绘图，用multiprocessing.Queue传递绘图对象。这套逻辑在Linux+Python3.7.1下正常，但在Windows11+Python3.12.1中，点击页面"Interactive"按钮触发Queue.put()时抛出：
RuntimeError: can't create new thread at interpreter shutdown
添加plots_process.join()后异常消失，需理清底层原因和解决方案。
异常触发底层逻辑
1. Windows与Linux的进程启动差异
Linux默认用fork创建子进程，子进程会继承父进程的内存空间和线程状态；而Windows默认用spawn方式，会启动全新的Python解释器实例，进程间通信依赖序列化/反序列化，且multiprocessing.Queue在Windows下会依赖主进程的线程来处理数据传输。
2. 主进程解释器的shutdown时机
你的main函数中，启动CherryPy引擎后没有阻塞主线程，导致main函数执行完毕，主线程直接退出。此时主进程虽然还在运行（因为CherryPy的服务线程和绘图子进程未终止），但Python解释器已经进入shutdown流程——这个阶段Python会禁止创建新线程。
而Queue.put()操作在Windows下需要启动辅助线程来完成数据的跨进程传输，当解释器已经进入shutdown状态时，创建线程的操作就会触发RuntimeError。
3. join()为何能解决问题
调用plots_process.join()会让主进程的主线程阻塞，等待绘图子进程结束，主线程不会退出，Python解释器也就不会进入shutdown流程，Queue.put()可以正常创建所需的通信线程，因此异常消失。
排查步骤
- 确认进程启动方式：执行
print(multiprocessing.get_start_method())，Windows下应为spawn，Linux下为fork。 - 追踪主线程生命周期：在
main函数末尾添加日志，观察主线程是否在CherryPy启动后直接退出。 - 验证Queue操作的线程依赖：在
Queue.put()前后打印线程数量，确认该操作会触发新线程创建。
解决方案
方案1：阻塞主线程，维持解释器正常状态
这是最稳妥的方式，让主线程一直运行，避免解释器进入shutdown。可以结合CherryPy的引擎阻塞逻辑，同时处理优雅退出：
def main(): start_plots_process() time.sleep(1) start_web_server() try: # 阻塞等待CherryPy引擎退出（比如Ctrl+C停止服务） cherrypy.engine.block() finally: # 发送退出信号给绘图进程，等待其结束 MultiProcessInfo.plots_process_queue.put("exit") MultiProcessInfo.plots_process.join()
方案2：主线程维持循环运行
如果不需要依赖CherryPy的block()，可以让主线程进入一个无限循环，保持活跃：
def main(): start_plots_process() time.sleep(1) start_web_server() try: while True: time.sleep(2) except KeyboardInterrupt: # 捕获中断信号，优雅关闭进程 MultiProcessInfo.plots_process_queue.put("exit") MultiProcessInfo.plots_process.join() cherrypy.engine.exit()
方案3：不推荐——将绘图进程设为守护进程
把绘图进程标记为守护进程（plots_process.daemon = True），这样主线程退出时会强制终止守护进程。但这种方式可能导致绘图窗口突然关闭，正在进行的绘图任务中断，仅适合对稳定性要求极低的场景。
核心总结
异常的本质是Windows下spawn方式启动的进程，其Queue通信依赖主进程线程，而主线程退出导致解释器shutdown，无法创建新线程。解决的核心就是让主进程的主线程保持运行，阻止解释器进入shutdown状态。
内容的提问来源于stack exchange，提问作者Shaggy1
