64位系统的那些事

 64位系统已是大势所趋了，就像32位代替16位一样。64位系统的优势非常明显，可以访问更多的物理内存，增强cpu计算能力，增大寄存器的存储能力，增大I/O的吞吐率……除了兼容性以外，几乎没什么缺点了。这些优点当中最大和最迫切需要的当非“访问内存容量的增加”莫属了，尤其是当前企业级的数据库服务器，对内存要求非常高，这样可以提高性能。尽管Sql server数据库具有 AWE功能，但AWE(一组API)的实现本身就要占用大约300M左右的内存，且动态映射地址也会损耗一些性能，另外对内存的使用不够灵活（会锁定内存页），基于这些缺点，为什么不直接采用64位系统呢？！

另外，现在的服务器渐渐不支持32位操作系统了（某些提供数据中心服务的机构尽管也有32位系统，但都是一些老的服务器，性能相对较低），微软的操作系统从windowsServer2008R2及以后版本都只有64位的，不支持32位，所以不管是从硬件、软件角度还是未来发展趋势来看，64位已是势不可挡了。

尽管64位有这么多好处，但真正使用起来还需要注意一些问题，下面是我的一些总结。

在用Visual Studio编译项目时，默认是AnyCpu(vs2010是这样，其它版本VS可能略有不同)，当项目运行在64位系统上时，项目就是64位的，当运行在32位系统上时，项目就是32位的。这个看上去很方便，因为不用担心项目的目标运行环境是32位的还是64的，可实际使用时在某些情况下会有问题。

比如当项目中引用了第三方32位组件（一般第3方正式组件都明确了是32位还是64位），编译项目使用的是AnyCpu，这时如果将项目运行在64位系统上，系统会报错的。因为系统是64位的，在加载项目时会将AnyCpu变成64位，并在64位的环境下运行，当项目调用第三方组件时就会出错了，因为64位环境无法运行32位的应用程序（只有兼容的32位环境才可运行32位系统）。

如果在编译项目时明确指定32位cpu，就会避免这种错误，因为32位的项目在64位系统上运行时将以兼容的32位环境运行，这样调用32位第三方组件就不会报错了。

那到底何时AnyCpu，何时明确指定32/64位呢？

基本原则是：当项目没有使用明确指定编译位数的第三方组件时可以使用anycpu，增加目标运行系统的灵活性，反之应明确指定编译版本，避免出错。

其实.net framwork也是有32位和64位的，可为什么32位的.net应用程序也能在64位系统上运行呢，那是因为64位机器上既有64位的.netframwork，也有32位的.net framwork，如下图所示，

                             

根据操作系统不同，会预安装一些32/64位.net framwork，如果没有满足需要的，需手动安装。

如果需要在64位（以Window 2008 R2为例，下面也一样）系统上注册32位的COM组件，需要在32位的兼容模式下注册，即在下面的目录：

    

 

另外Window Server2008 R2以明确表示不再支持.net framwork1.1，尽管.net framwork1.1的程序也能运行，但存在不稳定情况，最好不要用。

运行64位的操作系统机器CPU一定要支持64位的，不然在安装操作系统时就会出错了。不过现在大部分的CPU都是64位的，同时兼容32位。

针对Web应用程序运行在Window Server2008R2上，应用程序池也提供了一个属性Enable 32–bit Applications去处理32/64位的问题，如果设为true，则表示是在32位兼容模式下运行，反之就是64位环境，如下图所示：