.Net Discovery系列之十-深入理解平台机制与性能影响(上)
转眼间《.Net Discovery》系列文章已经推出1年了，本文为该系列的第10-13篇文章，在本文中将对以前所讲的.Net平台知识做一个小小的总结与机制分析，引出并重点介绍这些机制对程序性能的影响与改进建议。
本文将分为四部分，分别讲述了：垃圾回收机制、即时编译机制、异常处理机制、字符串驻驻留机制的原理与性能改进建议。《.Net Discovery》系列的每篇文章撰写耗时都在2天以上，转载时麻烦著名作者Aicken(李鸣)，并且未经作者同意，禁止一切商业用途！
一.关于垃圾回收机制
● 机制分析
垃圾收集器是.Net平台的一个特性，它自动回收托管堆上不再使用的对象，及时清理内存,这一切都是对开发人员透明的，当然你也可以手动把它召唤出来，它的本质就是跟踪所有被引用到的对象，整理对象不再被引用的对象，回收相应的内存。垃圾收集机制采用“标记与清除(Mark Sweep)”算法来完成上述任务，整个过程分为两步：
Step 1.Mark-Sweep ：从应用程序的root出发，利用相互引用关系，遍历其在Heap上动态分配的所有对象，指明需要回收的对象，标记出那些存活的对象，予以标记。
Step 2.Compact： 对内存中存活的对象进行移动，修改它们的指针，使之在内存中连续，这样空闲的内存也就连续了，即完成了内存释放工作，也解决了内存碎片问题，这个过程也可以成为指针的压缩。
垃圾收集器一般将托管堆中的对象分为3代，这可以通过调用GC.MaxGeneration得知，对象按照存在时间长短进行分代，最短的分在第0代，最长的分在第2代，第2代中的对象往往是比较大的，第二代空间被称作Large Object Heap，对于2代对象的回收，与第0、1代回收方式相比最大的不同在于，没有了指针移动的压缩过程。
如下图，第一次GC时，左边第一列A-F表示内存中的对象，位于浅蓝色 区域，经过Mark后，ACDF标记为可用，Sweep过程清除了BE，Compact过程移动了ACDF，使之位于连续存储区域中；第二次使用绿色做标记；第三次GC使用蓝色表示标记；可以看出第三次GC过程没有了指针移动的压缩过程。
●性能影响分析
这个过程看起来有点复杂，的确垃圾收集器的启动是会占用一些CPU时间，从而影响系统的性能，但这种影响很有限，并且这些损失是有所值的。
1.垃圾收集器并不是没有规律的启动，而是当代龄达到一定触发条件时启动，而且垃圾收集器只是移动代龄较低的1、2代的资源，并不会移动LOH中的对象。这就在一定程度上避免了GC长时间锁定线程导致的性能损失。
2.GC有三种不同的工作模式，适用于不同环境的情况，并不是所有环境都是“使用挂起->查找与标记->压缩->恢复” 的流程。“Workstation GC with Concurrent”模式可以第0、1代的收集仍然是要暂时挂起应用程序，在收集第2代时，会并行处理，具体原理是将Full GC过程切分成多个短暂子过程对线程进行冻结，在线程冻结时间之外，应用程序仍然可以正常运行。这主要通过将0代空间设置的很大，使Full GC时，CLR仍然能够在0代中进行内存分配，如果Full GC时0代内存也已用尽，那么应用程序将被挂起，等待Full GC的完成。
在多CPU的情况下，可以使用和“Server GC”模式。这种GC模式有着很高的性能和效率。这种模式下，CLR为每个CPU创建一个专用的GC线程，每个CPU可以独立的为相应的heap执行GC操作，这些GC线程是以非并发的形式工作的，收集工作与线程正常工作不能同时进行，这就是说第0、1、2代的收集都会挂起应用线程。
在.Net 4.0中，有一种新的垃圾收集机制，叫做后台收集。这种机制以concurrent GC为基础的，如上文所讲，Workstation GC with Concurrent模式中，在Full GC过程时，CLR仍然能够在0代中进行内存分配，如果Full GC时0代内存也已用尽，那么应用程序将被挂起，等待Full GC的完成。
3.垃圾收集器是配合策略引擎工作的。策略引擎可以唤醒GC，它会根据GC启动的次数、频率、代龄情况等自发的启动GC，使GC工作。特别要注意的是，由程序人员手动的调用GC收集的代码，同样会影响策略引擎的工作，这样会给策略引擎错误的信号，从而导致GC的错误启动，所以在没有必要的情况下，一般不建议使用GC.Collect();手动回收。
● 综述
比起垃圾收集器带来的微乎的性能损失，我们应该把精力放在程序的优化上，非托管资源的及时释放、字符串拼接、循环内的业务代码都是需要注意的地方。垃圾收集机制不是.Net也不是Java的专利，它已经有一段进化的历史，越来越多的案例也证明垃圾收集机制的优点，Exchange 2010的大部分模块就是基于托管环境的。
二.关于实时编译机制
JIT（Just In Time简称JIT）是.Net边运行边编译的一种机制，这种机制的命名来源于丰田汽车在20世纪60年代实行的一种生产方式，中文译为“准时制”。
.Net 的JIT编译器在设计初衷和运行方式来上讲，都与丰田汽车的这种“准时生产”思想体系有着很大的相似之处，所以让我们先来透过“准时生产”方式来理解.Net的JIT机制吧。
“准时生产”的基本思想可概括为“在需要的时候，按需要的量生产所需的产品”，这正是.Net JIT编译器的设计初衷，即在需要的时候编译需要的代码。
未完
下一篇中，Aicken将会结合Windbg为大家介绍.Net JIT机制以及其带来的性能问题，敬请期待。
我是Aicken(李鸣) 请您继续关注我的下一篇文章。
PS:怎么发随笔时，原来的编辑器不见了？取而代之的是只有HTML的编辑界面，而且用Windows live日志发布在哪里选择博客园的“首页发布选项”？这年头进步的让人莫名其妙！
“.Net Discovery 系列”是讲解.Net平台本质的文章，现在已经有：
.Net Discovery 系列之七--深入理解.Net垃圾收集机制(拾贝篇) 发布在新年第一秒
.Net Discovery 系列之五--Me JIT(深入浅出.Net JIT 上)
.Net Discovery 系列之六--Me JIT(深入浅出.Net JIT 下)
.Net Discovery 系列之三--深入理解.Net垃圾收集机制(上)
.Net Discovery 系列之四--深入理解.Net垃圾收集机制(下)
李鸣(aicken)原创 转载注明
