blocks|key|966134|text|内存使用率高的原因可能有很多，但.NET中的垃圾回收是一个非常精确的东西。也就是说，它为您做了很多事情，但有时并不像您预期的那样多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|966135|具体地说，它只能清理没有活动引用的对象，所以如果您已经处理完一个类，但仍然有一个对它的引用，那么您将需要删除该引用，以便GC可以为您恢复该内存。此外，如果您有任何非活动的打开连接(例如，到数据库或其他东西)，不要忘记关闭并清除它们。通常，我们将这样的对象包装在using块中，如下所示：|offset|length|style|CODE|966136|using(SqlConnection+conn+=+new+SqlConnection(myConnString))
{+...rest+of+code+here+}|code-block|syntax|javascript|966137|这将自动关闭并释放连接。这是作为try...finally块实现的，因此即使在using块中抛出异常，连接也会关闭。|966138|除此之外，答案是"profile，profile，profile“，直到你找到你的漏洞/瓶颈/任何东西。|966139|entityMap^0|0|3M|5|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|W|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

There could be lots of reasons for your high memory usage, but Garbage Collection in .NET is a very precise thing. That is, it does a lot for you, but sometimes not as much as you'd expect.

Specifically, it can only clean up objects to which there are no active references, so if you're done with a class, but something still has a reference to it, you'll want to remove that reference so the GC can recover that memory for you. Additionally, if you have any inactive open connections (say, to a DB or something) don't forget to close and dispose them. Typically, we wrap such objects in <code>using</code> blocks like this:

<pre><code>using(SqlConnection conn = new SqlConnection(myConnString))
{ ...rest of code here }
</code></pre>

This will automatically close and dispose of the connection. This is implemented as a try...finally block, so the connection will be closed even if an exception is thrown in the using block.

Other than that, the answer is "profile, profile, profile" until you find your leak/bottleneck/whatever.

blocks|key|966177|text|虽然你确实不必显式地释放内存，垃圾回收器将为你做这件事，但代码可能会无意中持有对对象的引用，以防止它被收集-这本质上是内存泄漏。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|966178|在ASP.NET中，对象在被应用程序和会话缓存引用时保持“活动”状态。在对应用程序一无所知的情况下，我建议您使用内存分析器，更仔细地查看内存中到底有什么，以及应用程序或会话缓存是否持有一些不应该保留的内容。|966179|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Whilst it is true that you don't have to explicitly free memory and the garbage collector will do this for you it is possible for code in inadvertently hold a reference to an object to prevent it being collected - this is essentially a memory leak.

In ASP.NET objects remain "alive" whilst they are referenced by the Application and Session cache. Without knowing anything about your application I would suggest you get hold of a memory profiler and look more closely at exactly what is in memory and whether the Application or Session cache is holding onto something it shouldn't.

blocks|key|1180488|text|.NET中的内存泄漏仍然是可能的。的确，在大多数情况下，您不需要释放对象(有一些例外，如Graphics对象)，但如果您保留对它们的引用，它们将不会被垃圾回收，因为它们仍然被引用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1180489|如果GC发现应用程序中的某处、任何位置引用了某个对象，它不会将其丢弃。|1180490|查看这篇关于.NET内存泄漏以及如何定位和修复它们的Code+Project文章。|offset|length|1180491|entityMap|0|LINK|mutability|MUTABLE|url|http://www.codeproject.com/KB/dotnet/Memory_Leak_Detection.aspx^0|0|0|Q|C|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Memory leaks in .NET are still possible. It is true that for the most part you don't need to free objects (there are a few exceptions such as the Graphics object) but if you keep references to them, they will not get garbage collected, because they are still referenced.

If the GC sees that an object is being referenced somewhere, anywhere in your app, it will not trash it. 

Check out this <a href="http://www.codeproject.com/KB/dotnet/Memory_Leak_Detection.aspx" rel="nofollow noreferrer">Code Project</a> article on .NET memory leaks and how to go about locating and fixing them.

blocks|key|966246|text|有几件事你应该看一看：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|966247|首先，你在使用会话吗？它们是在proc会话中还是在SQL会话中？如果它们正在处理中，那么超时设置为多少？如果你有一个非常长的超时，这可以解释为什么你使用这么多的内存(用户会话将存储很长时间)。|966248|第二，对象的处理。.NET垃圾回收器将为您清除引用，但是当您创建实现IDisposable接口的对象时，应该始终使用using关键字。|offset|length|style|CODE|966249|using(Foo+foo+=+new+Foo())
{
++++...
}|code-block|syntax|javascript|966250|等同于做：|966251|Foo+foo;
try
{
++++foo+=+new+Foo();
++++...
}
finally
{
++++foo.Dispose();
}|966252|它将确保你有效地处理你的对象。|966253|如果您仍然无法在代码中找到任何明显的东西，您可以分析它，从调用次数最多的方法开始。你可以找到关于好的分析器here的信息。这肯定会让你找到问题的根源。|966254|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/system.idisposable.aspx|1|https://stackoverflow.com/questions/3927/what-are-some-good-net-profilers^0|0|0|Y|B|Y|B|0|0|0|0|0|0|1H|4|1|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|18|8|@$F|19|G|1A|H|I]]|9|@$F|1B|G|1C|1|1D]]|A|$]]|$1|J|3|K|5|L|7|1E|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1F|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|1G|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|1H|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1I|8|@]|9|@$F|1J|G|1K|1|1L]]|A|$]]|$1|W|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]|14|$5|Z|10|11|A|$12|15]]]]

There are a few things you should look at : 

First of all, are you using sessions? Are they in proc or SQL sessions? If they are in process, what's the timeout set at? If you have a really really long timeout, this could explain why you are using so much memory (the user sessions would be stored for a long time).

Second, disposing of objects. The .NET garbage collector will get rid of references for you, but when you are creating objects that implement the <a href="http://msdn.microsoft.com/en-us/library/system.idisposable.aspx" rel="nofollow noreferrer"><code>IDisposable</code></a> interface, you should always use the using keyword.

<pre><code>using(Foo foo = new Foo())
{
 ...
}
</code></pre>

is the equivalent of doing :

<pre><code>Foo foo;
try
{
 foo = new Foo();
 ...
}
finally
{
 foo.Dispose();
}
</code></pre>

And it will ensure that you dispose of your objects efficiently.

If you still can't find anything obvious in your code, you can profile it, starting with the methods that are called the most. You can find information about good profilers <a href="https://stackoverflow.com/questions/3927/what-are-some-good-net-profilers">here</a>. That will definitely lead you to the source of your problem.

blocks|key|1180586|text|如果您的ASP.NET应用程序使用事件(以及哪一个不使用)，则使用then+you+have+to+make+sure+you+unsubscribe+from+the+event。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1180587|经验法则：|1180588|如果您使用%2B=订阅事件，则需要在Dispose()方法中使用-=来取消订阅。|style|CODE|1180589|在这个主题上有lots+of+resources，我在我工作过的应用程序中遇到了一些麻烦，因为您的普通程序员没有意识到事件可能会导致内存泄漏。|1180590|5：https://www.google.com/?gws_rd=ssl#hl=en&source=hp&q=.NET事件内存leak&aq=f&aqi=g1&aql=&oq=&gs_rfai=CnCywlWZZTMSQDYL-jQOA1ozyCAAAAKoEBU_Q8wsE&fp=ea2cd8eab02d18af|1180591|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/448197/unregistered-event-handlers-cause-memory-leak|1|https://web.archive.org/web/20151029113350/http://blogs.msdn.com:80/b/tess/archive/2006/01/23/net-memory-leak-case-study-the-event-handlers-that-made-the-memory-baloon.aspx|2|https://weblogs.asp.net/fmarguerie/events-references-garbage-collecting-memory-leaks-and-weak-delegates|3|https://web.archive.org/web/20160408074457/http://www.dev102.com:80/2008/03/16/a-net-memory-leak-you-did-not-think-about/|4|https://www.google.com/?gws_rd=ssl#hl=en&source=hp&q=.NET^0|X|1L|0|0|0|5|2|G|9|U|2|0|7|4|1|C|2|2|F|9|3|0|2|1L|4|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]|$1|D|3|E|5|6|7|17|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|18|8|@$A|19|B|1A|H|I]|$A|1B|B|1C|H|I]|$A|1D|B|1E|H|I]]|9|@]|C|$]]|$1|J|3|K|5|6|7|1F|8|@]|9|@$A|1G|B|1H|1|1I]|$A|1J|B|1K|1|1L]|$A|1M|B|1N|1|1O]]|C|$]]|$1|L|3|M|5|6|7|1P|8|@]|9|@$A|1Q|B|1R|1|1S]]|C|$]]|$1|N|3|-4|5|6|7|1T|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]|V|$5|Q|R|S|C|$T|W]]|X|$5|Q|R|S|C|$T|Y]]|Z|$5|Q|R|S|C|$T|10]]|11|$5|Q|R|S|C|$T|12]]]]

If your ASP.NET application uses events (and which one doesn't), <a href="https://stackoverflow.com/questions/448197/unregistered-event-handlers-cause-memory-leak">then you have to make sure you unsubscribe from the event</a>.
Rule of thumb:
If you use <code>+=</code> to subscribe to an event, then you need to use <code>-=</code> in the <code>Dispose()</code> method to unsubscribe.
There are <a href="https://web.archive.org/web/20151029113350/http://blogs.msdn.com:80/b/tess/archive/2006/01/23/net-memory-leak-case-study-the-event-handlers-that-made-the-memory-baloon.aspx" rel="nofollow noreferrer">lots</a> <a href="https://weblogs.asp.net/fmarguerie/events-references-garbage-collecting-memory-leaks-and-weak-delegates" rel="nofollow noreferrer">of</a> <a href="https://web.archive.org/web/20160408074457/http://www.dev102.com:80/2008/03/16/a-net-memory-leak-you-did-not-think-about/" rel="nofollow noreferrer">resources</a> [on this topic][5], and I've had a bit of pain in applications I've worked in because your run-of-the-mill programmer doesn't realize that events can cause memory leaks.
[5]: <a href="https://www.google.com/?gws_rd=ssl#hl=en&amp;source=hp&amp;q=.NET" rel="nofollow noreferrer">https://www.google.com/?gws_rd=ssl#hl=en&amp;source=hp&amp;q=.NET</a> events memory leak&amp;aq=f&amp;aqi=g1&amp;aql=&amp;oq=&amp;gs_rfai=CnCywlWZZTMSQDYL-jQOA1ozyCAAAAKoEBU_Q8wsE&amp;fp=ea2cd8eab02d18af

blocks|key|966338|text|当您的内存超过500MB时，使用memory+profiler+(在内存转储上或在您的实时环境中)，以获得哪些对象占用了所有空间的线索。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|966339|在您的开发环境中进行分析时，您可能会看到一个特定的对象类型只有在您的站点上浏览时才会增长，而其他对象类型在全局范围内保持不变。|966340|entityMap|0|LINK|mutability|MUTABLE|url|http://memprofiler.com/^0|G|F|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Use a <a href="http://memprofiler.com/" rel="nofollow noreferrer">memory profiler</a> (either on a memory dump, or on your live environment) when your memory exceeds that 500 MB to get a clue which objects take up all that space.

When profiling on your development environment you might see one particular objecttype only grow when surfing around on your site whilst others remain globally the same.

I have an ASP.NET website that will hit about 2gb physical memory used within about 3-4 days, which to me sounds really bad. At the moment, I have configured IIS to restart the app pool process when it hits 500mb. I would like to try and track down the problem. 

When creating a new instance of an object in .NET, I was under the impression that it doesn't need to be freed as the .NET garbage collector will do this for me.

Is that the case or could this be one of the reasons I am having issues?

ASP.NET Website Memory Usage quite high

数据库

我有一个ASP.NET网站，它将在大约3-4天内占用大约2 2gb的物理内存，对我来说这听起来真的很糟糕。目前，我已经将IIS配置为在达到500mb时重新启动应用程序池进程。我想试着追查这个问题。在.NET中创建对象的新实例时，我的印象是不需要释放它，因为.NET垃圾收集器将为我做这件事。这是真的吗，或者这可能是我遇到...

问ASP.NET网站内存使用率很高
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.NET网站内存使用率很高EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.NET网站内存使用率很高
EN