SqlCommand.Dispose() 未处理其中的 SqlParameters - 内存泄漏 - C#.NET

Question

我有一个以 MS SQL Server 2005 作为后端的 Windows 窗体应用程序。我已经在表单中编写了代码，使用 SqlConnection、SqlCommand 对象调用一些存储过程，并且我正确地处理了所有内容。

我已经通过调用处理了 sqlcommand 对象

oSqlCommand.Dispose()

，但我目睹了我的应用程序消耗了大量内存。我基本上将大型 XML 文件作为 SqlParameters 传递。

我最终决定使用 RedGate 内存分析器对其进行内存分析，并且我注意到 System.Data.SqlClient.SqlParameters 未释放。

对此有什么见解吗？

感谢

NLV

Answer 1

我看到这个：

我妥善处理了所有东西。

还有这个：

我通过调用 oSqlCommand.Dispose() 处理了 sqlcommand 对象

但是，这些是互斥的！如果您直接调用 .Dispose()，你做错了。具体来说，您保留了异常可能导致程序跳过对 Dispose() 方法的调用的可能性。处理命令的“正确”方法是使用 using 块创建它，如下所示：

using (SqlCommand cmd = new SqlCommand("sql string here"))
{
    // use the command here
} // compiler transforms your code to make sure .Dispose() is called here

现在，我从问题中得出结论，这不是目前的主要问题，但这是值得深入探讨的一点。

至于参数的问题：SqlParameters 没有实现 IDisposable。因此，您不要直接处置它们。它们是完全托管的资源，这意味着它们在无法再访问后的某个时刻会被垃圾收集器清理掉。您无需执行任何操作即可自行清理它们。

如果您可以认真地表明 SqlParameter 对象在其应有的时间之后仍然挂起很长时间，则意味着您在某处保存了对它们的引用。例如，也许您正在某处“缓存”旧的 SqlCommand 对象，而这些对象又保留它们的所有参数。不要那样做。查找并消除仍然引用 SqlParameters 的任何内容，垃圾收集器将为您清理它们。

更新：

重新阅读您的问题后，听起来 xml 参数最终出现在大型对象堆上。 .Net 中的垃圾收集器是分代的 - 它不会在每次运行时清理所有内容。当一个对象移动到更高的一代时，它更有可能停留一段时间。大对象堆基本上是最后一代，根本没有被清理太多。更重要的是，它永远不会被压缩，以至于随着时间的推移它会破碎。这可能会导致程序保留比其需要更多的数据。您需要做的是尝试找到一种方法来避免将参数的整个 xml 数据加载到内存中，这样它就永远不会进入大对象堆。使用文件流或类似的东西代替。

Answer 2

由于 SqlParameter 不是 IDisposable，因此这不是处置它的问题；而是处理它的问题。 通常整理引用等没有什么好处，因为它仍然受到相同的GC的影响。

如果听起来像是您不小心保留了对SqlCommand的引用。但如果您确定已完成，您可以尝试将每个 .Value 显式设置为 null，并调用 Clear() 在参数列表上。但这实际上只是掩盖您坚持死命令的事实。

Answer 3

Dispose 不会处理它的参数，只处理它的内部 SqlMetaData 缓存...顺便说一句，参数不会自动处理，这是正常的，因为您可以在处理命令后传入一些不应该处理的内容... + SqlParameter 没有实现处置其中一个，因为它不包含非托管资源......

Answer 4

如果不进行测试，我可以想到两件事可能对您有帮助。通过 SqlParameters，您可以使用 finalize() 方法来释放资源。另外，您是否通过 using 块运行所有 Sql 命令？如果是这样，当 using 块完成时，您的资源应该被回收，这将消除您的内存泄漏问题。

Answer 5

我已经在几个项目中使用了这种模式，没有任何问题

public partial class StoredProcedures
{
    [SqlProcedure()]
    public static void InsertCurrency_CS(
        SqlString currencyCode, SqlString name)
    {
        using (SqlConnection conn = new SqlConnection("context connection=true"))
        {
            SqlCommand InsertCurrencyCommand = new SqlCommand();
            SqlParameter currencyCodeParam = new SqlParameter("@CurrencyCode", SqlDbType.NVarChar);
            SqlParameter nameParam = new SqlParameter("@Name", SqlDbType.NVarChar);



            InsertCurrencyCommand.CommandText =
                "INSERT Sales.Currency (CurrencyCode, Name, ModifiedDate)" +
                " VALUES(@CurrencyCode, @Name)";

            InsertCurrencyCommand.Connection = conn;

            conn.Open();
            InsertCurrencyCommand.ExecuteNonQuery();
            conn.Close();
        }
    }
}

参考：http://msdn.microsoft.com/en-us/library/5czye81z%28VS.80%29.aspx

Answer 6

如果您确信是 SqlParameter 保留了最后一个引用，则可以执行多种操作。

首先，尝试将 XML 作为字符串传递（并在存储过程中使用 OPENXML 来处理它），看看使用一个简单的对象和更多的控制是否会有帮助。

其次，创建您自己的 SqlParameter-s，将它们保存在字典中，然后执行类似的操作：

foreach (SqlParameter param in parameters.Values)
    command.Parameters.Add(param);

然后在完成命令运行并处置命令并关闭（如果仍然打开）并处置连接后，进入您的字典，显式分配null as SqlParameter.Value（或者，将 .Value 中的字符串引用放入本地变量，将 String.Empty 分配给 .Value，然后将 null 分配给本地变量 - 仅当 SqlParameter.Value 抱怨直接为 null 时才会这样做。然后分配null 到字典项（这是对 SqlParameter 的引用），然后将 null 分配给字典。

在一种更简单的情况下，您可以仅保留对那个关键 SqlParameter 的引用并跳过字典关键是保留。显式分配 null - 字符串的最后一个引用，然后是包含该字符串的 SqlParameter 的最后一个引用。

请记住，这涉及到一些事情，首先是根本不解析中间层的 XML - 只是发送。它深入到 SQL 并以显式无效引用结束。如果您的代码实际上是动态构建 XML，请将其作为一个大的直字符串来尝试。

如果仅此不能降低内存压力，那么您将不得不强制显式 GC 收集，但为此您必须进行一些阅读并计划合理的时间间隔，因为 GC 成本很高，即如果您在每个请求后启动 GC-in就像一只疯狂的兔子一样，你将在 CPU 周期上付出很多代价。

另外，由于您没有说明数据实际上有多大以及您运行的硬件类型，并且如果您的中间层在 IIS 下运行，则很难推测可能的进一步选项，例如让 IIS 运行多个工作进程并回收当它们变得太臃肿时。对于真正巨大的内存消耗和真正的直通中间层（意味着没有缓存构建），这可能比摆弄 gc 更快，但我们正在讨论真正巨大的数据才能进入该区域。