根本问题在于未保护模块加载的临界区：两个线程并发调用dlopen可能触发C++全局构造函数的竞态执行，导致崩溃或初始化不全；必须用std::call_once等机制确保首次加载原子性，且dlsym须在其回调内完成。
为什么 dlopen 和 dlsym 在多线程中会出竞态
根本问题不在函数本身线程不安全，而在于你没控制模块加载的「临界区」。比如两个线程同时调用 dlopen("libfoo.so", RTLD_NOW)，虽然 glibc 保证多次打开同一路径返回相同句柄，但若模块含全局构造函数（C++ 静态对象初始化），这些构造函数可能被并发执行——标准未定义此行为，实际表现为崩溃、内存损坏或初始化不全。
常见错误现象包括：double free or corruption、Segmentation fault in __cxa_atexit、符号解析成功但后续调用访问非法地址。
- 必须确保同一模块路径的首次
dlopen是原子操作，后续调用可复用句柄 -
RTLD_LOCAL和RTLD_GLOBAL对符号可见性有影响，多线程下混用易导致符号解析结果不一致 - 不要在
__attribute__((constructor))函数里调用dlsym—— 此时动态链接器状态不稳定
用 std::call_once + static 懒加载封装模块句柄
比手写互斥锁更可靠：既避免重复加载，又天然防止初始化竞态。核心是把模块句柄和符号指针都绑定到一次初始化逻辑里。
class PluginLoader {
static void* s_handle;
static std::once_flag s_init_flag;
static void init_once() {
s_handle = dlopen("libmath.so", RTLD_NOW | RTLD_LOCAL);
if (!s_handle) { /* handle error */ }
}
public:
static double (*add_func)(double, double);
static void load() {
std::call_once(s_init_flag, init_once);
add_func = reinterpret_cast<double(*)(double,double)>(
dlsym(s_handle, "add"));
}
};-
std::call_once是 C++11 标准保证的线程安全初始化机制，比pthread_once更易用且无宏陷阱 - 所有符号获取（
dlsym）必须放在std::call_once回调内，不能拆到外面——否则可能拿到未初始化的s_handle - 避免在
load()外部直接访问s_handle，防止绕过初始化检查
调试时如何定位是模块加载引发的竞态
别急着加锁，先确认是不是它的问题。竞态往往藏在初始化阶段，而非运行时调用。
立即学习“C++免费学习笔记（深入）”；
- 用
LD_DEBUG=files,libs启动程序，观察是否有多条calling init: libxxx.so日志——重复出现即危险信号 - GDB 中对
__dl_open和__libc_dlopen_mode下断点，看多个线程是否同时停在此处 - 用
helgrind（Valgrind 工具）跑程序，它能报出Possible data race during read/write并指向dlopen调用点 - 临时把
dlopen改成sleep(1); dlopen(...)，如果问题消失，基本锁定是初始化竞态
模块卸载（dlclose）的线程安全陷阱
dlclose 不是 dlopen 的逆操作，它只是减少引用计数；只有计数归零才真正卸载。多线程下乱调 dlclose 极易导致已卸载模块的函数被继续调用。
- 永远不要在非主线程中调用
dlclose，除非你 100% 确保没有其他线程正在执行该模块内的任何代码 - 若必须支持热卸载，应设计引用计数+回调通知机制：每次
dlsym获取函数指针后，显式increment_ref()；调用前检查is_alive() - Linux 上可配合
memfd_create+mmap实现模块内存隔离，但代价高，仅限关键场景
最常被忽略的是：即使你只在单线程调用 dlclose，若模块中注册了 atexit 或 __cxa_atexit 回调，这些回调仍可能在其他线程中异步触发——务必检查模块是否带清理逻辑。
