如果是内存，由.NET进程分配，释放回Windows

问题描述

的设置

.NET分配内存每一代的堆（0，1，2，LOH）中的段来获得连续的存储器块，在启动时，以及当它试图满足分配请求，收集后。

分配给每个堆将可能平整的应用程序预热，但潜在的第二代，和大对象堆此内存。在一个垃圾收集，每堆（0，1，2）被扫过并压实，除了大对象堆（LOH），这是刚刚扫过。

我明白一个集合的扫描部分意味着GC识别哪些对象不再根深蒂固，并且可用于收集（或完成），以及紧凑型是指那些仍然活着的堆地址被重新安排，现有的剩余堆有更多的连续内存提供给它。

由于预算堆内各段超标，.NET会为了它是否能履行拨款分配另一个片段。

问题

我的问题归结到会发生什么是内存中的每个堆，即不使用应用程序（提交）不再，但仍保留由.NET？ 什么时候释放回操作系统？。

我相信这是一个进程可能会出现被占用大量内存的情况下（虚拟大小是相当大的，但专用字节小），但是检查时，其堆是大多是免费空间。另一个需要注意的堆在总规模还可能相当小，然后不占内存消耗的过程。

没有阻挡终结和一切看起来健康的一个过程 - 它可能已经运行了数周之前就引发了监视警报（例如）

。

试图进一步澄清的问题，如果你读苔丝<一href="http://blogs.msdn.com/b/tess/archive/2006/09/06/net-memory-usage-a-restaurant-analogy.aspx?PageIndex=1">.NET内存管理 - 一个餐厅比喻，如果​​表是堆段，并在餐厅会失去表（例如免费堆段）？

修改

1. 删除混乱参考工作集和鸡
2. 添加引用苔丝餐厅比喻

解决方案

我的答案是 - 这并不重要。操作系统给应用程序（.NET运行库运行在其中）的虚拟内存的。这不是真正的记忆。操作系统可以把虚拟内存的每一页无论它喜欢 - 在处理器上，在主内存中，在磁盘上。因此，它有可能为一个应用程序来使用更多的内存比RAM的系统的数量，操作系统将复制都需要/从磁盘到确保应用程序中的位保持运行（模一定的寻址和放大器;技术限制）

操作系统管理系统中的所有进程的虚拟内存，并确保一个程序不养猪的系统上的所有内存到其他程序的损害。当.NET运行时请求内存从系统在堆使用，但不使用它，这种记忆会（如果系统是低可用RAM）被移动到磁盘上，因为它没有被访问

通过从苔丝电子邮件澄清的：的（重点煤矿）

该段大小停留在整个应用程序的过程相同，但有两件事情要考虑这里。

1. 的拨款段是虚拟分配，这意味着尽管我们保留的虚拟内存的，我们只的提交的我们实际使用，因此专用字节的用于段是不一样的段大小，这意味着一个GC后，您的私人字节会下降，而虚拟字节将保持不变。

2. 当段将不再使用，也就是说，如果你碰巧GC一切都在一个段，使其不再包含任何.NET对象，则返回虚拟分配回操作系统。

而这样的信仰，然后堆段（餐桌）将被返回到操作系统。

The Setup

.NET allocates memory for each generation’s heap (0, 1, 2, LOH) in segments to get a continuous block of memory, on startup, and when it attempts to satisfy an allocation request, after a collection.

This memory allocated for each heap will likely level off as the application "warms up", except potentially for generation 2, and large object heap. During a garbage collection, each heap (0, 1, 2) is swept and compacted, except for the large object heap (LOH), which is just swept.

I understand the ‘sweep’ part of a collection to mean that the GC identifies which objects are no longer rooted and are available for collection (or finalization) and that ‘compact’ means that the addresses that are still alive in a heap are reorganized so that the available remaining heap has more continuous memory available to it.

As the budget for each segment within the heap is exceeded, .NET will allocate another segment in order to fulfill allocations if it can.

The Question

My question comes down to what happens to that memory in each heap, that is not be used by the application (committed) any longer, but is still reserved by .NET? When is it released back to the OS?.

I believe this to be the scenario where a process might appear to be consuming a lot of memory (virtual size is quite large, but private bytes small), but when inspecting its heaps are mostly free space. As another caveat, the total size of the heaps may also be quite small, and not account for the memory being consumed by the process.

There is no blocked finalizer and all looks healthy for a process - it may have been running for weeks before it triggered a monitor alert (e.g.).

Trying for further clarification of the question, if you read Tess .NET Memory Management - A Restaurant Analogy, if the tables are heap segments, does the restaurant ever lose tables (e.g. free heap segments)?

Edit

1. Removed confusing reference to working set and chickens
2. Added reference to Tess restaurant analogy

解决方案

My answer is - it doesn't matter. The OS gives the application (within which the .NET runtime runs) virtual memory. This is not 'real' memory. The OS can put each page of virtual memory wherever it likes - on the processor, in main memory, on the disk. So, it is possible for an app to use more memory than the amount of RAM on the system, and the OS will copy the bits that are needed to/from disk to ensures the app keeps running (modulo certain addressing & technical limitations).

The OS manages the virtual memory of all the processes on the system, and ensures that one program doesn't hog all the RAM on the system to the detriment of other programs. When the .NET runtime asks for memory from the system for use in the heaps, but then doesn't use it, this memory will (if the system is low on free RAM) be moved to disk, because it isn't being accessed.

Clarification via email from Tess: (emphasis mine)

The segment sizes stay the same throughout the course of the application, but there are two things to consider here.

1. The allocations for a segment is a virtual allocation, meaning that while we reserve virtual memory, we only commit what we actually use, so the private bytes used for a segment is not the same as the segment size, this means that after a GC, your private bytes will go down, while your virtual bytes will stay the same.

2. When a segment is no longer used, i.e. if you happen to GC everything in a segment so that it no longer contains any .net objects, the virtual alloc is returned back to the OS.

Taking that on faith, then heap segments (restaurant tables) will be returned back to the OS.

这篇关于如果是内存，由.NET进程分配，释放回Windows的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！