动态库卸载时单例对象不会自动析构，因静态对象析构顺序由加载单元控制，dlclose常跳过析构；应改用__attribute__((constructor/destructor))配合显式指针管理生命周期。
动态库卸载时单例对象不会自动析构，这是 C++ 中真实存在的、极易被忽略的崩溃源头。 原因很简单：静态存储期对象（包括局部静态变量、全局变量）的析构顺序由加载单元（可执行文件或共享库）控制；而 dlopen/dlclose 卸载动态库时，其内部的静态对象析构函数**未必被调用**——标准不保证，glibc 实现中常跳过，尤其当对象依赖外部符号或存在跨库析构依赖时。
为什么 static 局部变量在 .so 里不安全？
很多人用 static Singleton& getInstance() { static Singleton instance; return instance; } 实现单例，这在主程序里是安全的，但在动态库中会出问题：
- 动态库被
dlclose时，instance的析构函数大概率不会执行，导致资源泄漏（如未关闭的数据库连接、未释放的内存池） - 若
Singleton析构函数中调用了其他动态库的符号（比如日志函数），而该库已先卸载，则触发SEGFAULT - 更隐蔽的是：如果该单例被主程序或其他仍在运行的库持有指针，后续访问就是悬垂指针 —— 行为未定义，调试极难复现
如何让单例响应 dlclose 并主动销毁？
核心思路：放弃“自动析构”，改用显式生命周期管理。必须把单例的创建和销毁绑定到动态库的加载/卸载钩子上：
- 在动态库中定义
__attribute__((constructor))和__attribute__((destructor))函数（GCC/Clang 支持） - 在 constructor 中调用
getInstance()强制初始化单例（确保它真正在库加载时构造） - 在 destructor 中显式调用销毁逻辑，例如：
Singleton::destroy()或直接delete静态指针实例 - 注意：
__attribute__((destructor))函数执行时，不能依赖任何其他已卸载库的符号，也不能再调用getInstance()—— 此时静态局部变量可能已失效
用 std::call_once + static 指针替代局部静态变量
局部静态变量在动态库中析构不可靠，换成显式管理的指针更可控：
- 声明为
static Singleton* instance = nullptr;，而非static Singleton instance; - 初始化用
std::call_once(flag, []{ instance = new Singleton(); });，确保线程安全且只一次 - 提供显式
static void destroy() { delete instance; instance = nullptr; }，并在__attribute__((destructor))中调用它 - 这样做的好处：析构时机完全由你控制；可加日志确认销毁发生；避免 TLS 析构顺序混乱引发的 crash
thread_local 不适合做跨库单例
有人想用 thread_local static Singleton instance; 规避析构问题 —— 这反而更危险：
-
thread_local对象在线程退出时析构，但动态库卸载时，当前线程可能还在运行，此时该 TLS 对象仍存活，无法强制清理 - 若多个线程各自持有一个 TLS 实例，就彻底破坏了“单例”语义
- 它解决的是线程隔离问题，不是模块生命周期问题；对
dlclose安全毫无帮助
真正关键的一点是：动态库中的单例从来就不是“自动管理”的对象，它必须被视为一种需要手动注册/注销的资源。哪怕用了最现代的 C++11 局部静态变量写法，在 .so 场景下也得退回到显式指针 + 构造/析构钩子的老办法——这不是倒退，而是面对 ABI 约束时的务实选择。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
