Win32：编译64位程序的注意点

有许多程序员在遇到32位程序内存超过2G就崩溃了，因为2G是32位程序用户空间的最大值，于是就选择编译成64位程序，认为64位内存空间就一下在上升到了64位地址空间最大值了。

这种理解是不对的。关键还得由硬件来决定。

只能说：你的用户空间可能扩容了一点点而已，可能你的程序运行空间适当宽敞点了。但不一定。

硬件才是决定的关键。软件上的位数只是理论值。

64位地址线编址最大范围是16EB， （1EB=1024PB, 1PB=1024TB, 1TB=1024GB), 但是目前我们的CPU地址线却达不到64根（现在是2022年）。

举例：

• 第13代酷睿i9-13900@5.80GHZ的CPU，地址线37根支持最大编址才128GB；
• 你的主板，它可能只设计了36根地址线，最大支持64GB内存；
• 主板内存插槽上,实际上直插了可怜的4GB内存条;
• 这4GB是电脑上几百个程序共享的，剩余可用物理内存仅剩几百兆;

这种情况，实际上你的可用内存空间其实一点也没有增大，就算你编译成64位程序，也没有实质性的改变。

那什么情况下编译成64位程序，才是实实在在的有帮助了？

• 首先看windows是不是64位的
• 其次看可用物理内存还剩多少，如果仅剩1.50GB，你编译成64位也没用。如果你的物理可用内存还剩下3GB,那会有点用。
• 如果你的程序使用内存超过2G，但是小于3G，我建议你编译的时候启用大地址即可，无须编译成64位，因为编译成64位那依赖的一大批的32位DLL都要跟着编译，先不说你有没有源代码，你把它们都编译通过耗费的时间已经足够磨炼你的心性了。
• 如果你的内存条超过4GB，而且剩余物理空间远远大于2GB，你可以选择编译成64位。
• 程序使用内存都超过2GB了是不是该考虑一下程序架构不合理了，该从算法上去设计低内存消耗的架构了。

搁笔。如有疑问，可以留言或私信。