动态库卸载时Meyer单例会失效，因dlclose不保证局部静态对象析构，易致悬垂指针、段错误；应改用显式指针+constructor/destructor钩子，由主程序严格调用cleanup函数后dlclose。
动态库卸载时，单例对象不会自动析构，这是真实存在的崩溃源头，不是理论风险。直接用 static Singleton& getInstance() { static Singleton instance; } 在 .so 里，dlclose 后大概率留下悬垂指针、资源泄漏或 SEGFAULT。
为什么 Meyer 单例在动态库中会失效
局部静态变量的析构由加载单元控制，而 dlclose 不保证调用其析构函数——glibc 常跳过，尤其当对象依赖外部符号（如日志、配置）时。更危险的是：
- 析构函数若调用已卸载库的符号（比如
log("bye")），直接段错误 -
instance被其他模块持有指针，卸载后访问即未定义行为 - 多个插件共用该单例时，A 库卸载而 B 库仍在调用
getInstance()，崩溃难以复现
必须用显式指针 + constructor/destructor 钩子
放弃“自动析构”，把生命周期完全收归己手。核心是两件事：加载时强制构造、卸载时主动销毁。
- 声明为
static Singleton* instance = nullptr;，而非局部静态对象 - 用
std::call_once+std::once_flag保证线程安全初始化 - 在
__attribute__((constructor))函数中首次调用getInstance()，确保库加载即构造 - 在
__attribute__((destructor))函数中调用Singleton::destroy()，且该函数只做delete instance; instance = nullptr; -
__attribute__((destructor))里禁止调用任何外部 API（包括std::cout、日志、STL 容器）
销毁函数必须由主程序在 dlclose 前显式调用
仅靠 __attribute__((destructor)) 不够稳健——它执行时机不可控，且无法处理多线程残留访问。真正安全的做法是暴露 C 风格导出函数：
- 定义
extern "C" __attribute__((visibility("default"))) void cleanup_singleton(); - 内部只调用
Singleton::destroy()，不做任何跨模块操作 - 主程序必须严格按顺序执行：
cleanup_singleton();→dlclose(handle); - 若使用 RAII 封装（如
DllLoader），析构前需检查并调用该函数指针，不能假设它已执行
thread_local 和智能指针的陷阱要避开
这些看似“自动”的机制，在动态库场景下反而放大风险：
-
std::unique_ptr若作为静态变量，其析构仍受dlclose行为影响；若作为局部静态变量，则退化回 Meyer 模式，同样不可靠 -
thread_local Singleton*不是单例，是每线程一份实例；主线程的该指针在库卸载后可能被其他模块误读，变成悬空指针 - 单例内部若用
thread_local缓存资源（如连接句柄），其析构可能晚于单例本身，导致析构函数访问已销毁成员 - 正确做法是：用
std::atomic标记单例是否已停用，thread_local析构前先检查
真正关键的不是“怎么写析构函数”，而是“谁触发、何时触发、触发时还能依赖什么”。动态库的单例销毁，本质是模块边界问题——你无法控制其他模块的行为，只能守住自己的入口和出口。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
