因此,这与处理大对象堆并尝试最小化实例化byte []的次数有关。基本上,我有OutOfMemoryExceptions,我觉得这是因为我们实例化了太多的字节数组。当我们处理几个文件时,程序工作正常,但它需要扩展,目前它不能。
简而言之,我有一个从数据库中提取文档的循环。目前,它一次拉一个文档然后处理文档。文件的范围可以从小于1兆欧卡到400欧元不等。 (因此我为什么一次处理一个)。以下是伪代码,在我进行优化之前。
所以我正在做的步骤是:
调用数据库以查找最大文件大小(然后将其乘以1.1)
var maxDataSize = new BiztalkBinariesData().GetMaxFileSize();
maxDataSize = (maxDataSize != null && maxDataSize > 0)
? (long)(maxDataSize * 1.1)
: 0;
var FileToProcess = new byte[maxDataSize];
然后我进行另一个数据库调用,从数据库中提取所有文档(没有数据)并将它们放入IEnumerable中。
UnprocessedDocuments =
claimDocumentData.Select(StatusCodes.CurrentStatus.WaitingToBeProcessed);
foreach (var currentDocument in UnprocessDocuments)
{
// all of the following code goes here
}
然后我从外部源填充我的byte []数组:
FileToProcess = new BiztalkBinariesData()
.Get(currentDocument.SubmissionSetId, currentDocument.FullFileName);
这是问题所在。将currentDocument(IClaimDocument)传递给其他要处理的方法会更加清晰。因此,如果我将currentDocument的数据部分设置为预格式化的数组,那么这将使用现有的引用吗?或者这会在大对象堆中创建一个新数组吗?
currentDocument.Data = FileToProcess;
在循环结束时,我会清除FileToProcess
Array.Clear(FileToProcess, 0, FileToProcess.length);
答案 0 :(得分:6)
第1步:
var FileToProcess = new byte[maxDataSize];
第3步:
FileToProcess = new BiztalkBinariesData()
.Get(currentDocument.SubmissionSetId, currentDocument.FullFileName);
您的步骤1完全没必要,因为您在步骤3中重新分配了阵列 - 您正在创建新阵列,而不是填充现有阵列 - 所以基本上步骤1只是创建更多的GC工作,如果你按快速顺序执行(如果它没有被编译器优化,这是完全可能的)可能会解释你所看到的一些内存压力。
答案 1 :(得分:3)
数组是引用类型,因此您将传递引用的副本,而不是数组本身的副本。这只适用于值类型。
这个简单的代码片段说明了数组如何作为引用类型:
public void Test()
{
var intArray = new[] {1, 2, 3, 4};
EditArray(intArray);
Console.WriteLine(intArray[0].ToString()); //output will be 0
}
public void EditArray(int[] intArray)
{
intArray[0] = 0;
}
答案 2 :(得分:2)
它会使用现有的参考,不用担心。数组的内容不会被复制。
答案 3 :(得分:2)
您的问题可能出在" BiztalkBinariesData"的实施和使用中。类。
我不确定它是如何实现的,但我确实看到你每次都声明一个新实例
new BiztalkBinariesData()
要考虑的事情......
答案 4 :(得分:1)
我有OutOfMemoryExceptions,我觉得这是因为我们实例化了太多的字节 阵列的
不,这是因为你分配了LARGE数组。将它们限制为48kb或64kb,并将它们与自定义容器“组合”。 64kb意味着您可以使用索引的较高2个字节来确定要使用的数组。容器包含一个数组数组。处理非常大的对象会导致崩溃,并且无法在以后分配一个大型数组。