Visual Studio中/MT与/MD编译选项的差异及影响解析

我在Visual Studio中使用/MT或/MD编译代码，但尚未完全理解这些选项的全部影响。我的现有理解如下：

• (A) MSDN提及的“多线程”特性与应用程序无关，应用仍可为单线程，是C运行时库（CRT）支持多线程，例如CRT会在new操作周围加同步以避免多线程指针生成的数据竞争，过去存在单线程版本；
• (B) 尽管是编译器选项，但本质更偏向链接行为，/MD为动态链接CRT，/MT为静态链接CRT；
• (C) /MD生成的可执行文件更小，但会加载ucrtbase.dll，进而加载VCRUNTIME140.dll等C运行时DLL（或其调试版本），制作安装包时需配套对应vcredist组件；
• (D) /MT生成的可执行文件更大，但直接包含CRT代码，无需加载额外DLL；
• (E) 对于大型应用（如500万行代码、100个自定义DLL），选择/MD更有利，每个DLL体积更小，且上述运行时DLL仅加载一次，因此所有DLL至少应采用/MD编译；
• (F) CRT的调试版本/MDd//MTd采用不同内存布局，例如用0xCCCCCCCC作为填充模式检测缓冲区溢出/下溢；
• (G) 编译过程中不能混合使用/MD和/MT；
• (H) /MD会定义_DLL宏，程序可通过#ifdef _DLL做特殊处理，但不建议这么做，例如errno在/MT下是extern int，在/MD下是函数调用；
• (J) 使用/MT时，每个模块拥有独立的CRT堆，内存必须在分配它的模块中释放。

请问我的上述理解是否正确？是否遗漏了重要要点？我的核心目标是理解(J)点，同时确认对该主题其他内容的理解无误。

理解验证与补充 #

一、现有理解的正确性确认

所有(A)-(J)点的理解均正确，以下是针对性的细节补充：

• (A)：早期CRT确实存在单线程版本（对应/ML选项），现已被废弃，当前/MT//MD均为多线程CRT，即使程序是单线程，CRT内部也会保留线程安全逻辑（如内存分配的同步锁）。
• (F)：调试CRT的填充值不止0xCCCCCCCC（未初始化栈内存），还有0xDDDDDDDD（已释放堆内存）、0xFDFDFDFD（预留内存）等，用于精准定位内存越界、重复释放等问题。
• (H)：errno在/MD下是线程本地存储（TLS）的函数调用，目的是保证多线程环境下的安全性，而/MT下每个模块有独立的errno全局变量副本。

二、核心要点(J)的深度解析

/MT下每个模块拥有独立CRT堆的本质原因：
静态链接CRT时，每个编译模块（EXE/DLL）都会将CRT的内存管理代码（包括堆初始化、malloc/free实现、内存块元数据结构）完整嵌入自身二进制。每个模块的堆是独立初始化的，内存块的管理信息仅对该模块的CRT代码可见。

典型问题场景：

• 用/MT编译的DLL导出函数void* AllocMem(size_t size) { return malloc(size); }
• 用/MT编译的EXE调用该函数后执行free(ptr)
• 运行时会直接崩溃：因为malloc是DLL的CRT堆分配的内存，free调用的是EXE的CRT堆释放逻辑，两个堆完全独立，EXE的CRT无法识别不属于自己的内存块，触发堆损坏报错。

而/MD模式下，所有模块共享同一个动态CRT的堆实例，malloc/free均调用DLL中的统一实现，内存可以在任意模块中分配和释放，无此限制。

三、遗漏的重要要点

1. CRT补丁更新：/MD模式下，CRT DLL可通过Windows更新获得安全补丁；/MT模式下，程序必须重新编译并发布新版本才能获得CRT的修复。
2. 调试/Release版本兼容性：不仅不能混合/MD和/MT，同一选项的调试与Release版本也不能混合链接（如/MDd的DLL不能和/MD的EXE配合），否则会因CRT内部结构不匹配导致运行时崩溃。
3. 线程本地存储差异：/MD下CRT的全局变量（如errno）天然是线程本地的；/MT下每个模块有独立的全局变量副本，若模块间需要共享全局状态，需自行处理线程安全逻辑。
4. 第三方库兼容性：使用第三方库时，必须确保库的编译选项与项目一致（如第三方库用/MT编译，项目也必须用/MT），否则会出现链接错误或运行时内存问题。

内容的提问来源于stack exchange，提问作者Thomas W.