动态库卸载时单例需安全销毁：Windows用DllMain的DLL_PROCESS_DETACH调用destroyInstance；Linux用__attribute__((destructor))；推荐显式shutdown接口或RAII封装；混合策略提供双保险。
如果您在 Windows 或 Linux 下开发动态链接库（DLL 或 SO），并使用单例模式管理核心服务，当宿主程序调用 FreeLibrary 或 dlclose 卸载模块时，单例对象若未及时销毁，极易引发资源泄漏、句柄未关闭、线程未终止，甚至访问已释放内存的崩溃——这不是边缘情况，而是跨平台高频复现问题。以下是确保单例在动态库卸载阶段安全注销的多种实战方案：
一、Windows DLL 中在 DllMain 的 DLL_PROCESS_DETACH 分支显式调用 destroyInstance
该方法直接绑定系统卸载钩子，在 FreeLibrary 触发且非进程退出场景下执行销毁逻辑，是 Windows 平台最主流、最可控的方式。关键在于判空 lpReserved 以区分卸载来源，并确保 destroyInstance 具备幂等性与线程安全性。
1、在单例类中声明静态成员函数 destroyInstance()，内部使用 std::atomic
2、在 destroyInstance() 开头检查原子变量，若为 true 则立即返回，避免重复 delete。
立即学习“C++免费学习笔记（深入）”；
3、销毁前对单例内部持有的 std::mutex、std::thread 等非平凡资源执行 stop/join/close 操作。
4、执行 delete 操作后，立即将静态指针置为 nullptr，并在 getInstance() 中加入空指针检查。
5、在 DllMain 函数中，于 case DLL_PROCESS_DETACH 分支内添加 if (lpReserved == nullptr) 判断，仅在此条件下调用 Singleton::destroyInstance()。
二、Linux SO 中使用 __attribute__((destructor)) 函数注册卸载清理
该属性使编译器在 dlclose 调用后自动执行标记函数，适用于 dlopen 加载的共享库。但需注意其执行顺序不保证，且无法感知是否由 dlclose 引发（可能被进程退出触发），因此必须配合资源状态判空与线程安全保护。
1、定义一个全局 C 风格函数，如 static void __attribute__((destructor)) so_cleanup() { }。
2、在该函数内调用 Singleton::destroyInstance()，而非直接操作静态指针或裸 new 对象。
3、确保 destroyInstance() 内部对 std::thread 对象先调用 joinable() 判断再 join，对 std::mutex 使用 try_lock 避免死锁。
4、所有文件句柄、映射内存、socket 描述符必须在 destroyInstance() 中显式 close/munmap/closesocket，不得依赖析构函数隐式释放。
5、禁止在 destructor 函数中调用任何可能抛异常的 C++ 标准库函数，否则将触发 std::terminate。
三、提供显式 shutdown 接口并由宿主程序在卸载前主动调用
该方案将生命周期控制权完全移交宿主，规避操作系统级钩子的不确定性，适用于高可靠性要求场景（如嵌入式中间件、金融交易模块）。它不依赖 DllMain 或 destructor 属性，而是通过导出 C 风格函数实现跨语言兼容。
1、在单例类中声明 public static void shutdown()，该函数内部调用 destroyInstance() 并重置所有静态状态标志。
2、在 DLL/SO 导出表中添加 extern "C" void STDCALL mylib_shutdown() { Singleton::shutdown(); }。
3、宿主程序在调用 FreeLibrary 或 dlclose 前，必须显式调用该导出函数。
4、在 shutdown() 中增加日志输出或写入临时文件标记，用于验证是否真实执行。
5、若单例持有其他模块的回调函数指针，shutdown() 必须在所有回调注销完成后执行，否则将导致卸载后回调触发野指针访问。
四、基于 RAII 封装动态库生命周期并绑定单例销毁时机
该方法将动态库句柄与单例生存期强绑定，通过 RAII 对象构造时初始化单例、析构时强制销毁，彻底规避手动调用遗漏风险。适用于 C++ 宿主且可修改加载逻辑的项目。
1、定义一个 LibraryGuard 类，构造函数接收 HMODULE 或 void* 句柄，并在内部调用 Singleton::getInstance() 触发首次初始化。
2、LibraryGuard 析构函数中调用 Singleton::destroyInstance()，并确保该析构发生在句柄释放（FreeLibrary/dlclose）之前。
3、将 LibraryGuard 对象声明为栈变量或智能指针托管对象，使其生命周期严格包裹动态库使用区间。
4、在 LibraryGuard 构造函数中设置 std::atomic_flag 表示“已绑定”，防止同一句柄被多次封装。
5、若 Singleton 构造过程中抛出异常，LibraryGuard 构造失败，此时不得执行任何销毁逻辑，避免对未构造对象调用 destroyInstance()。
五、混合策略：DllMain/Destructor + 显式 shutdown 双保险机制
该方案在关键路径上叠加两层保障：操作系统钩子作为兜底，显式 shutdown 作为主流程。即使宿主遗漏调用 shutdown，DLL_PROCESS_DETACH 或 destructor 仍可捕获并执行基本清理；而正常流程下则优先走显式路径，确保资源释放顺序可控。
1、在 destroyInstance() 中引入双重检查：先检查原子标志，再尝试加锁执行销毁，锁失败则放弃（避免卸载时竞态）。
2、显式 shutdown 函数返回布尔值表示是否成功执行销毁，宿主应校验返回值并记录错误。
3、在 DllMain 或 destructor 函数中，仅当检测到 shutdown 未被调用时才执行轻量级资源释放（如关闭日志文件、释放 mmap 内存），跳过复杂对象析构。
4、所有线程句柄、event、semaphore 等内核对象必须在双路径中均被 CloseHandle 或 sem_destroy，不可仅依赖某一条路径。
5、在单例类静态成员中维护一个 volatile bool s_shutdown_called 标志，由 shutdown() 设置为 true，供钩子函数读取判断。
