单例对象退出时不销毁的根本原因是堆分配对象无自动析构保障；Meyers单例（局部静态变量）最安全，GC守门人模式适用于需多态的堆分配场景。
单例对象在程序退出时没被销毁，是 C++ 单例模式里最隐蔽也最危险的问题之一——不是“会不会销毁”，而是“能不能按预期顺序销毁”。关键判断只有一条：m_Instance 是堆上 new 出来的指针，它本身不参与静态析构；只有静态存储期的对象（如局部静态变量、静态成员变量）才保证在 main 返回后按逆序析构。
为什么 static Singleton* m_Instance 不会自动析构
因为 m_Instance 是一个指针变量，它的存储期是静态的，但指针所指向的 Singleton 对象在堆上，生命周期完全由程序员控制。C++ 标准（[basic.start.term]）只保证静态对象的析构函数被调用，不负责堆内存的释放。常见错误现象包括：
- 程序退出时
~Singleton()完全没被调用，资源（文件句柄、socket、数据库连接）泄漏 - 析构函数里访问了已被先析构的其他静态对象（比如日志模块），触发未定义行为
- 多线程环境下，析构时机与主线程退出不同步，
delete m_Instance被多个线程争抢
根本原因：静态变量的析构顺序是“声明逆序”，但堆对象无此保障；且 m_Instance 的析构函数不等于它指向对象的析构函数。
用 Meyers 单例（局部静态变量）绕过销毁问题
这是目前最简洁、最安全的解法——把单例对象本身放在静态存储期，而非仅放一个指针。C++11 保证局部静态变量的初始化和析构都是线程安全且确定的。
立即学习“C++免费学习笔记（深入）”；
示例写法：
class Singleton {
public:
static Singleton& getInstance() {
static Singleton instance; // ✅ 对象在静态区，main 退出后自动调用 ~Singleton()
return instance;
}
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
<p>private:
Singleton() { std::cout << "constructed\n"; }
~Singleton() { std::cout << "destructed\n"; } // 确保这里能执行
};
注意点：
- 必须返回引用（
Singleton&），不能返回指针；否则又退化为堆分配 - 不要在
getInstance()里加锁或new，否则失去局部静态变量的语义优势 - 析构顺序依赖于该函数首次调用时机——若某静态对象的构造函数里调用了
getInstance()，则instance的析构会在该静态对象之后
如果必须用堆分配（比如需要虚析构或动态类型），就靠内部 GC 类兜底
当单例需继承、或需多态销毁（如 Base* 指向派生类对象）时，局部静态变量不可行，只能回到堆分配 + 手动/自动回收。此时唯一可靠方式是引入一个静态生存期的“守门人”类，在其析构函数中 delete 堆对象。
核心结构：
- 定义嵌套类
GC，含~GC()，里面做delete m_Instance - 在外部类中声明静态成员
static GC gc;（注意：必须在类外定义，否则链接时报错） -
GC析构时机由 C++ 静态析构规则保障，且它一定在m_Instance所指对象的析构之前完成
关键代码片段：
class Singleton {
public:
static Singleton* getInstance() {
if (m_Instance == nullptr) {
m_Instance = new Singleton();
}
return m_Instance;
}
<p>private:
Singleton() = default;
~Singleton() = default;</p><pre class="brush:php;toolbar:false;">static Singleton* m_Instance;
class GC {
public:
~GC() {
delete m_Instance; // ✅ 这里是唯一安全的 delete 位置
m_Instance = nullptr;
}
};
static GC gc; // 必须在类外定义：Singleton::GC Singleton::gc;};
Singleton* Singleton::m_Instance = nullptr; Singleton::GC Singleton::gc; // ⚠️ 这一行漏掉，gc 构造函数都不会执行
atexit() 不是好选择，尤其在多线程或跨 DLL 场景下
atexit() 看似简单，但实际踩坑极多：
- 注册的函数在所有静态对象析构前执行，容易访问到已析构的全局资源（比如
std::cout可能已失效） - 无法控制执行顺序，多个
atexit回调之间无依赖关系 - Windows 下 DLL 中注册的
atexit回调，在 DLL 卸载后可能仍被调用，导致崩溃 - C++11 后标准不鼓励用它管理 C++ 对象生命周期，因缺乏类型安全和异常安全保证
除非你明确知道自己在做什么，且项目完全不涉及 DLL、不使用 STL 流、不抛异常，否则跳过它。
真正容易被忽略的是析构顺序的隐式依赖：哪怕你用了 GC 类或 Meyers 方案，只要 Singleton 的析构函数里调用了另一个单例（比如日志器），就必须确保那个单例的静态对象声明顺序在它之后——否则就是“析构时访问已销毁对象”，而这类 bug 往往只在 Release 模式下稳定复现。
