动态库卸载时单例不会自动安全销毁，必须显式提供destroySingleton()函数由主程序在卸载前调用，禁止依赖静态析构顺序，且需确保所有线程已停止访问、无跨模块依赖。
动态库卸载时单例不会自动安全销毁，必须显式干预；否则极易因跨模块内存释放、静态对象析构顺序错乱或线程仍在访问而崩溃。
动态库中单例的析构时机不可靠
动态库（.so 或 .dll）卸载时，C++ 标准不保证静态/全局对象的析构顺序，尤其当单例依赖其他静态资源（如日志、配置）时，很可能出现「单例还在用某对象，该对象却已析构」。更危险的是：若单例内部持有 new 出来的资源，而析构函数在库卸载后才执行（比如被主程序的 atexit 拖延），此时堆可能已被 CRT 清理，delete 直接触发段错误。
- Windows 下 DLL 的
DLL_PROCESS_DETACH回调中调用delete仍可能失败——CRT 堆句柄可能已失效 - Linux 下
.so的__attribute__((destructor))函数执行时，不能依赖任何其他静态对象（包括 STL 容器、iostream） - 若单例被多个模块共享（如插件系统），卸载顺序不确定，A 库卸载时 B 库可能还在调用其
getInstance()
必须由动态库自己提供并控制销毁入口
不能依赖程序退出时的静态析构，而应暴露一个显式的销毁函数，由主程序在卸载前主动调用。这个函数必须满足：在所有使用者停止访问后、库卸载前执行，且内部不触发跨模块释放。
- 销毁函数签名应为
void destroySingleton()，定义在动态库内，导出符号（extern "C"推荐） - 实现中只做两件事：
delete实例指针（前提是它由本库new）、置空静态指针（如m_instance = nullptr） - 禁止在销毁函数里调用任何外部模块的 API（包括日志、网络、文件），避免间接依赖已卸载的符号
- 若单例使用了
std::shared_ptr管理，需确保其自定义删除器也定义在本库内（例如绑定[](void* p) { ::operator delete(p); }）
避免 thread_local + 单例组合引发卸载死锁
如果单例内部用了 thread_local 缓存（如每个线程持有一个连接句柄），卸载时这些 thread_local 对象的析构可能晚于单例本身，导致析构函数访问已销毁的单例成员。
立即学习“C++免费学习笔记（深入）”；
- 不要在
thread_local变量的析构函数中调用单例的任何方法（包括getInstance()） - 改用惰性初始化：把
thread_local改为函数内静态局部变量，例如static auto& per_thread = []{ return std::make_unique<conn>(); }();</conn> - 若必须关联单例状态，用原子标志位（
std::atomic<bool></bool>）在单例销毁时标记「已停用」，thread_local析构前先检查
主程序调用销毁的时机必须严格对齐
主程序不能在任意位置调用销毁函数，否则残留调用会导致空指针解引用或未定义行为。关键约束是：所有线程必须已退出对该单例的使用，且不能有异步回调正在入栈。
- 在调用
destroySingleton()前，必须join()所有已启动的工作线程（detach()是高危操作） - 若单例被用于事件循环（如 Qt 的
QObject），需确保所有信号-槽连接已断开，并清空待处理事件队列 - 推荐封装一层「可关闭」接口：单例类增加
shutdown()成员，只清理业务资源（关闭 socket、flush buffer），不释放自身内存；最后再由destroySingleton()彻底释放
真正棘手的不是怎么写销毁逻辑，而是谁来决定「现在可以销毁了」——这需要主程序和动态库之间明确的生命周期协议。一旦模块间存在隐式依赖（比如插件 A 调用插件 B 的单例），卸载顺序就不再是技术问题，而是架构问题。
