在DllMain的DLL_PROCESS_DETACH中释放对象是否符合规范？

问题描述 #

我正在用C编写一个DLL，其中包含C类以及用于处理客户端与类之间交互的extern "C"包装函数。我维护了一个存储所有已创建对象指针的vector列表，计划在dllmain.cpp的DLL_PROCESS_DETACH分支中调用函数BasePin::deleteAllObjects()，在DLL卸载时删除所有对象。以下是对应的dllmain代码：

// dllmain.cpp : Defines the entry point for the DLL application.
#include "pch.h"
#include "libloaderapi.h"
#include "XTalk.h"
#include <vector>

// Entry-point function for the DLL application
BOOL APIENTRY DllMain(HMODULE hModule,
    DWORD ul_reason_for_call,
    LPVOID lpReserved)
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        // Code to run when the DLL is loaded
        break;
    case DLL_THREAD_ATTACH:
        // Code to run when a new thread is created
        break;
    case DLL_THREAD_DETACH:
        // Code to run when a thread ends normally
        break;
    case DLL_PROCESS_DETACH:
        // Code to run when the DLL is unloaded

        BasePin::deleteAllObjects(); 

        // If lpReserved is NULL, it means the DLL is being unloaded by FreeLibrary
        // If lpReserved is not NULL, it means the DLL is being unloaded due to process termination
        if (lpReserved == NULL)
        {
            // Unload the DLL if it was dynamically loaded using LoadLibrary
            //FreeLibrary(hModule);
        }

        break;
    }
    return TRUE;  // Indicate that the DLL was successfully loaded/unloaded
}

目前代码运行正常，但想确认该实现方式是否符合通用开发实践，是否存在潜在问题。

分析与解答 #

整体方向符合通用实践 #

在DLL卸载时兜底清理内部创建的对象是合理的设计思路，能避免客户端未主动释放对象导致的内存泄漏，核心逻辑是成立的。

潜在问题与风险点 #

• DllMain操作限制
  Windows官方明确要求DllMain中应避免复杂操作：如果BasePin::deleteAllObjects()内部涉及调用可能触发其他DLL加载/卸载的函数、使用同步原语、或访问已销毁的全局/静态对象，都可能引发死锁、崩溃或未定义行为。尤其要注意，进程终止阶段（lpReserved != NULL）CRT状态可能已不稳定，此时执行C++标准库操作风险极高。

• 线程安全隐患
  若DLL支持多线程调用，存储对象指针的vector必须保证线程安全。如果DLL_PROCESS_DETACH执行清理时，还有其他线程在访问或修改这个vector，会直接引发数据竞争导致崩溃。

• 进程终止场景的冗余清理
  当lpReserved != NULL时，进程正在终止，操作系统会自动回收整个进程的内存空间，此时执行对象清理属于冗余操作，甚至可能因进程资源已部分释放而触发错误。

• FreeLibrary误用
  代码中注释的FreeLibrary(hModule)是错误操作，DllMain中绝不能调用FreeLibrary卸载自身，会导致递归调用和崩溃，务必保持注释状态。

优化建议 #

• 简化DllMain逻辑：将对象清理逻辑移到单独的导出函数中，要求客户端在调用FreeLibrary前主动调用该函数释放对象，DllMain中的清理仅作为兜底方案。
• 保证线程安全：对vector的所有操作（添加、删除、遍历）都用std::mutex等同步机制保护。
• 调整清理触发时机：仅在主动卸载DLL（lpReserved == NULL）时执行清理，进程终止时跳过：

  case DLL_PROCESS_DETACH:
      if (lpReserved == NULL) {
          BasePin::deleteAllObjects(); 
      }
      break;
  

• 精简清理函数：确保BasePin::deleteAllObjects()内部只做指针遍历和delete操作，避免依赖其他可能已失效的模块或资源。

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