单例对象在程序退出时不销毁是C++常见资源泄漏源，因静态指针指向的堆内存不会被自动释放；最可靠方式是使用函数内静态变量（C++11线程安全、自动构造析构），无需手动管理。
单例对象在程序退出时不销毁，是 C++ 中最常见、最隐蔽的资源泄漏源头之一。根本原因不是“忘了写析构”，而是：堆上分配的单例指针（m_instance）本身是静态变量，但其所指向的对象不在静态存储期——系统只自动析构静态对象，不自动 delete 静态指针指向的堆内存。
为什么 static local 变量方式最可靠
使用函数内静态变量（static singleton instance）实现单例，是 C++11 起线程安全且自动管理生命周期的首选。它的销毁由编译器保证：当 main() 返回后，该变量的析构函数会被按逆序调用。
- 无需手动
delete，无悬挂指针风险 - 构造和析构都在线程安全上下文中完成（C++11 要求）
- 不依赖额外类、
atexit或智能指针，无初始化顺序问题 - 若单例持有文件句柄、数据库连接等资源，必须确保析构函数中释放
示例：
class Logger {
public:
static Logger& getInstance() {
static Logger instance; // ✅ 自动构造 + 自动析构
return instance;
}
private:
Logger() { /* 打开日志文件 */ }
~Logger() { /* 关闭日志文件 */ } // 程序退出时必然执行
};
用静态内部类做垃圾回收时，最容易漏掉这一步
当单例用 new 在堆上创建（static T* m_instance = nullptr），靠内部类（如 CGarbo）自动销毁，关键前提是：该内部类的静态实例必须在类外显式定义并初始化。
- 只在类内声明
static CGarbo garbo;不够 —— 它根本不会被构造 - 必须补上这一行：
Singleton::CGarbo Singleton::garbo;，否则析构函数永远不会触发 - 内部类的构造函数可空，但析构函数里必须判空再
delete m_instance，防止重复析构 - 如果单例被多次
getInstance()调用但从未创建（比如加了额外条件判断），m_instance仍为nullptr，不判空会崩
std::unique_ptr 管理单例时，别忽略 reset 的时机
用 std::unique_ptr 封装堆上单例看似简洁，但它的生命周期取决于指针变量本身的存储期。若把 unique_ptr 放在函数内静态变量中，它本身仍是静态的，析构时机没问题；但若放在全局或命名空间作用域，就可能遇到静态初始化顺序问题（SIOF）。
立即学习“C++免费学习笔记（深入）”；
- ✅ 推荐写法：
static std::unique_ptr<singleton>& getInstance() { static std::unique_ptr<singleton> inst = std::make_unique<singleton>(); return inst; }</singleton></singleton></singleton> - ❌ 危险写法：全局
std::unique_ptr<singleton> g_singleton;</singleton>—— 它的构造可能早于某些依赖库的初始化 -
reset()主动销毁后，再次调用getInstance()会重建实例，这在热重载或模块卸载场景有用，但也意味着你必须确保所有旧引用已失效
atexit 注册销毁函数的风险点
atexit 是 C 风格的退出钩子，在 C++ 单例中用它手动 delete 堆上实例，容易踩三个坑：
- 注册时机太晚：如果在
getInstance()第一次调用后才atexit(&cleanup)，而此时程序已注册过其他atexit函数，析构顺序不可控 - 重复注册：每次
getInstance()都调用atexit，会导致多次delete同一地址 - 异常不安全：若
atexit回调中抛异常，程序直接std::terminate
除非你明确控制整个退出流程（如嵌入式环境或游戏主循环），否则不建议用 atexit 替代语言级生命周期管理。
真正难的不是“怎么写销毁逻辑”，而是判断：这个单例是否真的需要手动干预生命周期？绝大多数情况下，用函数内静态变量就够了；只有当你必须延迟创建、或需在运行时反复重建/销毁时，才引入 unique_ptr 或内部类方案——而这时，判空、线程同步、初始化顺序，全得自己兜底。
