1. 从一次数据分包发送的“坑”说起最近在做一个工业上位机的数据采集模块遇到了一个挺典型的问题。设备通过串口上传数据协议规定每帧数据长度是128字节但我的接收缓冲区设置的是1024字节。理想情况下一次能收齐8帧完整数据但现实是网络抖动、设备响应延迟导致数据包经常是零零碎碎地过来有时候一次SerialPort.Read只能读到几十个字节有时候又能读到几百个字节。我的任务就是把这一堆支离破碎的byte[]按照128字节一帧的规则重新拼装成完整的报文。这本质上就是字节数组的合并与拆分。在C#里byte[]合并听起来是个基础操作但当你真正要在高性能、低延迟的场景下处理海量数据流时就会发现里面门道不少。选错了方法轻则内存碎片、GC垃圾回收压力山大程序卡顿重则数据错位、解析失败整个系统宕机。今天我就结合这个实际踩坑和优化的过程把C#中合并byte[]的几种方法掰开揉碎了讲清楚不止告诉你“怎么做”更重点讲明白“为什么这么做”以及“什么场景下该用哪种”。2. 基础操作Array.Copy 与 Buffer.BlockCopy 的正面较量当我们需要合并两个已知的、大小固定的byte[]时最直观的想法就是创建一个新数组然后把两个旧数组的数据拷贝进去。这里就有两位“选手”Array.Copy和Buffer.BlockCopy。很多人觉得它们差不多但在处理字节数组时区别就体现出来了。2.1 使用 Array.Copy通用但稍慢的“万金油”Array.Copy是System.Array类的静态方法它能处理任何类型的数组。用法很直接byte[] array1 new byte[] { 0x01, 0x02, 0x03 }; byte[] array2 new byte[] { 0x04, 0x05, 0x06 }; byte[] mergedArray new byte[array1.Length array2.Length]; Array.Copy(array1, 0, mergedArray, 0, array1.Length); Array.Copy(array2, 0, mergedArray, array1.Length, array2.Length); // mergedArray 结果 [0x01, 0x02, 0x03, 0x04, 0x05, 0x06]它的工作原理是每次调用Array.Copy它都会检查源数组和目标数组的类型执行类型安全检查然后进行内存块的复制。对于引用类型数组它还会处理元素的复制语义是复制引用还是复制对象。正因为这些安全检查它在绝对速度上不是最快的但安全性最高通用性最强。注意Array.Copy的参数顺序是(sourceArray, sourceIndex, destinationArray, destinationIndex, length)。务必确保目标数组destinationArray有足够的容量来容纳从sourceIndex开始拷贝的length个元素否则会抛出ArgumentException。2.2 使用 Buffer.BlockCopy为字节而生的“快枪手”Buffer.BlockCopy是System.Buffer类的静态方法这个类就是专门为操作基元类型特别是字节的数组而设计的。byte[] array1 new byte[] { 0x01, 0x02, 0x03 }; byte[] array2 new byte[] { 0x04, 0x05, 0x06 }; byte[] mergedArray new byte[array1.Length array2.Length]; Buffer.BlockCopy(array1, 0, mergedArray, 0, array1.Length); Buffer.BlockCopy(array2, 0, mergedArray, array1.Length, array2.Length);它的核心优势在于速度。Buffer.BlockCopy在内部实现上假设你传入的就是基元类型数组如byte,int,float它直接操作内存块跳过了很多Array.Copy需要的类型检查和元数据访问相当于“我已知这是字节直接内存搬运”。在需要频繁、大量合并字节数组的场景下比如网络通信、文件I/O它的性能优势非常明显。参数上的一个关键区别Buffer.BlockCopy的索引和长度参数是以字节为单位的。这对于byte[]来说很自然但如果你用它来拷贝int[]就要小心了。Buffer.BlockCopy(sourceIntArray, 0, destIntArray, 0, length)里的length指的是字节数而不是元素个数。拷贝4个intlength应该是4 * sizeof(int) 16字节。如何选择追求极致性能且确定操作的是byte[]等基元类型数组优先使用Buffer.BlockCopy。需要拷贝非基元类型数组如自定义类对象的数组或不确定数组类型使用Array.Copy。代码可读性与维护性优先如果数据量不大性能差异可忽略不计两者皆可。Array.Copy的命名更通用可能对团队其他成员更友好。在我的数据采集模块中因为处理的是纯字节流且频率很高所以我毫无悬念地选择了Buffer.BlockCopy。3. 动态合并的利器MemoryStream 与 List前面讲的是合并两个已知数组。但在现实世界的流式处理中我们经常面临的是“不知道会有多少数据包过来需要动态累积”的场景。比如我那个串口数据接收每次收到的字节数不定我需要一个缓冲区把它们攒起来直到凑够一帧完整的128字节。3.1 使用 MemoryStream面向“流”的思维MemoryStream是System.IO命名空间下的类它把一个byte[]包装成一个可以像文件流一样进行读写操作的流。用它来合并数组非常符合“数据流”的抽象。using System.IO; byte[] chunk1 ReceiveDataFromSerialPort(); // 假设第一次收到50字节 byte[] chunk2 ReceiveDataFromSerialPort(); // 假设第二次收到78字节 using (MemoryStream ms new MemoryStream()) { ms.Write(chunk1, 0, chunk1.Length); ms.Write(chunk2, 0, chunk2.Length); // 可以继续 ms.Write(chunk3, ...); // 获取合并后的完整字节数组 byte[] completeBuffer ms.ToArray(); // 或者如果你只想获取有效数据部分避免内部缓冲区可能存在的空余空间 // byte[] completeBuffer ms.GetBuffer(); // Array.Resize(ref completeBuffer, (int)ms.Length); }为什么适合动态合并自动扩容MemoryStream内部维护一个字节数组缓冲区。当你写入的数据超过当前缓冲区容量时它会自动分配一个更大的新数组并把旧数据拷贝过去。你不需要自己关心数组扩容的细节。位置管理它有Position属性每次Write后会自动后移你永远是在尾部追加数据逻辑清晰。与其他流API兼容很多网络库如TcpClient.GetStream()或序列化库如BinaryFormatter返回的就是Stream对象直接用MemoryStream与之对接非常方便。实操心得与坑点using语句务必使用using语句或在finally块中调用Dispose()。虽然MemoryStream的Dispose主要作用是标记自己不可用但这是一个好的习惯尤其是当它持有非托管资源尽管MemoryStream默认没有或未来代码演变时。GetBuffer() vs ToArray()这是个大坑GetBuffer()返回的是内部使用的原始字节数组这个数组的长度可能大于实际写入的数据长度ms.Length。如果你直接使用这个数组可能会读到一堆未初始化的0值。ToArray()方法会创建一个新的、长度恰好等于ms.Length的数组并把数据拷贝过去。所以在绝大多数需要获取合并后数据的场景下应该使用ToArray()。GetBuffer()仅在需要避免一次额外拷贝、且能精确控制使用长度配合ms.Length的高性能场景下使用。初始容量如果你能预估最终数据的大致大小可以在创建MemoryStream时指定初始容量new MemoryStream(estimatedCapacity)这样可以减少甚至避免自动扩容带来的数据拷贝开销提升性能。在我的项目中最初版本就是用一个MemoryStream来累积接收到的所有字节然后在另一个线程里不断检查ms.Length一旦大于等于128字节就读取并解析一帧同时从流中移除已处理的数据这需要一些技巧比如将剩余数据读出来再重新写入或者使用Circular Buffer环形缓冲区这是另一个话题了。3.2 使用 List 更直观的集合操作如果你更习惯于操作集合那么Listbyte可能是更直观的选择。Listbyte byteList new Listbyte(); byte[] chunk1 ReceiveDataFromSerialPort(); byte[] chunk2 ReceiveDataFromSerialPort(); byteList.AddRange(chunk1); byteList.AddRange(chunk2); // 可以继续 byteList.AddRange(chunk3); // 获取合并后的数组 byte[] completeBuffer byteList.ToArray();它的优点API直观AddRange方法语义非常清晰就是“添加一系列元素”。动态扩容和MemoryStream一样ListT内部也有数组会自动扩容。灵活的元素操作除了合并你还可以方便地插入(InsertRange)、删除(RemoveRange)特定位置的字节这在某些协议解析如移除帧头帧尾时可能有用。与MemoryStream的对比与选择性能对于纯粹的字节追加操作两者性能在同一个数量级。MemoryStream可能因为更底层而略有优势但通常差异不大。Listbyte.ToArray()和MemoryStream.ToArray()都会创建新数组并拷贝数据。功能侧重MemoryStream的核心是“流”除了写它还提供了读、寻址(Seek)、设置长度(SetLength)等流式操作。Listbyte的核心是“动态数组”提供了丰富的集合查询和修改方法。选择建议如果你的数据本身就是以“流”的形式产生或消费如网络流、文件流或者后续操作需要Stream接口如调用一个接受Stream参数的方法用MemoryStream。如果你需要频繁地对累积的字节进行复杂的查找、插入、删除等集合操作用Listbyte。如果只是简单的动态累积并转换为数组两者均可看个人或团队的编码习惯。我项目中的一个日志模块需要将不同来源的文本转换成byte[]合并成一个大的日志块因为涉及一些条件判断和过滤可能跳过某些字节块使用Listbyte的AddRange配合条件语句代码写起来更顺手。4. 高性能与零拷贝的探索Span 与 Memory当性能成为瓶颈或者你希望减少不必要的内存分配和拷贝时C# 7.2引入的SpanT和.NET Core 2.1引入的MemoryT就成了救星。它们提供了对任意内存区域数组、非托管内存、栈内存等的统一、安全的视图并且支持切片操作而无需分配新数组。4.1 使用 Span 进行合并栈上或非托管内存SpanT是ref struct只能存在于栈上这使得它极其轻量且高效但不能被装箱因此不能用于异步方法、类字段等场景。它非常适合局部变量、方法参数中的高性能操作。假设我们有两个栈上的字节数组或者来自非托管内存想合并它们byte[] array1 new byte[] { 1, 2, 3 }; byte[] array2 new byte[] { 4, 5, 6 }; // 创建一个足够大的新数组来存放合并结果 byte[] mergedArray new byte[array1.Length array2.Length]; // 获取新数组的Span Spanbyte mergedSpan mergedArray; // 使用Span的CopyTo方法进行拷贝 array1.AsSpan().CopyTo(mergedSpan); array2.AsSpan().CopyTo(mergedSpan.Slice(array1.Length)); // Slice不会创建新数组 // mergedArray 现在包含了 [1,2,3,4,5,6]关键点AsSpan(): 将数组转换为Spanbyte这是一个零开销的操作。CopyTo(SpanT destination): 将当前Span的内容拷贝到目标Span。对于字节数组其底层实现很可能调用类似Buffer.MemoryCopy这样的高性能内存操作。Slice(int start): 这是Span的精华所在。mergedSpan.Slice(array1.Length)返回的是mergedSpan从索引array1.Length开始到结尾的一个视图它没有分配任何新的数组内存我们直接将array2的数据拷贝到这个视图所代表的内存区域就完成了合并。这种方式的优势零额外分配对于切片Slice操作不分配新数组。代码简洁高效链式调用表达力强且底层是高性能内存操作。安全性Span有边界检查能防止内存越界访问比直接使用指针安全。4.2 使用 Memory 进行异步或跨上下文合并MemoryT可以看作是SpanT的“可装箱”版本。它可以存在于堆上因此可以用作字段、可以跨异步await使用。当你需要在异步方法中操作内存或者需要将内存块作为类的一部分持有时就用MemoryT。public async Taskbyte[] MergeDataAsync(IAsyncEnumerablebyte[] dataChunks) { using (var memoryStream new MemoryStream()) { await foreach (var chunk in dataChunks) { // 将byte[]转换为Memorybyte并写入MemoryStream // MemoryStream 有接受 ReadOnlyMemorybyte 的WriteAsync重载 await memoryStream.WriteAsync(chunk.AsMemory()); } return memoryStream.ToArray(); } }在这个异步示例中chunk.AsMemory()将数组转换为Memorybyte然后WriteAsync接受这个Memorybyte参数。MemoryT使得在异步流水线中高效传递和操作内存块成为可能而无需等待整个数据块都加载完毕或进行多次拷贝。在合并场景下的高级用法 你可以创建一个大的byte[]然后获取其Memorybyte再通过MemoryT.Span属性获取其Spanbyte进行高速拷贝最后再将这个Memorybyte传递给其他需要处理连续内存的异步API。这结合了高性能和异步友好性。重要注意事项SpanT和MemoryT都是对底层内存的“视图”。修改通过Span或Memory看到的内容会直接影响原始的数组或内存块。对于简单的、同步的、局部的数组合并SpanTCopyToSlice的组合通常是性能最高的写法之一。如果你的合并逻辑需要跨越异步边界或者需要将合并后的内存块存储起来稍后处理那么使用MemoryT更合适。在我的数据采集模块的性能优化阶段我将核心的数据拼装循环从使用Buffer.BlockCopy改为了使用Spanbyte的CopyTo和Slice虽然对于单次操作提升微乎其微但在每秒处理成千上万帧数据的压力测试下整体的CPU消耗和GC触发次数有了可观的下降。5. 大型数据流合并策略与内存管理实战当我们处理的不再是两个小数组而是持续不断、可能无限长的数据流如视频流、持续日志、大文件分片上传时简单的“创建新数组拷贝”策略会导致严重的内存和性能问题。频繁分配大数组会引发GC频繁工作导致程序卡顿。5.1 预分配缓冲区与循环复用这是处理流式合并最基本也是最重要的优化思想避免在热路径频繁执行的代码段中分配新内存。错误示范在循环中不断new数组// 模拟不断收到数据块 while (hasMoreData) { byte[] newChunk ReceiveNextChunk(); // 每次合并都创建新数组GC压力巨大 mergedData MergeArrays(mergedData, newChunk); // MergeArrays内部会new一个新数组 }正确做法预分配与复用// 1. 预估一个合理的初始缓冲区大小例如1MB int bufferSize 1024 * 1024; byte[] buffer new byte[bufferSize]; int dataLength 0; // 记录缓冲区中已有数据的长度 while (hasMoreData) { byte[] newChunk ReceiveNextChunk(); int chunkSize newChunk.Length; // 2. 检查缓冲区剩余空间是否足够 if (dataLength chunkSize buffer.Length) { // 3. 缓冲区不足需要扩容这是一个相对昂贵的操作应尽量避免 // 通常策略是翻倍扩容以减少扩容次数 int newSize Math.Max(buffer.Length * 2, dataLength chunkSize); Array.Resize(ref buffer, newSize); // 注意Array.Resize会创建新数组并拷贝数据仍有开销。 } // 4. 将新数据块拷贝到缓冲区的尾部 Buffer.BlockCopy(newChunk, 0, buffer, dataLength, chunkSize); dataLength chunkSize; } // 5. 处理完成后如果只需要有效数据可以裁剪数组 if (dataLength buffer.Length) { Array.Resize(ref buffer, dataLength); } return buffer;策略解析预分配根据业务场景预估一个初始大小一次性分配避免小碎片的频繁GC。检查与扩容在添加数据前检查容量。扩容策略很重要成倍扩容如翻倍是常见做法它使得扩容的均摊时间复杂度接近O(1)。虽然单次扩容有成本但总扩容次数是对数级的。复用缓冲区整个循环只使用一个或少数几个buffer数组极大地减少了内存分配压力。最终裁剪处理完后如果缓冲区很大但有效数据不多可以Array.Resize裁剪释放多余内存。5.2 使用 ArrayPool 实现缓冲区租赁.NET Core/.NET 5 提供了System.Buffers.ArrayPoolT这是一个高性能的数组池。你可以从池中“租用”(Rent)一个数组用完后“归还”(Return)给池。池会复用这些数组从而完全避免在热路径上分配新数组。using System.Buffers; // 从共享池租用一个最小长度为 targetSize 的数组 int targetSize dataLength newChunk.Length; byte[] buffer ArrayPoolbyte.Shared.Rent(targetSize); try { // ... 使用buffer进行数据拷贝合并 ... Buffer.BlockCopy(existingData, 0, buffer, 0, dataLength); Buffer.BlockCopy(newChunk, 0, buffer, dataLength, newChunk.Length); dataLength newChunk.Length; // 处理buffer中0到dataLength-1的数据... } finally { // 务必归还否则会导致内存泄漏池中数组无法被复用 ArrayPoolbyte.Shared.Return(buffer); // 注意归还后buffer数组不能再被使用因为可能已被池分配给其他代码。 }为什么用ArrayPool零分配Rent方法可能返回一个池中已有的、大小足够可能比你请求的更大的数组完全避免了new byte[]。减少GC压力池化的数组长期存在不会被GC回收从而减少了Gen 2 GC完整GC的发生频率这对需要高吞吐、低延迟的应用至关重要。适合短生命周期、大小不定的缓冲区网络数据接收、临时计算缓冲区等场景的绝配。重要警告必须归还使用try-finally确保数组被归还。归还后即失效归还后该数组引用应立即置为null或不再使用因为它里面的内容可能随时被其他租用者覆盖。不清零内容Return的数组不会被自动清零。下次Rent到的数组可能包含上次使用的旧数据。因此如果你的逻辑依赖于数组的初始值如0必须在租用后自行清理所需的部分或者使用Rent的重载Rent(minimumLength, bool clearArray)请求清空数组但有性能开销。在我的高性能数据采集服务中每个连接会话都会从ArrayPool租用一个固定大小的缓冲区如8KB用于接收数据。当缓冲区满或收到完整报文时将有效数据部分拷贝出来处理然后清空缓冲区通过Array.Clear或重置偏移量以备下次接收直到连接关闭时才将缓冲区归还给池。这几乎完全消除了因数据接收导致的内存分配。5.3 链表式结构管理超大数据块对于极端情况比如需要合并的数据总量可能远超物理内存例如处理数十GB的文件上述基于连续数组的方法就不适用了。这时可以考虑使用链表(LinkedListbyte[])或自定义的块状链表结构来管理数据块只在需要时才将某些块加载到内存。public class ChunkedByteBuffer { private LinkedListbyte[] _chunks new LinkedListbyte[](); private long _totalLength 0; public void Append(byte[] chunk) { _chunks.AddLast(chunk); _totalLength chunk.Length; } // 仅在需要时如最终写入文件才将数据合并到连续流 public void WriteToStream(Stream outputStream) { foreach (var chunk in _chunks) { outputStream.Write(chunk, 0, chunk.Length); } } // 或者提供一个接口允许按块处理避免一次性合并 public IEnumerableArraySegmentbyte GetChunks() { foreach (var chunk in _chunks) { yield return new ArraySegmentbyte(chunk); } } }这种方式牺牲了随机访问的便利性你无法直接通过索引buffer[1000000]访问数据但换来了处理海量数据的能力。.NET中MemoryStream在处理超大容量时内部也可能采用类似的策略在.NET Core的某些版本中超大MemoryStream会使用多个数组块。