奔向64位② 内存管理(大内存环境)
软件世界
讨论的对象
我们在这一期和下一期中考虑一个程序设计中的最基本也是最重要的问题，亦即内存管理(Memory Management)的问题。如前所述，Windows通过物理地址扩展(Physical Address Extension)和地址窗口扩展(Address Windowing Extension)的方式，将实际的可用物理内存扩展到64GB，而全部可用内存则达到了几乎不可思议的16TB。
当然，这样的技术是非常超前的，谁能预计到今后的应用会用掉多少内存呢？况且在网格计算的环境中，单台服务器的内存也许并没有很多，但是多个网格节点的加和极为容易地就会突破现有的32位环境中的可用内存寻址极限──我始终认为这是64位的概念被引入的根本原因之一。
不过，这只是操作系统的观点，硬件上现在还没有任何一块CPU和主板支持64GB的物理内存。我们可以在两个方向上作些假设，这是问题不大的：我们先假设一个内存极为充足的环境下，我们应该怎样管理内存。这种情况下，主要考虑的问题集中在如何申请大块内存以及避免内存碎片，主要的应用环境是企业服务器中的大数据规模的应用程序。另一个环境中，则是内存极为有限，如只有数个MB下，如何胜任那些看起来需要较多内存的任务。这种环境比较具有挑战性，然而只要适当运用设计模式，也决不是无法完成的。小内存环境主要应用在新一代的嵌入式系统和平板个人电脑(Tablet PC)中。
大内存，大请求
大内存环境下的全部可用内存虽然高达16TB，但是每个进程能够分配到的最大内存是有限制的，当然这个“限制”高达40GB。对于数据库应用来说，这个数据量也许并不难达到。比如，一个国家级的图书馆，一条简单的SQL语句：
select * from libdata
可能在物理层被转化成：
BLOB p = (BLOB) malloc(COUNT(libdata)sizeof Tuple)
从而消耗大于40GB的内存，比如60GB。如果你来设计这个DBMS，你会怎么做？不错，你一定想到了，这种操作是不可能在个人机器上完成的，也不可能用于非服务器级的操作系统。所以我们当然应该充分利用Windows 2003 Server 64-bit的特性啦！
Windows 2003 Server 64-bit放弃了传统的32位平台上的对称负载多处理器(symmetrical multi-processor，SMP)模型，而改用非统一内存访问(Non-uniformed Memory Access，NUMA)模型。这样的改变，就消解了多处理器、大内存环境下的对称维持成本。一定要学会使用GetNumaAvailableMemoryNode()函数来在内存暂时不足的情况下征用其他处理器分组里的内存使用，并把申请大内存的线程分割成几个申请小内存的线程，并使用缓式评估技术，把暂时不用的内存请求加入到队列中。反正，必须注意的一点就是无论如何也不能在内存很大的情况下，还使用二级存储器。
预告：下期将为大家介绍新平台下小内存环境的内存管理和大内存环境下内存碎片的处理方式。