C++如何确保单例模式在模块卸载时销毁 _ 静态注销逻辑【详解】-C++-PHP中文网

单例对象在DLL卸载时必须显式销毁，否则会因析构顺序失控导致资源泄漏或崩溃；需在DllMain的DLL_PROCESS_DETACH中调用幂等、线程安全的destroyInstance()，并避免析构依赖。

c++如何确保单例模式在模块卸载时销毁 _ 静态注销逻辑【详解】

单例对象在 DLL 或共享库卸载时若未显式销毁，极大概率触发析构函数未调用、资源泄漏、甚至访问已释放内存的崩溃——这不是“可能”，而是 Windows 和 Linux 下都高频复现的问题。

为什么 DLL 卸载时单例不自动销毁

静态变量（包括 static Singleton* instance）的析构顺序由链接器和运行时决定，不受你控制。当 DLL 被 FreeLibrary（Windows）或 dlclose（Linux）卸载时：

全局静态对象的析构函数可能已被跳过（尤其跨模块依赖时）
若单例内部持有线程、句柄、std::thread、std::mutex 等非 trivial 资源，其析构函数根本不会执行
更危险的是：若其他模块的静态析构函数试图访问该单例（比如日志模块先析构，而单例还存着一个 logger 指针），就会读野指针

必须手动注册 DLL 卸载钩子

不能依赖静态对象生命周期，得在 DLL 入口点（DllMain）或初始化函数中主动注册清理逻辑：

Windows 下，在 DllMain 的 DLL_PROCESS_DETACH 分支中调用 Singleton::destroyInstance()
Linux 下，用 __attribute__((destructor)) 函数（注意：它只对主程序或 dlopen 加载的 SO 有效，且不保证执行顺序）
更可靠的做法是：提供显式的 shutdown() 接口，要求宿主程序在卸载前明确调用

示例（Windows DLL）：

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
    switch (ul_reason_for_call) {
        case DLL_PROCESS_ATTACH:
            // 可选：提前初始化单例
            Singleton::getInstance();
            break;
        case DLL_PROCESS_DETACH:
            // 必须加判空，因为 DLL_PROCESS_DETACH 可能被多次触发
            if (lpReserved == nullptr) { // 表示是 FreeLibrary 触发，而非进程退出
                Singleton::destroyInstance();
            }
            break;
    }
    return TRUE;
}

destroyInstance() 必须是幂等且线程安全的

你写的销毁函数不是“删一次就完事”，它得扛住并发调用、重复调用、以及销毁后被误访问：

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

用 std::atomic 标记是否已销毁，避免二次 delete
销毁前加锁（如果单例本身支持多线程访问），否则 delete 和后续 getInstance() 可能竞态
销毁后把指针置为 nullptr，并在 getInstance() 中检查返回值（或抛异常）
不要在 destroyInstance() 里调用任何可能再次触发单例访问的代码（比如日志、配置读取）

关键片段：

class Singleton {
public:
    static void destroyInstance() {
        if (destroyed.exchange(true)) return; // 幂等
        std::lock_guard<:mutex> lock(mtx);
        delete instance;
        instance = nullptr;
    }
<p>private:
static Singleton* instance;
static std::mutex mtx;
static std::atomic<bool> destroyed;
};</bool></p></:mutex>