SSL 和客户端证书与 HttpWebRequest 对象一起使用时的内存泄漏
我正在使用 HttpWebRequest 对象使用 SSL 和客户端证书上传文件，我的服务器上有有效的证书，我的应用程序存在内存泄漏问题，并且 Microsoft 已发布了一些内容与以下链接中的问题相关：
修复：SSL 和客户端证书与 HttpWebRequest 对象一起使用时内存泄漏< /a>
有工作吗为了避免这种内存泄漏，特别是每个请求都消耗 8K 泄漏内存，这将导致我的应用程序消耗如此多的内存。
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(uri);
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);
request.Method = "POST";
request.ContentType = "text/xml; charset=utf-8";
使用 .NET Memory Profiler 检测到内存泄漏，它显示 HttpWebRequest 对象具有字节数组这会泄漏内存，我正在销毁流和请求对象。
我已经尝试过使用 SSL 和 不使用 SSL 的情况，泄漏在非 SSL 请求中消失了。
I am using HttpWebRequest object to upload files using SSL with client certificate, I have a valid certificate on my server, My application is having a memory leak issue and Microsoft has posted something related to the issue on the following link:
FIX: Memory Leak When SSL and Client Certificates Are Used With the HttpWebRequest Object
Is there any work around to avoid this memory leak specially that each request is consuming 8K leaked memory, this will cause my application to consume so much memory.
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(uri);
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);
request.Method = "POST";
request.ContentType = "text/xml; charset=utf-8";
memory leaks were detected using .NET Memory Profiler and it shows the HttpWebRequest object has array of bytes that leaks the memory, I am deposing both stream and request objects.
I have tried this case with SSL and without SSL the leaks have disappeared in non SSL Requests.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只需将
HttpWebRequest对象的AllowWriteStreamBuffering属性设置为 false：注意：框架会在创建 SSL 会话时对其进行缓存，并尝试在以下情况下为新请求重用缓存的会话：可能的。当尝试重用 SSL 会话时，框架使用 ClientCertificates 的第一个元素（如果有），或者如果 ClientCertificates 为空，则尝试重用匿名会话。
其他注意事项：出于性能原因，您不应将客户端证书添加到 HttpWebRequest 中，除非您知道服务器会要求它。
有关说明如何枚举客户端证书存储中的证书的代码示例，请参阅 X509Certificate2Collection 类。
或者尝试使用这个：
simply set the
AllowWriteStreamBufferingproperty of yourHttpWebRequestobject to false:Note : The Framework caches SSL sessions as they are created and attempts to reuse a cached session for a new request, if possible. When attempting to reuse an SSL session, the Framework uses the first element of ClientCertificates (if there is one), or tries to reuse an anonymous sessions if ClientCertificates is empty.
Other Note : For performance reasons, you shouldn't add a client certificate to a HttpWebRequest unless you know the server will ask for it.
For a code example illustrating how to enumerate the certificates in the client certificate store, see the X509Certificate2Collection class.
Or try to use this :
您可以使用 WinDbg（一个调试器，它是 Windows SDK 的一部分）来更好地探索如何管理内存。虽然不像第三方选项那么友好，但它可以让您降低并弄清楚您所看到的是否确实是泄漏。没有真正简单的方法可以告诉你的问题出在哪里，你创建了 ValidateRemoteCertificate 的新实例，我认为这是你的代码，并且它本身可能无法释放它使用的所有内容，这反过来又会导致 GC 不清理请求。
要开始使用，您可以阅读
如果之后您确实认为这是一个 .NET 框架错误，而不是您自己的代码中的错误，那么请报告它。有几种方法可以通过 Connect 来执行此操作，或者如果这对您影响很大，您可以放置一个 与 Microsoft 的支持事件。如果您选择支持事件路线，您将需要一张信用卡。如果您的问题是由于 .NET 框架中的错误造成的，您将无需付费。
You can use WinDbg, a debugger which is part of the Windows SDK to better explore how memory is being managed for you. Whilst not as friendly as the 3rd party options out there it allows you to go lower and figure out if what you are seeing is indeed a leak. There's no real easy way to tell where your problem lies, you create new instances of ValidateRemoteCertificate, which I presume is your code, and could itself not be freeing all it uses, which in turn can cause the GC not to clean up the request.
To get started you can read
If, after that, you truly believe this is a .NET framework bug, and not in your own code then report it. There are a couple of ways to do this, via Connect, or if this is impacting you heavily you can place a support incident with Microsoft. If you go the support incident route you will need a credit card. If your problem is due to a bug in the .NET framework you will not be charged.