【IT168 技术文章】

         概念--什么是MMF?

　　从现在开始，MMF一词将在本文中大量出现。所以，我在此先对MMF做一个简单的描述。MMF，全称Memory Mapped Files，从宏观上看，它是一种数据内存映射的技术或者说管理动态内存的一种方法，Randy Kath这样定义到MMF：Memory-mapped files(MMFs) offer a unique memory management feature that allows applications to access files on disk in the same way they access dynamic memory-through pointers。从微观的角度，它主要具有以下几个特性：

　　概念：MMF是一个Windows对象，你可以通过Windows API创建和访问它。

　　本质：你可以把MMF当成一个普通的文件，只不过它贮存在系统内存中。

　　图一：MMF在各个进程间实现共享(来自MSDN Online)

　　特性：MMF可以被任何进程、线程所访问，这说明MMF具有可在进程间共享的特性，这也正是它的最大"魅力"所在。当然，因为所有的存取操作都在内存中进行，它也同时具备快速的特点。

　　实现原理：MMF是基于现代操作系统都普遍采用的虚拟内存(virtual memory)技术，而虚拟内存是基于一种被称作Paging的机制之上的(2)。所以可以这样认为，只要某个操作系统采用了基于Page的虚拟内存管理系统，它就可以实现MMF这种功能特性。

　　生存周期：MMF一直存在直到对它的最后一个引用被断开。

　　MMF其实是Windows平台下的一个基本特性，所有关于它的操作都可以通过Windows API获得，它使得DNA架构下COM跨进程访问数据成为可能。利用它，可以将数据库端的业务数据缓存到应用服务器端或者客户端的MMFs中，省去频繁访问数据库的开销，极大地提高系统访问性能。对于Java，我们也在Jdk1.4的NIO规范下找到了利用MMF的类集合，虽然在Jdk1.4的API文档中并没有明确地提出这样一个概念，但是我们在FileChannel和ByteBuffer类的文档中了解到FileChannel对象具有映射文件至内存的功能，从上面的介绍中我们可以看出这实际上就是创建了MMF。

　　背景--我们遇到什么困难?

　　我们希望对某个购买系统进行升级开发，自然就会涉及到平台的选型。原来的系统是基于微软的DNA架构，我们现在倾向于将之移植到J2EE平台。在此之前自然要进行必要的可行性分析，除去其他方面的考虑之外，我们最关心的自然落到关键技术的可行性上面，因为我们希望最大限度地利用原有系统的架构设计。

　　由于该系统基于微软的DNA架构，采用DCOM远程访问组件的方式，系统性能自然成为一个非常重要的考虑。所以，在原有系统中最大的亮丽之处在于花费大量工作来提高整个系统的性能指标，使得整个系统无论在系统响应速度，还是大数据量并发操作方面都有很杰出的表现。在这其中尤以数据缓存技术MMF的应用最为关键，通过服务器端和客户端的数据缓存，有效地提升了整个系统的性能。

　　图二：应用MMF后的系统图

　　图示说明：

　　图中的"Server Cache(Business Rules)"部分即为利用MMF进行的数据缓存;

　　另外，在客户端也大量利用到MMF，在图中并未标出。

　　整个系统沿着这样一个思路来利用MMF：每次系统启动的时候，程序访问数据库，获取表中数据，通过一系列步骤将之缓存至应用服务器端MMFs，见下图中黑线所示。以后客户端每次请求数据，将直接访问应用服务器端MMFs，见图中红线所示，并且同时将数据缓存到客户端。此后，如果有任何配置数据的改变，可以重新装载数据到MMFs。当然，与之配套的还有一套比较合理的定时数据比较机制。

　　图三、系统与MMF的交互图

　　以上这些就是我们所要实现的MMF缓存机制，简单地说，我们就是要在Java中找出与之对应的缓存机制解决方案。