C++跨DLL内存所有权问题探幽（一）DLL提供的全局单例模式
最近在开发的时候，特别是遇到关于跨DLL申请对象、指针、内存等问题的时候遇到了这么一个问题。
问题 跨DLL能不能调用到DLL中提供的单例？
问题比较简单，就是我现在有一个进程A，有DLL B DLL C，这两个DLL都依赖DLL D的单例，这个时候如果A调用了DLLB 和 DLL C，那么B和C能否正确引用到这个指定的单例？
其实这个问题我心中想的是可以使用这个进程的，但是在实际开发中我们却有了争议，有的人认为可以，有的人认为不可以，但是我对这个内存的所有权一直不太清楚，所以这也算是给自己一个解惑，一个交代。这篇文章也是我边查资料边写的，有引用很多文章，主要是为了引出结论和一些别的问题。
聊C/C++的动态内存管理的内容之前，我们先来了解一下进程中的内存分区，如上所示。我们可以通过查看程序的完整启动过程去看这些内存分区。
内存分区
在C++中，将操作系统分配给程序的内存空间按照用途划分了代码段、数据段、栈、堆几个不同的区域，每个区域都有其独特的内存管理机制。
代码区
只存代码本身，几乎不需要考虑
代码区是用于存储程序代码的区域，代码段在程序真正执行前就被加载到内存中，在程序执行期间，代码区内存不会被修改和释放。由于代码区是只读的，所以会被多个进程共享。在多个进程同时执行同一个程序时，操作系统只需要将代码段加载到内存中一次，然后让多个进程共享这个内存区域即可。
数据段
纯粹的数据，几乎不用考虑
数据段用于存储静态全局变量、静态局部变量和静态常量等静态数据。在程序运行期间，数据段的大小固定不变，但其内容可以被修改。按照变量是否被初始化。数据段可分为已初始化数据段和未初始化数据段。
栈
存放局部变量和函数调用。局部变量访问出错和函数死循环往往会导致stacks overflow。
C++中函数调用以及函数内的局部变量的使用，都是通过栈这个内存分区实现的。栈分区由操作系统自动分配和释放，是一种"后进先出"的一种内存分区。每个栈的大小是固定的，一般只有几MB，所以如果栈变量太大，或者函数调用嵌套太深，容易发生栈溢出（stack overflow）。
堆
一般就是我们new出来的指针，是一些内存空间。当内存地址所有权不明或者内存出错就容易出现堆损坏问题。
用于存放在程序运行时被动态分配的内存段。堆的大小不固定，可以动态增加和减少。使用malloc()等函数动态分配内存到堆上，使用free()等函数释放对应的动态分配内存。堆的最大容量受限于系统中有效的虚拟内存。
栈和堆？
区别：
1、申请方式：栈的空间由操作系统自动分配和释放，堆上的空间需要程序员使用malloc\free手动分配和释放。如果不释放会造成内存泄漏。
2、申请大小限制和效率：栈的空间时有限的，在linux中，使用 ulimit -s 指令 ，可以看到看到栈的容量为8M。栈区以先进后出的方式自动分配时连续的内存单元，效率高。
堆的大小受限与系统中有效的虚拟内存大小，系统是用链表来存储空闲的内存块，是不连续的。因此，堆的空间分配比较灵活，但容易产生内存碎片，相对来讲对效率低。
对于一个程序而言，大概的模型是这样的
以启动Windows系统中的exe程序为例
当我们双击某个exe程序或者通过桌面等快捷方式去启动一个exe程序时，就进入exe程序的启动过程。
程序启动时，系统首先会将exe主程序依赖的所有的dll库文件（包括exe程序自带的dll以及exe程序依赖的系统dll）都加载到进程空间中，这些dll二进制文件中存放的是可执行的二进制机器代码（即汇编代码，机器码与汇编代码等价的，汇编代码是机器码的助记符），都加载到进程的代码段的内存区中。
待所有依赖的dll模块都加载到进程空间后，最后才会将exe主程序加载到进程空间中。然后去启动C/C++的运行时库，紧接着去给全局变量分配内存并执行全局变量的初始化操作，此处对应的就是全局内存区。然后才会进入到main函数，程序才能真正的启动并运行起来。
进入到函数中，就会从所在线程的栈内存上给函数的局部变量分配栈内存，这就是我们讲的栈内存。当执行到malloc或new等代码时，申请的内存就是堆内存。
回到问题
这个问题其实实际上还没有涉及到内存所有权问题，但是我觉得可以当作一个引子：
static变量的唯一性是动态库级别的，不同库包含同一截代码的话就会有多份static实例。出现问题的情况往往是，这截代码是实现在头文件里的，所以被不同模块引用时就生成了多份代码。解决办法就是按照一般DLL导出接口的规则，在获取static变量的地方：
1.对于实现单例的dll，使用dllexport。对于MSVC来说就是__declspec(dllexport)，对于GCC/clang就是__attribute__ ((dllexport))
2.对于引用单例的dll，使用dllimport。对于MSVC/clang来说就是__declspec(dllimport)，对于GCC/clang就是__attribute__ ((dllimport))这样就只有一份了。
所以跨DLL的单例模式是可行的，这个静态变量（单例对象）必须导出，否则这个静态对象的实现会在不同的代码头文件引用的过程中一同被申请出来。
解决方案：
1.设计代码时选好单例的内存该放在哪，然后通过导入导出一解决(MSVC上导入导出使_declspec(dllimport)和_declspec(dllexport)，类比extern变量一)。比如单例打算放在动态链接库A中，那就在生成动态库A的地方的这个static变量导出，其他动态链接库°或可执行文件使用的地方导入。
2.搞个统一的地方大家的单例共同注册到一起，用的时候拿出来。
tips:
Windows使用注意事项：
- 要求使用MD/MDd，而不是MT/MTd，反正至少保证要保证exe和所有dll使用同一间使用同一个crtheap堆，否则exe和不同dll间都有各自的crtheap堆，而new和delete需要在同一堆中配套执行。
- 慎用virtual，析构函数不能为virtual函数。因为当析构函数为virtual函数时，如果单例由dll1加载，而dll2在dll1卸载之后如果还在使用，那析构时调virtual的析构函数会去查虚函数表，而虚函数表是由dll1创建的，会引发崩溃。其他虚函数也涉及虚函数表，因此若要使用虚函数，那么除非能保证dll的卸载顺序，否则不要使用热卸载。事实上，全局单例的管理交由单例框架来实现后，析构函数是否使用virtual都不会产生泄漏，因为单例框架构造和析构时使用的都是具体的全局单例类，而不会是它们的基类。
- 单例全为懒加载，直到GetReference的时候才真正实例化单例对象，需要注意全局单例没有保证多线程间安全，因此在单例实例化/动态库首次获取单例时都是线程不安全的。若在SingletonManager.cpp的Count/Obtain/Release函数中使用std::mutex加锁能够实现单例获取的安全，但实例化过程(创建过程)仍是线程不安全的。
下一期来聊聊关于跨DLL引用DLL的时候导致的所有权问题