为什么 IHttpAsyncHandler 在负载下会泄漏内存？

Question

我注意到 .NET IHttpAsyncHandler（以及较小程度的 IHttpHandler）在遭受并发 Web 请求时会泄漏内存。

在我的测试中，Visual Studio Web 服务器（Cassini）从 6MB 内存跃升至超过 100MB，并且一旦测试完成，就不会回收任何内存。

该问题可以很容易地重现。创建一个包含两个项目的新解决方案 (LeakyHandler)：

1. 一个 ASP.NET Web 应用程序 (LeakyHandler.WebApp)
2. 一个控制台应用程序 (LeakyHandler.ConsoleApp)

在 LeakyHandler.WebApp 中：

1. 创建一个名为 TestHandler 的类，该类实现 IHttpAsyncHandler。
2. 在请求处理中，做短暂的Sleep并结束响应。
3. 将 HTTP 处理程序添加到 Web.config 作为 test.ashx。

在LeakyHandler.ConsoleApp中：

1. 生成大量的HttpWebRequest到test.ashx并异步执行。

随着HttpWebRequests（sampleSize）数量的增加，内存泄漏变得越来越明显。

LeakyHandler.WebApp > TestHandler.cs

namespace LeakyHandler.WebApp
{
    public class TestHandler : IHttpAsyncHandler
    {
        #region IHttpAsyncHandler Members

        private ProcessRequestDelegate Delegate { get; set; }
        public delegate void ProcessRequestDelegate(HttpContext context);

        public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
        {
            Delegate = ProcessRequest;
            return Delegate.BeginInvoke(context, cb, extraData);
        }

        public void EndProcessRequest(IAsyncResult result)
        {
            Delegate.EndInvoke(result);
        }

        #endregion

        #region IHttpHandler Members

        public bool IsReusable
        {
            get { return true; }
        }

        public void ProcessRequest(HttpContext context)
        {
            Thread.Sleep(10);
            context.Response.End();
        }

        #endregion
    }
}

LeakyHandler.WebApp > Web.config

<?xml version="1.0"?>

<configuration>
    <system.web>
        <compilation debug="false" />
        <httpHandlers>
            <add verb="POST" path="test.ashx" type="LeakyHandler.WebApp.TestHandler" />
        </httpHandlers>
    </system.web>
</configuration>

LeakyHandler.ConsoleApp > Program.cs

namespace LeakyHandler.ConsoleApp
{
    class Program
    {
        private static int sampleSize = 10000;
        private static int startedCount = 0;
        private static int completedCount = 0;

        static void Main(string[] args)
        {
            Console.WriteLine("Press any key to start.");
            Console.ReadKey();

            string url = "http://localhost:3000/test.ashx";
            for (int i = 0; i < sampleSize; i++)
            {
                HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);
                request.Method = "POST";
                request.BeginGetResponse(GetResponseCallback, request);

                Console.WriteLine("S: " + Interlocked.Increment(ref startedCount));
            }

            Console.ReadKey();
        }

        static void GetResponseCallback(IAsyncResult result)
        {
            HttpWebRequest request = (HttpWebRequest)result.AsyncState;
            HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(result);
            try
            {
                using (Stream stream = response.GetResponseStream())
                {
                    using (StreamReader streamReader = new StreamReader(stream))
                    {
                        streamReader.ReadToEnd();
                        System.Console.WriteLine("C: " + Interlocked.Increment(ref completedCount));
                    }
                }
                response.Close();
            }
            catch (Exception ex)
            {
                System.Console.WriteLine("Error processing response: " + ex.Message);
            }
        }
    }
}

调试更新

我使用 WinDbg 来查看转储文件，一些可疑类型被保存在内存中并且从未释放。每次我运行样本大小为 10,000 个的测试时，内存中都会多保存 10,000 个此类对象。

• System.Runtime.Remoting.ServerIdentity
• System.Runtime.Remoting.ObjRef
• Microsoft.VisualStudio.WebHost.Connection
• System.Runtime.Remoting .Messaging.StackBuilderSink
• System.Runtime.Remoting.ChannelInfo
• System.Runtime.Remoting.Messaging.ServerObjectTerminatorSink

这些对象位于第 2 代堆中，不会被收集，即使在强制完全垃圾回收之后。

重要说明

即使强制顺序请求，甚至在 ProcessRequest 中没有 Thread.Sleep(10)，问题也存在，只是更加微妙。该示例使问题变得更加明显，从而加剧了问题，但基本原理是相同的。

Answer 1

我查看了您的代码（并运行了它），我不相信您看到的内存增加实际上是内存泄漏。

您遇到的问题是您的调用代码（控制台应用程序）本质上是在紧密循环中运行。

但是，您的处理程序必须处理每个请求，并且还受到 Thread.Sleep(10) 的“束缚”。这样做的实际结果是，您的处理程序无法跟上传入的请求，因此它的“工作集”随着更多请求排队等待处理而不断增长。

我获取了您的代码并将 AutoResetEvent 添加到控制台应用程序，

在 request.BeginGetResponse(GetResponseCallback, request);

和

.Set 之后执行 .WaitOne() () after streamReader.ReadToEnd();

这具有同步调用的效果，因此在第一个调用回调（并完成）之前无法进行下一个调用。您所看到的行为就会消失。

综上所述，我认为这纯粹是一种失控情况，实际上根本不是内存泄漏。

注意：我在 GetResponseCallback 方法中使用以下内容监视内存：

 GC.Collect();
 GC.WaitForPendingFinalizers();
 Console.WriteLine(GC.GetTotalMemory(true));

[编辑以响应 Anton 的评论]
我并不是说这里完全没有问题。
如果您的使用场景是处理程序的这种锤击是真实的使用场景，那么显然您遇到了问题。我的观点是，这不是内存泄漏问题，而是容量问题。解决这个问题的方法可能是编写一个运行速度更快的处理程序，或者扩展到多个服务器等。

泄漏是指资源在使用完毕后仍被保留，从而增加了工作集。这些资源尚未“完成”，它们处于队列中并等待服务。一旦它们完成，我相信它们就会被正确释放。

[编辑以回应安东的进一步评论]
好吧——我发现了一些东西！我认为这是 Cassini 问题，在 IIS 下不会发生。您是否在 Cassini（Visual Studio 开发 Web 服务器）下运行处理程序？

当我仅在 Cassini 下运行时，我也看到了这些泄漏的 System.Runtime.Remoting 命名空间实例。如果我将处理程序设置为在 IIS 下运行，我就看不到它们。您能否确认您是否属于这种情况？

这让我想起了我见过的其他一些远程/卡西尼问题。 IIRC 具有类似 IPrincipal 的实例，需要存在于模块的 BeginRequest 中，并且在模块生命周期结束时也需要从 Cassini 中的 MarshalByRefObject 派生，而不是 IIS。由于某种原因，Cassini 似乎在内部进行了一些远程处理，而 IIS 则没有。

Answer 2

您正在测量的内存可能已被 CLR 分配但未使用。要检查，请尝试调用：

GC.Collect();
context.Response.Write(GC.GetTotalMemory(true));

在 ProcessRequest() 中。让您的控制台应用程序报告来自服务器的响应，以查看活动对象实际使用了多少内存。如果这个数字保持相当稳定，那么 CLR 只是忽略执行 GC，因为它认为它有足够的可用 RAM。如果该数字稳步增加，那么您确实存在内存泄漏，您可以使用 WinDbg 和 SOS.dll 或其他（商业）工具来解决该问题。

编辑：好的，看起来你确实有内存泄漏。下一步是弄清楚是什么支撑着这些物体。您可以使用 SOS !gcroot 命令来实现此目的。 .NET 2.0 有一个很好的解释 此处，但如果您可以在 .NET 4.0 上重现此内容，那么它的 SOS.dll 有更好的工具为您提供帮助 - 请参阅http://blogs.msdn.com/tess/archive/2010/03/01/new-commands-in-sos-for-net-4-0-part-1.aspx

Answer 3

你的代码没有问题，也没有内存泄漏。尝试连续运行控制台应用程序几次（或增加样本大小，但请注意，如果您有太多并发请求处于睡眠状态，最终您的 http 请求将被拒绝）。

通过您的代码，我发现当 Web 服务器内存使用量达到大约 130MB 时，垃圾收集就会产生足够的压力，并将其减少到大约 60MB。

也许这不是您期望的行为，但是运行时已经决定快速响应快速传入的请求比花时间处理 GC 更重要。

Answer 4

这很可能是您的代码中的问题。

我要检查的第一件事是您是否分离了代码中的所有事件处理程序。每个 += 都应该由事件处理程序的 -= 镜像。这就是大多数 .Net 应用程序造成内存泄漏的方式。