跨dll单例不能依赖函数内static局部变量，因其在每个模块中独立初始化，导致地址不同、析构两次、资源重复；根本原因是各dll/exe拥有隔离的数据段，必须通过导出全局变量并统一运行时实现真正唯一性。
跨 DLL 共享单例对象，**不能靠函数内 static 局部变量（即“Magic Static”）**。它在每个模块里各初始化一份，地址不同、析构两次、资源重复——不是单例，是“伪单例”。根本原因是 Windows/Linux 下 DLL/SO 拥有独立数据段，静态变量不跨模块共享。
为什么 static MySingleton& getInstance() 在 DLL 里会失效
常见错误现象：getInstance() 在 EXE 和 DLL 中返回不同地址；调试时发现构造函数执行两次、析构函数被调两次；日志打印出两套初始化行为；资源（如文件句柄、线程池）被重复创建导致崩溃。
本质原因不是线程安全问题，而是**存储期隔离**：每个加载的模块（EXE 或 DLL）都有一份自己的 .data 节，static 局部变量的内存和初始化标志都绑定在当前模块内。A.dll 调一次，B.exe 再调一次，就各自 new 出一个实例。
- 即使用了 C++11 的线程安全局部静态变量，也只保证「本模块内」首次调用线程安全，不解决跨模块唯一性
- 若单例内部持有
std::shared_ptr，控制块也会分裂——两个模块各自持有一个独立的控制块，引用计数互不影响 - 用
std::unique_ptr返回单例指针更危险：释放时可能在错误的堆上 delete（比如 DLL 用 /MD，EXE 用 /MDd）
正确做法：把单例实例声明为 DLL 导出的全局变量
核心原则：**让所有模块访问同一块内存地址**。必须把单例对象本身放在 DLL 的 .data 节中，并显式导出其符号地址。
MSVC 示例（MySingleton.h）：
#ifdef BUILDING_MYDLL
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif
class MYDLL_API MySingleton {
public:
static MySingleton& getInstance();
void doSomething();
private:
MySingleton() = default;
~MySingleton() = default;
MySingleton(const MySingleton&) = delete;
MySingleton& operator=(const MySingleton&) = delete;
};
MySingleton.cpp 中定义全局实例并实现 getInstance()：
// 定义在 DLL 内部，仅此一份
static MySingleton g_instance;
MySingleton& MySingleton::getInstance() {
return g_instance;
}
- 必须确保
g_instance是static（或inline变量，C++17+），且只在 DLL 的源文件中定义一次 -
MYDLL_API必须同时修饰类声明（用于虚表导出）和getInstance()函数（用于函数地址导出） - 不要在头文件里定义
static MySingleton instance;—— 头文件被多个模块包含，就会产生多份定义
Linux SO 下等效方案：__attribute__((visibility("default")))
Linux 不支持 __declspec，需用 GCC/Clang 的 visibility 控制。关键不是“导出函数”，而是**导出变量地址**。
示例（MySingleton.h）：
#ifdef __linux__
#define EXPORT __attribute__((visibility("default")))
#else
#define EXPORT __declspec(dllexport)
#endif
class EXPORT MySingleton {
public:
static MySingleton& getInstance();
// ...
};
// 注意：全局变量也要加 EXPORT（否则链接时找不到符号）
extern "C" EXPORT MySingleton& getMySingletonInstance();
MySingleton.cpp：
static MySingleton g_instance;
extern "C" EXPORT MySingleton& getMySingletonInstance() {
return g_instance;
}
- Linux 默认符号全可见，但若项目启用了
-fvisibility=hidden（推荐），就必须对要跨 SO 使用的变量/函数加visibility("default") - C 链接（
extern "C"）可避免名称修饰，方便 dlsym 查找，也规避 C++ ABI 差异风险 - 不要依赖
static局部变量 +extern "C"函数封装——仍会触发多实例
跨模块传递单例时最易忽略的内存一致性问题
即使单例地址唯一，若它的成员函数内部 new 对象、或返回智能指针，依然可能崩溃。因为 new/delete、malloc/free 绑定的是当前模块链接的 CRT 堆。
- 确保所有模块（EXE/DLL/SO）动态链接同一个 C/C++ 运行时（如 MSVC 的 /MD，而非 /MT）
- 避免从 DLL 返回
std::unique_ptr或std::shared_ptr管理的对象——除非明确控制块也在 DLL 内分配/销毁 - 若必须跨模块传递对象，优先用 raw pointer + 明确所有权约定（如“由创建者负责释放”），或改用纯 C 接口（
create_XXX()/destroy_XXX()） - 热插拔场景下，全局变量导出法不适用——DLL 卸载时全局对象析构，但 EXE 仍持有其地址，变成悬垂指针
真正安全的跨模块单例，不是“怎么写 getInstance”，而是“谁拥有内存、谁决定生命周期、谁负责释放”。导出全局变量只是起点，后续所有资源操作都必须锚定在同一运行时上下文中。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
