dlclose后dlopen(RTLD_NOLOAD)仍非空，共享库未卸载问题排查

让我逐个解答你的疑问，结合你给出的代码和测试结果来看：

你的测试代码 #

#include <iostream>
#include <dlfcn.h>
#include <unistd.h>
using namespace std;

bool isLibraryLoaded(const string& libPath) {
    return (nullptr != dlopen(libPath.c_str(), RTLD_NOW | RTLD_NOLOAD));
}

int main(int argc, char** argv) {
    const string libPath = "/path/to/library.so";
    cout << "loaded: " << isLibraryLoaded(libPath) << endl;
    sleep(8); // first execution of lsof

    // load lib
    void* handle = dlopen(libPath.c_str(), RTLD_NOW);
    cout << "handle: " << handle << endl;
    if (nullptr != handle) {
        cout << "loaded: " << isLibraryLoaded(libPath) << endl;
    } else {
        cout << "error: " << dlerror() << endl;
    }
    sleep(8); // second execution of lsof

    // unload lib
    if (0 == dlclose(handle)) {
        cout << "loaded: " << isLibraryLoaded(libPath) << endl;
    } else {
        cout << "error: " << dlerror() << endl;
    }
    sleep(8); // third execution of lsof

    return 0;
}

程序输出 #

loaded: 0
handle: 0x6420b0
loaded: 1
loaded: 1

三次lsof执行结果 #

第一次执行lsof：

# lsof /path/to/library.so (return -1)

第二次执行lsof：

# lsof /path/to/library.so
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
test 3240 me mem REG 8,33 333493040 5242954 /path/to/library.so

第三次执行lsof：

# lsof /path/to/library.so
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
test 3240 me mem REG 8,33 333493040 5242954 /path/to/library.so

1. 你的代码是否存在问题？ #

代码写法上没什么语法错误，isLibraryLoaded用RTLD_NOLOAD调用dlopen的方式是标准的检测库是否加载的手段——这个标志只会检查库的加载状态，不会重复加载。dlclose的调用逻辑也没问题，但核心问题是你对dlclose的预期和它实际的行为不匹配，属于对动态链接器机制的理解偏差，不是代码写错了。

2. 为什么dlclose()没有真正卸载共享库？ #

dlclose的核心作用是给共享库的引用计数减1，而不是立刻强制卸载。只有当库的引用计数降到0，同时满足其他条件时，动态链接器才会真正把库从进程地址空间中移除。

在你的测试里，虽然调用了dlclose(handle)，但库没被卸载的关键原因是：引用计数可能没降到0，或者动态链接器出于性能或依赖原因，暂时保留了库的映射。

3. 可能的原因有哪些？ #

总结下来，常见的导致dlclose后库未卸载的原因包括：

• 引用计数未归零：如果多次调用dlopen加载同一个库，每次都会增加引用计数，需要对应次数的dlclose才能把计数降到0；
• 库内全局/静态对象未清理：如果共享库中有全局对象或静态对象，它们的析构函数可能要等到进程退出才会执行，动态链接器会为了等待析构而保留库；
• 符号被其他模块引用：进程中的主程序或其他共享库如果还在引用该库的函数、变量等符号，动态链接器会保持库的加载状态；
• 动态链接器的缓存策略：为了避免重复加载的开销，动态链接器可能会缓存已加载的库，即使引用计数为0也不立刻卸载；
• 内核内存映射缓存：lsof显示的是内核层面的内存映射状态，即使动态链接器标记库为可卸载，内核可能不会立刻解除映射，直到内存压力触发回收。

4. C/C++中是否有方法检测共享库的加载/卸载状态？ #

你当前用dlopen(..., RTLD_NOLOAD)的方式是检测库是否已加载的标准方法，但要注意：

• 它只能判断库是否在进程地址空间中，无法区分引用计数是否大于0；
• 如果库确实被完全卸载，dlopen(RTLD_NOLOAD)会返回nullptr，否则会返回有效句柄。

另外，还有这些辅助检测方式：

• 查看/proc/[pid]/maps文件：这个文件会列出进程的所有内存映射，搜索库的路径就能判断它是否还被映射；
• 在共享库中添加销毁钩子：比如定义一个__attribute__((destructor))标记的函数，当库被真正卸载时，这个函数会被调用，你可以在函数里输出日志来确认卸载时机；
• 使用dlinfo函数：可以获取已加载库的路径、版本等信息，但它不能直接检测卸载状态，主要用于补充句柄的关联信息。

需要注意的是，动态链接器的卸载行为是系统控制的，没有绝对可靠的方法强制立刻卸载，只能通过遵循规则（比如确保引用计数归零、避免残留符号引用）来提高卸载的可能性。

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