Tkinter继承tk.Tk与非继承模式多线程关窗异常差异原因

问题背景 #

使用Tkinter开发多线程应用时，会遇到经典的RuntimeError: main thread is not in main loop错误，已知Tkinter并非真正线程安全。为探究原因，编写了两种实现方案：

方法1：继承tk.Tk的App类，在独立线程运行 #

关闭窗口后触发上述RuntimeError，报错栈信息如下：

Closing root window
Exception ignored in: <function Variable.__del__ at 0x000002A7D9FCB9D0>
Traceback (most recent call last):
  File "C:\ProgramData\Miniconda3\lib\tkinter\__init__.py", line 363, in __del__
    if self._tk.getboolean(self._tk.call("info", "exists", self._name)):
RuntimeError: main thread is not in main loop
Tcl_AsyncDelete: async handler deleted by the wrong thread

方法2：不继承tk.Tk，仅在类内实例化tk.Tk，同样在独立线程运行 #

关闭窗口无报错。

核心疑问 #

为何两种模式在独立线程运行时，关闭窗口会出现是否触发该错误的差异？

原因解析 #

这两种模式的差异本质是Tkinter对象的生命周期与线程绑定关系不同：

• 方法1：继承tk.Tk的类作为线程执行体
  当继承tk.Tk的App类在独立线程中运行时，App实例本身既是Tkinter的根窗口对象，又是线程的执行载体。窗口关闭后，Tkinter的内部变量（如Variable子类对象）会在垃圾回收时触发__del__方法，而Python全局垃圾回收默认由主线程执行。这些变量绑定的Tcl解释器属于子线程创建的根窗口，主线程调用Tcl解释器方法时，子线程的事件循环已经终止，就会触发RuntimeError: main thread is not in main loop，同时还会因为Tcl异步处理器被错误线程销毁而抛出Tcl_AsyncDelete错误。

• 方法2：类内实例化tk.Tk
  这种模式下，子线程中创建的tk.Tk实例完全被限制在子线程内部。当窗口关闭、子线程结束时，Tkinter的所有相关对象（包括内部变量）的生命周期都由子线程管理，垃圾回收也在子线程内完成。此时调用Tcl解释器方法的线程就是创建它的子线程，不存在跨线程调用Tcl接口的问题，因此不会触发错误。

注意：Tkinter官方并不推荐在非主线程创建GUI对象，即使方法2看似正常，也可能存在潜在的线程安全隐患，比如某些Tcl内部状态的竞争问题。

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