一个大字节缓冲区还是几个小字节缓冲区?

你的直觉是正确的。每次需要增大数组时,都需要重新创建数组并复制现有字节。由于我们在这里谈论的是字节,数组的大小可能会很快变大。因此,您每次都会要求一块连续的内存,这取决于您的程序如何使用内存,可能可行也可能不可行。这实际上也将成为一个虚拟池。根据定义,池包含一组由多个客户端管理和共享的多个项目。

单阵列解决方案的实现也要复杂得多。好的一面是,单数组解决方案允许您提供可变大小的块,但这是以重新实现malloc为代价的:处理碎片等,这是您不应该进入的。

多阵列解决方案允许您使用N个缓冲区初始化池,并以简单的方式轻松管理它们。这绝对是我推荐的方法。

我不建议调整大小。从简单开始,一路往上走。一个字节缓冲区队列,当它耗尽时,会在末尾添加一个新的字节缓冲区,这将是一个良好的开端。您可能必须注意线程问题,所以我的建议是使用其他人的线程安全队列实现。

接下来,你可以看看进入大字节数组块的更复杂的“指针”,除了我的建议是有一个4k/16k(页面大小的两倍的幂)块的队列,当它满了时,你可以向队列中添加另一个大块。事实上,由于其复杂性和可疑的性能提升,我根本不建议这样做。

从简单开始,循序渐进。缓冲池,使其线程安全,看看你是否需要更多。

对多个缓冲区再投一票,但另外,由于你是异步做事的,你需要确保你的队列是线程安全的。默认值 Queue<T> 收藏绝对是 不 螺纹安全。

SO用户和MS员工 JaredPar 这里有一个很好的线程安全队列实现:
http://blogs.msdn.com/jaredpar/archive/2009/02/16/a-more-usable-thread-safe-collection.aspx

如果你使用单个缓冲区,你需要一个在需要时增长速度的策略。如果你以较小的增量增长它,你可能需要经常这样做,并经常复制所有数据。如果你以较大的增量增长它(比如下一个大小是前一个大小的1.5倍),那么当你只是试图增长缓冲区时,你就有可能面临“内存不足”的情况。对于一个可扩展的系统来说,这是一个双输的选择。这就是为什么最好重用小缓冲区。

对于垃圾收集堆,您应该始终青睐生命周期短、大小合适的小型缓冲区。这个。NET堆分配器 非常 快速的0代系列非常便宜。

当你保留一个静态缓冲区时,你将在程序的生命周期内耗尽系统资源。最坏的情况是,当它变得足够大,可以在大对象堆中移动时,它将成为无法移动的永久障碍。