动态库全局变量在多线程下是进程级共享而非线程隔离；thread_local仅实现线程级隔离，无法解决多次dlopen的实例级独立；需通过显式上下文对象或不同soname变体实现实例隔离。
动态库中全局变量在多线程下被多个实例共享？
不是“冲突”，而是默认行为：Linux 下 dlopen 加载的动态库（.so），其全局变量是进程级单例——无论你 dlopen 多少次，只要库路径相同、符号未加 RTLD_LOCAL 隔离，所有线程看到的都是同一份内存。Windows 的 LoadLibrary 同理，DLL 全局变量默认进程内共享。
常见误判场景：std::shared_ptr 初始化失败、std::mutex 被重复构造、静态局部变量初始化竞态（如 static T x = init();），表面像“冲突”，实则是未考虑多线程安全初始化或误用单例模式。
- 确认是否真有多次
dlopen：检查返回句柄是否重复，用dladdr验证地址是否一致 - 避免在全局/静态变量中直接使用非 POD 类型（如
std::string,std::vector）：C++11 起静态初始化是线程安全的，但销毁顺序不可控，且跨 DSO 边界易出问题 - 若需每个加载实例独立状态，改用函数局部
thread_local或显式传入上下文对象，而非依赖全局变量
thread_local 能解决动态库全局变量的线程隔离吗？
能，但仅限于“每个线程一份”，不解决“每个 dlopen 实例一份”。thread_local 变量在动态库中有效，且各线程各自拥有独立副本——前提是变量定义在 .so 内部，且链接时不被优化掉（确保 -fPIC 编译、无 visibility=hidden 隐藏）。
注意：GCC/Clang 对 thread_local 在 dlopen 库中的支持要求运行时 TLS 支持（glibc ≥ 2.12），且不能用于模板静态数据成员（除非显式实例化）。
立即学习“C++免费学习笔记（深入）”；
- 声明必须带
thread_local存储说明符，static thread_local和extern thread_local均可，但定义只能有一处 - 避免在
thread_local变量的构造函数里调用dlsym或其他可能触发重入的 API - 不要对
thread_local指针做跨线程传递并解引用：生命周期绑定创建线程，其他线程访问会 UB
如何让每次 dlopen 加载获得独立的全局变量副本？
标准 POSIX 不支持。Linux dlopen 默认按库路径去重，相同路径只映射一次；即使强制用 RTLD_NOW | RTLD_DEEPBIND，也无法复制数据段。真正可行的方案只有两个：
- 把状态封装进类实例，由调用方显式创建/传入（例如暴露
MyLibContext* create_context()接口），全局变量仅作配置缓存或日志开关等无状态用途 - 编译多个不同 soname 的变体（如
libfoo_v1.so,libfoo_v2.so），通过路径区分加载——本质是绕过符号合并，代价是代码冗余和维护成本上升
试图用 RTLD_LOCAL + 符号隐藏（__attribute__((visibility("hidden")))）来“隔离”变量，只会导致符号不可见，无法解决数据段共享问题。
调试时发现 std::mutex 报 Resource deadlock avoided
这是典型重复初始化：全局 std::mutex m; 在动态库中，若该库被多次 dlopen（且未设 RTLD_NOLOAD），而 mutex 构造函数非幂等（C++ 标准未要求多次构造安全），就可能损坏内部状态。更危险的是静态局部 mutex（static std::mutex& get_mutex() { static std::mutex m; return m; }），其初始化在首次调用时发生，多线程并发进入会导致未定义行为。
- 永远不要在动态库全局作用域或静态局部作用域中定义可变状态对象（
std::mutex,std::shared_ptr,std::ofstream等） - 改用
pthread_mutex_t手动管理，配合PTHREAD_MUTEX_INITIALIZER宏（POD，可安全多次赋值）或运行时pthread_mutex_init+ 显式生命周期控制 - 用
std::call_once+std::once_flag保护初始化逻辑，但仅适用于“一次初始化、长期使用”的场景，不适用于需多次加载/卸载的库
最稳妥的做法，是把所有可变状态推给用户管理，动态库只提供纯函数接口和明确的初始化/清理函数。
