C# 执行SqlBulkCopy时内存泄漏

我遇到以下代码中发生的内存泄漏问题：

 public void BulkInsert(string tableName, IDataReader reader, String connectionString)
    {
        using (var connection = new SqlConnection(connectionString))
        {
            connection.Open();
            using (var bulkCopy = new SqlBulkCopy(connection))
            {
                bulkCopy.DestinationTableName = tableName;
                bulkCopy.BulkCopyTimeout = 900;

                try
                {
                    bulkCopy.WriteToServer(reader);
                }
                catch (Exception ex)
                {
                    Console.WriteLine(ex.Message);
                }
                finally
                {
                    reader.Close();
                }
            }
        }
    }

此代码段执行了数千次，因此，内存不足异常只需一分钟即可发生。Ants报告这是因为IDataReader指向的行没有被GC收集。然而，当我注释掉下面这行代码时，没有泄漏，这就是我如何将问题隔离到这段代码中的原因

bulkCopy.WriteToServer(reader);

有人建议如何防止内存泄漏吗

先谢谢你

呼叫代码：

 var reader = datatable.CreateDataReader();
 BulkInsert(tablename, reader, connectionString);
 reader.Dispose();
 datatable.Dispose();

---

您可能需要处理读取器，以便GC收集它。在最后一个块中，尝试调用Dispose

finally
{
    //reader.Close();
    reader.Dispose();
}

---

我绝对不喜欢回答我自己的问题，但我终于找到了解决办法，虽然我觉得犯了这个错误很愚蠢，但我只是想把它作为答案贴出来，以防其他人遇到这个问题，所以没有人在这个问题上浪费宝贵的时间

内存泄漏根本不是提供的代码段造成的-事实上，它根本不是泄漏

查看性能分析后，我发现BulkCopy调用在速度上是我整个程序的瓶颈。我有一个生产者-消费者模式向它提供数据表供它插入

我认为内存分析器向我显示了在我运行代码时没有处理的DataTable对象。这些实际上是等待插入的队列表，但由于我正在重新使用测试数据，队列表已经在数据库中（因此似乎已经插入）

通过注释掉BulkCopy行，我实际上消除了瓶颈，数据表被快速处理，因此内存分析器上没有显示任何问题。这使它看起来像是Bulkcopy线路出了故障

当我用1s延迟替换BulkCopy代码时，这还不足以成为瓶颈。只有当我用5秒的延迟替换批量拷贝时，我才注意到我的消费者-生产者队列大小失控了。。。。因此，我的内存很快就用完了

---

感谢所有在这个问题上花时间的人。很抱歉，没有更有趣的答案。

调用此代码的代码是否处理了

IDataReader

？可能是后期绑定的问题-这就是注释行仍然有效的原因-好主意！我现在会再次检查读卡器是否正确处理。您要传递什么类型的数据读卡器？理论上，datareader一次只能保存一行（直到调用MoveNext），SqlBulkCopy应该正确地处理它们。我认为我正确地处理了读卡器和表。读卡器作为参数传递，调用方必须处理它（用例除外），当显式设置参数（例如

bool disposeReader

）打开方法内部的可选处理时。此外，调用

Close

然后调用

Dispose

是没有用的。调用

Dispose

就足够了。我插入了这段代码，不幸的是，它对应用程序的内存配置文件没有任何影响。我还有漏洞。虽然我很欣赏这个建议，但这只是一个愚蠢的想法，但是您是否在处理读取器之前尝试过处理datatable…函数中的SqlConnection是否被正确处理，或者您只是在每次调用函数时创建一个新连接？