跨DLL边界的shared_ptr单例缓存触发R6025错误的解决方案问询

1. 优雅解决Windows下DLL卸载时的纯虚函数调用问题 #

核心矛盾是DLL1（ISession实现所在）先于DLL2（缓存所在）卸载，导致std::shared_ptr<ISession>销毁时无法找到ISession的析构函数实现。以下是几种可行的优雅方案：

方案一：为std::shared_ptr指定自定义删除器，绑定第三方DLL的销毁接口 #

如果第三方DLL1提供了显式销毁ISession的接口（比如SessionFactory::DestroySession），直接用它替换默认析构逻辑：

// 假设DLL1补充提供销毁接口
class SessionFactory final
{
public:
    static std::shared_ptr<ISession> CreateSession(const std::string& pi_dataSourceId);
    static void DestroySession(ISession* pSession); // 新增销毁接口
};

// DLL2中修改getSession逻辑
std::shared_ptr<ISession> getSession(const std::string& pi_dataSourceId)
{
    auto im = m_sessions.find(pi_dataSourceId);
    if (im == m_sessions.end())
    {
        // 直接获取裸指针，绑定自定义删除器
        ISession* rawSession = SessionFactory::CreateSession(pi_dataSourceId).release();
        std::shared_ptr<ISession> l_session(rawSession, [](ISession* p) {
            SessionFactory::DestroySession(p);
        });
        m_sessions.emplace(pi_dataSourceId, l_session);
        return l_session;
    }
    else return im->second;
}

优点：销毁逻辑完全由DLL1控制，避免跨DLL析构的依赖问题；缺点：依赖DLL1提供销毁接口，若第三方不提供则无法使用。

方案二：主动提前清理缓存，确保清理动作在DLL1卸载前执行 #

避免在DllMain中执行清理（DllMain中调用复杂逻辑本身就存在风险），改为提供一个导出的清理函数，要求主程序在进程退出前、DLL1尚未卸载时主动调用：

// DLL2中导出清理函数
extern "C" __declspec(dllexport) void CleanSessionCache()
{
    SessionCache::Get().clean();
}

// 移除DllMain中的清理代码
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    switch(fdwReason) 
    { 
        case DLL_PROCESS_DETACH:
            // 不再在这里清理
            break;
    }
    return TRUE;
}

主程序需在退出流程中先调用CleanSessionCache()，再卸载DLL1和DLL2。
优点：完全规避DLL卸载顺序问题，符合Windows平台的最佳实践；缺点：需要主程序配合修改退出逻辑。

方案三：利用进程退出时的资源自动回收特性，放弃主动清理 #

若ISession持有的资源是进程级的（如内存、文件句柄），进程退出时系统会自动回收这些资源，此时可以改为动态分配单例且不主动清理：

// 修改SessionCache的Get方法为动态分配
static SessionCache& Get()
{
    static SessionCache* s_instance = new SessionCache();
    return *s_instance;
}

// 移除clean调用和DllMain中的清理代码

优点：实现最简单，无崩溃风险；缺点：存在名义上的资源泄漏（但进程退出后会被系统回收，实际无影响），仅适用于进程退出场景。

方案四：控制DLL加载顺序（仅适用于可控场景） #

若主程序可以控制DLL加载顺序，确保DLL2在DLL1之后加载，根据Windows DLL卸载顺序“先加载后卸载”的规则，DLL2会先于DLL1卸载，此时清理缓存时DLL1仍在内存中，析构函数可正常调用。
优点：无需修改业务代码；缺点：依赖主程序的加载逻辑，第三方DLL无法控制时不可行。

2. 类Unix系统中的类似问题与限制 #

类Unix系统（Linux、macOS）的共享对象（SO）机制与Windows DLL有差异，但同样会遇到跨共享对象的析构依赖问题，只是错误表现和细节不同：

• 错误表现：不会出现Windows的R6025纯虚函数调用错误，而是直接触发段错误（SIGSEGV），因为共享对象卸载后其代码段已被释放，调用其中的函数（包括析构）会访问非法内存。
• 场景差异：类Unix系统中，除非主动调用dlclose()卸载共享对象，否则共享对象会一直驻留内存直到进程退出；而进程退出时，内核会直接回收整个进程的内存空间，不会执行用户态的全局对象析构逻辑（若进程是正常退出，仍会执行，但此时若SO已卸载则会崩溃）。
• 解决方案类似：同样可以通过自定义删除器、提前清理、加载时指定RTLD_NODELETE标志（阻止dlclose()卸载SO）等方式规避问题。其中RTLD_NODELETE是类Unix系统特有的方案，加载SO时使用该标志，即使调用dlclose()也不会卸载SO，避免后续调用其函数时崩溃，但会占用更多内存。

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