当CLR执行自动内存管理和GC时？ [英] When CLR Do Automatic Memory Management and GC?

问题描述

我想了解.net CLR是如何工作的，我列出了它的工作方式据我所知（也许有一些错误，请随时指出），并在下面提出一些问题。



1，当.Net编译器编译.net应用程序源代码时，它将选择任何语言编译器。然后创建dll或exe程序集，其中包括CIL，元数据和清单。



2，在Manifest中，它告诉我需要使用哪个外部库。所以加载了库（或其他dll）。



3，JIT将CIL转换为计算机可以运行应用程序的机器语言。 JIL还检查代码的安全性。



我的问题是：

1，CLR是否像我上面提到的那样运行？



2，我知道CLR还负责自动内存管理和垃圾收集。当CLR做那些事情的时候？

I am trying to understand how .net CLR work, I listed how it work as far as I know(Maybe there are some mistake, please feel free to point out), and have some questions below.

1, When .Net Compiler compile .net application source code, it will select whatever language compiler.Than creates dll or exe assembly, which includes CIL, Metadata and Manifest.

2, In Manifest, it tells which outside library I need to use. So the library(or other dll) loaded.

3, JIT translate CIL to machine language which the computer can run the application. JIL also check the code safety.

My questions are:
1, Is the CLR run as I mentioned above?

2, I know that the CLR also responsible for Automatic memory management and Garbage Collection. When CLR do those thing?

推荐答案

让我们看看：

Let''s see:

1. 几乎是这样，但并不完全正是在你写关于JIT操作的时候。通常，代码是基于每个方法进行JIT编译的。当一些方法即将在其组装的生命周期中第一次被调用时，它是JIT编译的。
   
   
   
   如果你可以预先编译它使用NGEN.EXE，可以获得一些性能优势，例如： http://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx [ ^ ]。
   
   
   
   这是一篇关于JIT优化的非常有趣的CodeProject文章： JIT Optimizations [ ^ ]。
2. 内存管理和垃圾几乎所有的收集工作;他们的操作独立于申请流程并且对其透明。一般规则是：您永远不能依赖任何特定的操作顺序。
   
   
   
   当您 pin 某些内存时，您可以阻止内存管理操作。这是通过使用 fixed 语句完成的。请参阅：
   
   http://msdn.microsoft.com/en-us /library/f58wzh21.aspx [ ^ ]。
   
   
   
   当你真正需要固定时，有很多种情况。通常，只有在 unsafe statement 下的代码中使用 unsafe 选项编译的程序集中直接使用指针时才能执行此操作：http://msdn.microsoft.com/en-us/library/chfa2zb8%28v= vs.110％29.aspx [ ^ ]。
   
   
   
   同样，这是一篇有趣的深入CodeProject文章：固定对象 [ ^ ]。
   
   
   
   现在，关于GC。 GC的操作由对象的可达性驱动。在应用程序中无法预测对象析构函数的实际调用和回收内存的行为（顺便说一句，这就是为什么析构函数很少在典型的.NET应用程序中编写的原因，通常这不是必需的，并且可能会产生一些问题种族条件类型），但当某个物体变得无法到达时会发生。
   
   
   
   顺便说一句，这个并不像你想象的那么简单。例如，如果对象A引用对象B，对象B引用对象C和C引用A，则此循环依赖性不会阻止GC确定如果没有其他对象引用，则应对所有对象进行垃圾回收。通过简单的实验很容易检查。
   
   
   
   您可以在这里找到可达性和垃圾收集的详细信息：http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29 [ ^ ]。

1. Pretty much so, but not quite exactly when you write about the JIT operation. Usually, the code is JIT-compiled on per-method basis. When some method is about to be called for the very first time in the lifetime of its assembly, it is JIT-compiled.
   
   It can be pre-compiled if you use NGEN.EXE, which can be done for some performance benefits, for example: http://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx[^].
   
   This is a very interesting in-depth CodeProject article on JIT optimization: JIT Optimizations[^].
2. Memory management is and garbage collection work pretty much all the time; their operation is independent from the application process and transparent to it. The general rule is: you can never rely on any particular order of operation.
   
   You can prevent memory management operations when you pin some memory. This is done by using fixed statement. Please see:
   http://msdn.microsoft.com/en-us/library/f58wzh21.aspx[^].
   
   There are a number of cases when you really need pinning. Normally, you do it only if you directly use pointers in an assembly compiled with unsafe option in the code under unsafe statement: http://msdn.microsoft.com/en-us/library/chfa2zb8%28v=vs.110%29.aspx[^].
   
   Again, this is an interesting in-depth CodeProject article on pinning: Pinned Object[^].
   
   And now, about GC. The operation of GC is driven by the reachability of objects. The actual call of the object destructors and the act of reclaiming memory cannot be predicted bu the application (by the way, this is the reason why destructores are rarely written in the typical .NET applications, usually this is not needed and can created some problems of race conditions type), but it happens when some object becomes unreachable.
   
   By the way, this is not so trivial criterion as you might think. For example, if object A references object B, object B references object C, and C reference A, this cyclic dependency does not prevent GC from figuring out that all objects should be garbage-collected if there are no other referenced to them. This is easy to check up by a simple experiment.
   
   You can find the detail of reachability and garbage collection here: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29[^].

祝你好运，

-SA

内存管理就像它一样。如果您在内存中使用大型对象（如视频），这还不够好。这对大多数应用程序来说都很好。



它与您列出的编译过程无关。这完全是另一回事。

Memory management happens when it feels like it. This is not good enough if you use large objects in memory, like videos. It''s fine for most applications.

It has nothing to do with the compilation process that you listed. It''s something else entirely.

这篇关于当CLR执行自动内存管理和GC时？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！