Python对象析构时机不确定，取决于引用计数归零、循环引用触发gc.collect()、全局变量生命周期、多线程竞态及解释器关闭时模块卸载等五种场景。
Python 对象的析构时机并非由程序员直接控制，而是依赖于垃圾回收机制的运行节奏与引用计数的变化。以下是理解该不确定性的关键路径：
一、引用计数归零触发即时析构
当一个对象的引用计数降至0时，CPython 会立即调用其 __del__ 方法并释放内存。该行为在大多数简单作用域中可预测，但受循环引用干扰。
1、定义两个相互持有引用的类实例。
2、手动删除所有外部引用，例如使用 del obj 语句。
立即学习“Python免费学习笔记（深入）”；
3、观察 __del__ 是否被调用：若无循环引用，则通常立即执行。
二、循环引用依赖周期性垃圾回收
当对象之间形成闭环引用且无外部引用时，引用计数无法归零，CPython 的引用计数器无法触发析构，必须等待 gc.collect() 主动扫描并清理。
1、导入 import gc 模块。
2、在疑似存在循环引用的代码段后插入 gc.collect() 调用。
3、确认 __del__ 是否在该调用后执行，而非在 del 后立即发生。
三、全局变量生命周期覆盖整个程序运行期
模块级或函数外定义的对象，其引用在解释器退出前始终存在，导致析构延迟至解释器关闭阶段，此时顺序不可控且可能被跳过。
1、在模块顶层创建一个含 __del__ 方法的类实例。
2、不通过任何局部作用域引用它，仅保留在全局命名空间。
3、程序结束前，该实例的 __del__ 可能不被执行，尤其在解释器强制终止时。
四、多线程环境下析构顺序不可预测
当对象被多个线程共享且在不同线程中被删除时，各线程的引用计数减法操作非原子，可能导致析构被延迟至某个线程完成清理之后，甚至引发竞态条件。
1、在线程 A 中创建对象并传入线程 B。
2、在线程 A 中执行 del obj，同时线程 B 仍在访问该对象。
3、线程 B 结束后，引用计数才真正归零，此时析构发生，时间点完全取决于线程调度。
五、__del__ 方法被抑制的隐式场景
CPython 在解释器关闭期间会清空模块命名空间，若 __del__ 方法所属的模块已被卸载，则该方法不会被调用，对象以未析构状态被强制释放。
1、在自定义模块中定义带 __del__ 的类，并在主脚本中实例化。
2、主脚本末尾不显式清理，直接让解释器退出。
3、此时 __del__ 所在模块的全局命名空间已失效，调用被静默忽略。
