程序退出时共享库卸载顺序是否明确定义？如何控制dlopen库卸载逻辑？

这个问题的核心在于跨库全局对象的销毁顺序不可预测，以及程序退出时操作系统自动卸载动态库的行为和你预期的RAII生命周期管理冲突了。下面给你几个可行的解决方案，按推荐优先级排序：

1. 主动触发清理，控制卸载顺序 #

最可靠的方式是在程序退出前，主动让libfooloader.so完成对libfoo.so的清理，避免依赖系统的自动卸载顺序。具体做法：

• 在libfooloader.so中导出一个显式的清理函数，比如：

  // libfooloader.so 中的代码
  #include <dlfcn.h>
  #include <memory>
  
  std::unique_ptr<void, decltype(&dlclose)> g_libfoo_handle{nullptr, dlclose};
  
  extern "C" void cleanup_libfoo() {
      g_libfoo_handle.reset(); // 主动触发dlclose，释放libfoo句柄
  }
  
  // 初始化逻辑
  void init_libfoo() {
      void* handle = dlopen("libfoo.so", RTLD_LAZY);
      if (handle) {
          g_libfoo_handle.reset(handle);
      }
  }
  

• 在主程序的main函数末尾（或者程序退出的必经路径）调用这个清理函数：

  // 主程序代码
  extern "C" void cleanup_libfoo();
  
  int main() {
      // 业务逻辑...
      cleanup_libfoo(); // 先清理libfoo的引用，再让系统卸载库
      return 0;
  }
  

如果主程序无法直接调用，也可以用atexit注册这个清理函数，但要注意atexit的回调顺序是后进先出，确保它在其他依赖libfoo的回调之前执行。

2. 使用RTLD_NODELETE标志抑制自动卸载 #

如果你的系统支持（比如Linux、BSD等），可以在dlopen时加上RTLD_NODELETE标志，这样即使调用dlclose，系统也不会卸载libfoo.so，直到程序完全退出。这样就不用担心libfoo先于libfooloader被卸载的问题：

void* handle = dlopen("libfoo.so", RTLD_LAZY | RTLD_NODELETE);

不过这个方案的缺点是libfoo.so不会被主动卸载，直到程序结束，可能会造成临时的资源泄漏，但程序退出时操作系统会回收所有资源，对大多数场景来说影响不大。

3. 重构代码，移除全局状态 #

如果上面的方案都不适用，那确实只能移除libfooloader.so中的全局智能指针，把libfoo.so的句柄管理权交给调用者（主程序）：

• 让主程序负责dlopen加载libfoo.so，并把句柄传递给libfooloader.so的接口
• libfooloader.so仅在需要时使用这个句柄，不持有全局引用
• 主程序在退出前调用dlclose关闭libfoo.so
  这种方式完全避免了跨库全局对象的生命周期问题，是最彻底的解决方案，但需要修改库的接口设计。

为什么会出现这个问题？ #

程序退出时，操作系统会自动卸载所有加载的动态库，但卸载顺序是未定义的（通常和加载顺序相反，但不保证）。而你在libfooloader.so中的全局智能指针属于库的全局对象，它的销毁时机是在libfooloader.so被卸载时。如果此时libfoo.so已经被系统自动卸载，那么智能指针的析构函数调用dlclose（或者访问libfoo中的代码）时，就会访问已经被释放的内存，导致崩溃。

另外，你提到的"未用dlclose关闭的库会自动关闭"是对的，但系统的自动关闭行为不受应用程序控制，顺序完全由操作系统决定，这就是冲突的根源。

内容的提问来源于stack exchange，提问作者Calmarius