动态库间单例重复实例化的本质是符号隔离导致静态变量不共享——每个动态库加载时都拥有独立的Singleton::instance，根本不是同一个单例；应将单例实现在主程序或统一core库中，仅头文件声明、实现唯一编译。
动态库（.so / .dll）间单例被重复实例化，本质是**符号隔离导致静态变量不共享**——每个动态库加载时都拥有自己的一份 Singleton::instance，根本不是“同一个单例”。这不是线程安全问题，而是链接与加载机制问题。
为什么动态库里写个饿汉式单例会失效
当两个动态库 A.so 和 B.so 都定义了相同的单例类（比如都含 static Singleton instance;），且各自编译链接进主程序时：
- 每个动态库的
Singleton::instance是独立的符号，位于各自模块的数据段中 - 主程序调用 A.so 的
Singleton::getInstance()，返回的是 A.so 里的 instance - 调用 B.so 的同名函数，返回的是 B.so 里的另一份 instance
- 即使类定义完全一致，C++ 标准也不保证跨翻译单元/模块的静态变量合并
最可靠方案：把单例实现在主程序（或统一的 core 库）中
让所有动态库只依赖单例的接口声明（头文件），而**不包含其实现**。真正的实例只在主程序或一个被所有模块共同链接的静态库（如 libcore.a）中初始化。
- 头文件
Singleton.h只声明class Singleton和static Singleton& getInstance();，不定义静态成员 - 实现文件
Singleton.cpp放在主程序或 core 库中，且只编译一次 - 各动态库通过 dlsym 或直接链接该 core 库来调用
getInstance() - 若必须用动态库提供单例，可导出 C 风格函数（如
extern "C" Singleton* get_singleton();），由唯一模块实现并导出
避免用局部静态变量实现跨模块单例
像这种写法看似简洁，但在多动态库场景下依然危险：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
static Singleton& getInstance() {
static Singleton instance; // ❌ 每个 .so 各有一份
return instance;
}原因：局部静态变量的初始化是**按翻译单元（即每个 .so 的 .cpp 文件）独立进行的**，不跨模块共享。即使函数签名相同，每个动态库加载时都会触发自己的 instance 构造。
除非你明确控制整个进程只加载该单例类的一个副本（例如强制所有模块链接同一个 libsingleton.so 并确保其符号不被隐藏），否则不要依赖此方式。
检查是否真出现多实例的最快方法
在关键位置打印地址，比对是否一致：
std::cout << "A.so: " << &Singleton::getInstance() << std::endl; // 在 B.so 中同样打印 std::cout << "B.so: " << &Singleton::getInstance() << std::endl;
如果输出两个不同地址，就确认发生了跨库重复实例化。此时别修构造逻辑，先修链接结构——这是根源。
真正麻烦的不是怎么写单例，而是怎么让所有模块看到的是同一块内存里的那个 instance；一旦分散到多个动态库实现里，就不再是设计模式问题，而是构建和链接问题。
