前言
MemoryMappedFile(简称MMF)类是.NET中对内存映射文件进行操作的类，内存映射文件是非常高效的本地IO方案，由操作系统提供内存与IO文件之间的映射转换，对内存映射文件的更改由操作系统自动与物理文件进行高效的数据交换。在大文件处理中一般都需要使用到它，同时它也被用来做高效的进程间通讯的底层技术。
正因为它是如此的高效和便捷，所以在服务器程序开发中被广泛使用到。譬如，我们实现的基于Socket网络通讯程序中，在发送大数据时，需要对数据进行拆包组包的操作，这就往往需要对未接收完全的数据包进行缓存，在这个的场景中最好是使用MMF手动来对通讯包数据的缓存管理，倘若直接把这些数据放在.NET内置的集合、列表或字典中，那很可能会把.NET托管内存撑爆的。
当我把基于Socket的通讯类库代码运行在Mono on Linux中的时候，发现其使用到的MMF代码运行时异常了，本文就是对这一问题的处理过程的记录。
问题说明
Mono on Linux
我的代码是通过指定文件路径的方式创建MMF的，譬如文件路径为：/tmp/Zongsoft.Communication.Net#1.cache，在Windows中运行的很正常，但是在Mono on Linux中发生运行时异常：
难道在Mono中，需要先创建MMF对应的物理文件？好吧，那我就手动在临时文件夹下创建一个指定名称的空文件后，再来跑一遍，结果报了这个：
难道是Mono对通过文件路径来创建MMF支持不力？好吧，那就试试通过文件流的方式来创建MMF吧，结果还是不行：
看来，应该是跟capacity与物理文件的大小不匹配所致，好吧，那就在创建完文件流后，再使用文件流的SetLength来指定一个长度后，再通过该特定长度的文件流来创建MMF吧，结果果然创建成功！这说明在Mono中的创建MMF时，传入的目标文件必须是已经存在，且该文件长度不能为零。
由于刚才那个文件流的长度正好与创建MMF时capacity参数值相同，那么接下来我再来测试下，当文件流的长度与创建MMF时指定的capacity数值不同时，分别会发生什么情况。
1、文件流的长度大于创建MMF时capacity，成功，并且MMF创建后不会改变对应文件流的大小；
2、文件流的长度小于创建MMF时capacity：
.NET on Windows
再简单说明下MemoryMappedFile类在.NET Windows平台中的创建行为：
- 通过文件路径的方式，如果对应的文件不存在则自动创建一个对应指定capacity大小的文件。
- 通过文件流的方式，如果对应文件流的大小小于capacity则成功；如果对应文件流大小大于capacity则失败，提示指定的文件流大小太小。
Mono 源码简查
通过查看Mono-3.0.12的源码，发现MMF类的如下代码：
可见它们是都是通过CreateFromFile方法来处理的，并且将mapName作为文件路径来使用，所以，调用这两个方法要留心了，因为它与.NET(Windows)平台的实现是完全不同的，除此以外的其他创建或打开方法未实现，请勿使用！代码如下：
总结
综上所述，为了让代码能够在Linux和Windows平台都正常运行，建议统一使用
方法来创建MMF，并且在调用前确保指定的文件流大小与capacity参数值相同。