C产品如何满足特定用户需求？

本文共计979个文字，预计阅读时间需要4分钟。

在Windows系统中，使用`MemoryMappedFile`依赖内核对象命名空间。如果命名空间中已存在同名共享内存对象，将导致`IOException`异常：

实操建议：

• 用带前缀的固定格式命名，例如 "Global\MyApp_Data_v2"（Global 前缀确保跨会话可见，适合服务与桌面进程通信）
• 避免硬编码字符串，改用常量或配置项；调试阶段可在名称后追加 Process.GetCurrentProcess().Id 辅助排查
• 若需多实例隔离，把用户 SID 或应用实例 ID 注入名称，而非依赖随机数——随机数无法保证跨进程一致

Write/Read 必须严格对齐偏移和长度，否则读到脏数据

MemoryMappedViewAccessor 不做边界校验，越界写入会破坏相邻内存区域（可能影响其他字段甚至引发 AccessViolationException），而越界读取则返回零值或旧垃圾数据，错误极其隐蔽。

实操建议：

• 定义结构体时显式使用 [StructLayout(LayoutKind.Sequential, Pack = 1)]，禁用编译器填充
• 用 Marshal.SizeOf<T>() 替代 sizeof(T) 获取实际序列化长度（尤其含引用类型时）
• 写入前检查 accessor.Capacity - offset >= dataSize；读取时用 TryRead 而非 Read 避免异常中断
• 示例：写入一个 int 到偏移 0 处：

  using var accessor = mmf.CreateViewAccessor(); accessor.Write(0, 123); // 正确：偏移 0，写入 4 字节 int accessor.Write(1, 123); // 危险：从第 1 字节开始写，跨字节破坏数据

Dispose 顺序错误会导致子进程崩溃或句柄泄漏

常见误操作是父进程先释放 MemoryMappedFile 实例，但子进程仍在用其创建的 MemoryMappedViewAccessor。此时子进程访问会触发 ObjectDisposedException 或直接崩溃——.NET 不保证跨进程资源生命周期同步。

实操建议：

• 所有持有映射对象的进程，都应自行调用 Dispose()，不要依赖父进程“统一清理”
• 若需协调销毁时机，用命名 EventWaitHandle 通知对方“我已退出”，再安全释放；切勿用 GC.Collect() 强制回收
• 在 finally 块或 using 语句中释放 MemoryMappedViewAccessor 和 MemoryMappedFile，且 accessor 必须先于 mmf 释放

大块数据共享时，用 CreateViewStream 比 CreateViewAccessor 更稳

当共享数据超过几 MB，频繁调用 accessor.Write 写入结构体会因重复 pinning 和 marshal 开销变慢，且易触发 GC 压力；而 ViewAccessor 的指针模式在超长数据下容易因地址截断出错（尤其 x86 进程访问大内存）。

实操建议：

• 传输二进制流（如图片、日志块）优先用 mmf.CreateViewStream(offset, length, FileAccess.ReadWrite)，配合 BinaryWriter/BinaryReader
• 流模式天然支持分段读写，不强制加载整块内存，适合不确定大小的数据
• 注意：流不支持并发写入，需额外用 Mutex 同步；若需高并发，改用多个小映射文件 + 索引表

跨进程共享不是“打开就完事”，最麻烦的是两边对结构体布局、生命周期、同步点的理解稍有偏差，程序就会在某个凌晨三点突然返回 0 或抛出无法捕获的异常。别省略 try/catch 包裹 Write 和 Read，也别相信“测试时没问题”。