如何解决JVM自带vcruntime140.dll引发的链接冲突问题？

可行解决方案 #

1. 静态链接VC运行时 #

将你的C++库静态链接到VC运行时库（编译时选择/MT或/MTd选项），把所需的vcruntime和msvcp代码打包进库文件内部，彻底规避与JVM附带DLL的冲突。

• 优点：完全解决版本冲突问题，无需依赖外部运行时文件。
• 缺点：库体积会明显增大；无法自动获取微软发布的运行时安全更新；多动态库项目可能出现代码冗余。

2. 使用版本化VC运行时DLL #

微软从MSVC 14.20版本开始提供版本化C++运行时DLL（如vcruntime140_1.dll、msvcp140_2.dll等），这类文件不会被JVM默认附带。将库编译为依赖这些版本化文件：

• 在MSVC项目属性中，进入C/C++ -> 代码生成 -> 运行库，选择多线程DLL (/MD)或多线程调试DLL (/MDd)（需确保编译器版本支持版本化运行时）。
• 优点：保留动态链接的体积优势，同时避开JVM自带的旧版运行时；用户可通过安装VC Redistributable获得安全更新。
• 缺点：需要确保用户系统已安装对应版本的VC运行时，可通过引导用户安装官方VC Redist包解决。

3. 强制优先加载系统最新版运行时 #

通过代码控制DLL加载顺序，在加载绑定库前强制加载系统目录下的14.40版本运行时：

• 借助JNI调用Windows API LoadLibraryEx，指定LOAD_LIBRARY_SEARCH_SYSTEM32标志加载C:\Windows\System32\vcruntime140.dll和C:\Windows\System32\msvcp140.dll（注意区分64位/32位路径），再加载你的绑定库。
• 注意：不要在DllMain中执行DLL加载操作，可能引发死锁或未定义行为，建议在库的初始化函数中完成。

4. 引导用户安装VC Redistributable（配合加载优先级调整） #

严格遵循微软最佳实践，在Java应用启动流程中加入检测逻辑：

• 检查系统是否已安装14.40及以上版本的VC Redistributable。
• 若未安装，引导用户从官方渠道下载安装对应版本的包。
• 补充：由于Windows DLL搜索顺序优先当前进程目录（JVM所在目录），安装系统运行时后，可通过JNI调用SetDllDirectory API，强制优先搜索系统目录，或修改Java启动脚本将系统目录加入PATH最前端。

关于微软与JVM做法的合理性分析 #

• 微软的做法更符合Windows平台长期维护逻辑：将VC运行时作为系统组件统一分发更新，既能保证所有应用使用的运行时版本一致、安全，又能避免多应用分发不同版本DLL导致的冲突，用户可及时获取安全补丁。
• JVM开发者的做法是为了简化部署：自带运行时DLL是为了让用户下载JVM后无需额外安装依赖即可直接使用，降低跨平台部署门槛，但这种做法违反了Windows平台最佳实践，本质是将应用独立性置于系统整体兼容性之上。

两者出发点不同，但从系统稳定性、安全性和长期兼容性来看，微软的规范更具合理性。

内容的提问来源于stack exchange，提问作者Nick Williams