串口读取存包序列化场景下，使用fixed固定缓冲区是否有益？

你的场景里用fixed有没有意义？ #

先看你的实际需求：数据包接收后存入Queue<T>，只有在序列化的时候会读取一次obss，全程不修改数据。

• 用普通byte[]的情况：数组是托管引用类型，GC确实可能移动它的内存，但你只是读取一次——CLR会自动帮你处理内存地址的更新，根本不会有性能损耗。而且数组的写法不需要unsafe上下文，代码安全还容易维护。
• 用fixed byte obss[9]的情况：这会把9个字节直接嵌在结构体里，结构体变成非托管类型，确实不会被GC移动。但你的场景完全用不上这个特性——既不用频繁操作指针，也不需要稳定的内存地址，反而要开unsafe上下文，增加代码复杂度，还可能埋下内存安全的坑。

说白了，你的场景下用fixed没有实际意义，普通数组的方案反而更合适。

fixed关键字的通用和边角适用场景 #

通用适用场景 #

• 高频内存操作场景：比如高性能网络通信、音视频编解码这类需要频繁用指针直接读写缓冲区的场景，fixed能避免GC移动导致指针失效，省掉每次操作都重新固定地址的开销。
• 和非托管代码交互：要给C/C++写的非托管API传数据时，fixed能直接提供稳定的内存地址，不用额外做内存拷贝（比如不用Marshal.Copy）。
• 手动实现序列化/反序列化：如果要自己写二进制序列化逻辑，直接操作内存指针比遍历数组快很多，fixed能保证操作期间指针的稳定性。

边角场景 #

• 极致内存优化：当需要把结构体的内存占用压到最小的时候，fixed缓冲区直接嵌在结构体里，不会有数组对象的额外开销（每个数组都有对象头、长度字段这些额外内存）。如果要存几十万上百万个这种小结构体，累计能省不少内存。
• 避免空引用风险：fixed缓冲区是结构体的一部分，不会出现null的情况，而普通数组如果初始化错了可能会有空引用异常，适合那种绝对不能容忍空值的高安全场景。
• 实时系统场景：对延迟要求极高的实时系统里，GC的内存移动可能带来不可预测的延迟波动，fixed能避免这种潜在问题（不过这类场景一般会直接用全非托管内存方案）。

内容的提问来源于stack exchange，提问作者dragondangun