DLL中声明的全局变量会怎样？
What happens to global variables declared in a DLL?

在Windows C ++ DLL中，所有全局对象（包括类的静态成员）都将在使用DLL_PROCESS_ATTACH调用DllMain之前构造，并且在使用DLL_PROCESS_DETACH调用DllMain之后立即销毁它们。

现在，您必须考虑三个问题：

0-当然，全局非常量对象是邪恶的（但是您已经知道了，所以我将避免提及多线程，锁，上帝对象等）。

1-不保证对象或不同编译单元（即CPP文件）的构造顺序，因此，如果在两个不同的CPP中实例化两个对象，您就不能希望在B之前构造对象A。 如果B依赖于A，这一点很重要。解决方案是将所有全局对象移动到同一CPP文件中，就像在同一编译单元内部一样，对象实例化的顺序将是构造顺序（以及该顺序的相反顺序）。破坏）

2-DllMain中禁止执行某些操作。 这些东西也可能在构造函数中被禁止。 因此，避免锁定某些东西。 请参阅Raymond Chen关于该主题的出色博客：

http://blogs.msdn.com/oldnewthing/archive/2004/01/27/63401.aspx

http://blogs.msdn.com/oldnewthing/archive/2004/01/28/63880.aspx

在这种情况下，惰性初始化可能会很有趣：类将保持“未初始化”状态（内部指针为NULL，布尔值为False，无论如何），直到您调用它们的方法之一为止，此时它们将自行初始化。 如果在主体（或主体的后代函数之一）中使用这些对象，您会没事的，因为在执行DllMain之后将调用它们。

3-当然，如果DLL A中的某些全局对象依赖于DLL B中的全局对象，则您应非常小心DLL的加载顺序，并因此确保依赖关系。 在这种情况下，具有直接或间接循环依赖关系的DLL将使您发疯。 最好的解决方案是打破循环依赖。

PS：请注意，在C ++中，构造函数可能会抛出，并且您不希望在DLL加载过程中发生异常，因此请确保没有非常充分的理由，您的全局对象就不会使用异常。 由于正确编写的析构函数无权抛出，因此在这种情况下DLL卸载应该可以。

Microsoft的本页详细介绍了DLL初始化和全局变量销毁的细节：
http://msdn.microsoft.com/en-us/library/988ye33t.aspx

如果要查看链接.dll时执行的实际代码，请查看%ProgramFiles%\\Visual Studio 8\\vc\\crt\\src\\dllcrt0.c 。

从检查来看，当由dll CRT维护的内部引用计数达到零时，将通过_cexit()调用析构函数。

在应用程序结束或DLL卸载时（以先到者为准）应调用它。 请注意，这在某种程度上取决于要编译的实际运行时。

另外，请注意非平凡的析构函数，因为同时存在时序和排序问题。 在析构函数所依赖的DLL 之后，您的DLL可能会被卸载，这显然会引起问题。

在Windows扩展名为* .exe的二进制图像文件中，*。dll为PE格式。此类文件具有入口点。 您可以使用dumpbin工具查看它

dumpbin / headers dllname.dll

如果使用Microsoft的C运行时，则入口点将类似于* CRTStartup或* DllMainCRTStartup

这些函数执行c和c ++运行时的初始化，并将执行分别委派给（main，WinMain）或DllMain。

如果使用Microsoft的VC编译器，则可以在VC目录中查看此函数的源代码：

• crt0.c
• dllcrt0.c

在正常情况下，DllMainCRTStartup过程处理所有事情都需要从.data节中初始化/取消初始化全局变量，当它在dll卸载期间检索通知DLL_PROCESS_DETACH时。 例如：

• 程序启动线程的main或WinMain返回控制流
• 您明确地调用FreeLibrary并且use-dll-counter为零

当调用带有fdwReason = DLL_PROCESS_DETACH参数的DllMain时，这意味着该DLL已由应用程序卸载。 这是调用全局/静态对象的析构函数之前的时间。