.net托管与非托管

官方解释

.NET Framework的核心是其运行库的执行环境，称为公共语言运行库(CLR)或.NET运行库。通常将在CLR的控制下运行的代码称为托管代码(managed code)。

运行库环境（而不是直接由操作系统）执行的代码。托管代码应用程序可以获得公共语言运行库服务，例如自动垃圾回收、运行库类型检查和安全支持等。这些服务帮助提供独立于平台和语言的、统一的托管代码应用程序行为。

托管代码是可以使用20多种支持Microsoft .NET Framework的高级语言编写的代码，它们包括：C#, J#, Microsoft Visual Basic .NET, Microsoft JScript .NET, 以及C++。所有的语言共享统一的类库集合，并能被编码成为中间语言(IL)。运行库编译器（runtime-aware ompiler）在托管执行环境下编译中间语言（IL）使之成为本地可执行的代码，并使用数组边界和索引检查，异常处理，垃圾回收等手段确保类型的安全。

大白话解释

CLR能识别解析且编译的就是托管代码,其他的就是非托管代码

托管资源与非托管资源的区别

1. 编译运行过程不同
2. 跨平台能力不同
3. 程序性能不同

本节中，我们会涉及到托管和非托管的另一个区别：

1. 释放资源的方式不同

在C/C++中，资源都是需要手动释放的，比如，你new了一个指针，用过之后就需要delete掉，否则就会造成内存泄露。
而在Java中，不必考虑资源释放的问题，Java的垃圾回收机制（GC，Garbage Collection）会保证失效的资源被自动释放。
而C#的机制与Java类似，运行于.net平台上的代码，分配的资源一般会自动由平台的垃圾回收器释放，这样的资源就是托管资源。
但是一些例外的资源，如System.IO.StreamReader等各种流、各种连接所分配的资源，需要显式调用Close()或Dispose()释放，这种资源就叫做非托管资源。

托管与非托管的混合编程

在C#的三大难点之前传：什么时候应该使用C#？中我提到过，C#的一大优势在于Windows平台下的界面编程。但由于C#并不是很普及，经常出现底层或后台代码采用C/C++编写的情况，此时，若选择C#作为界面语言，则必然遇到一个C#调用C++代码的问题。
比较普遍的解决方案就是，先将C/C++的代码生成为DLL动态运行库，再在C#中调用。
举个例子
在C中：

#include 
#include 

void DisplayHelloFromDLL()
{
    printf ("Hello from DLL !\n");
}

void CallHelloFromDLL(char* cp)
{
    printf (cp);
    printf ("\n");
    *cp='a';
    cp++;
    printf (cp);
    printf ("\n");
}

在C#中：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TestConsole
{
    using System;
    using System.Runtime.InteropServices;     // DLL support

    class Program
    {
        [DllImport(@"TestLib.dll")]
        public static extern void DisplayHelloFromDLL();

        [DllImport(@"TestLib.dll", CallingConvention = CallingConvention.Cdecl)]
        public static extern void CallHelloFromDLL(StringBuilder s);

        static void Main()
        {
            Console.WriteLine("This is C# program");
            DisplayHelloFromDLL();
            StringBuilder sb = new StringBuilder(100);
            CallHelloFromDLL(sb);
            Console.WriteLine(sb);
    }
}

在混合编程中，涉及了几个要点。

1. 如何在DLL中将函数接口暴露出来？
   有两种方式，一种是采用__declspec(dllexport)的声明，另一种是编写额外的def文件，如

   ;导出DLL函数
   LIBRARY testLib
   EXPORTS 
   DisplayHelloFromDLL
   CallHelloFromDLL
   

2. DLL与C#之间如何进行数据传送？
   这个问题其实很复杂，像int，double这种基本的数据类型，是很好传递的。到了byte和char，就有点复杂了，更复杂的还有string和stringBuilder，以及结构体的传递等。
   若传递的是指针，有两种方法，一种是采用托管的方式，使用Intptr存储指针，并使用ref获得地址（&）；另一种是在C#中编写非托管的代码，用unsafe声明：

   unsafe
   {
   //非托管代码
   }
   

   在非托管代码中，即可进行指针相关的操作。
   若传递的是函数指针，由于C#中没有函数指针的概念，因此采用委托（delegate）的方式。 
   若传递的是自定义结构体，也可以采用ref的方式传递。
   这个如果有机会的话，我会单独整理一下。

3. extern “C”、CallingConvention =CallingConvention.Cdecl)等必要声明。
   这里面也牵涉到复杂的语言机制，本文不再赘述。

GC(垃圾回收)

既然CLR自动处理对象的垃圾回收，为什么还要去了解GC和内存分配呢？

答：当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对虚拟机的自动管理技术实施必要的监控和调节了。 

前言

.net CLR在运行我们的程序时，在内存中开辟了两块地方作不同的用处--托管栈和托管堆. 托管栈用来存放局部变量, 跟踪程序调用与返回. 托管堆用来存放引用类型. 引用类型总是存放于托管堆. 值类型通常是放在托管栈上面的. 如果一个值类型是一个引用类型的一部分，则此值类型随该引用类型存放于托管堆中.

C#的new操作符导致CLR执行以下步骤

①计算类型的字段（以及从基类型继承的字段）所需的字节数。

②加上对象的开销所需的字节数。每个对象都有两个开销字段：类型对象指针和同步快索引（32位：两个字段各需32位，所以每个对象要增加8字节。64位：每个字段各需64位，所以每个对象要增加16字节）（int=4字节；long=8字节）

③CLR检查区域中是否有分配对象所需的字节数。如果托管堆有足够的可用空间，就在NextObjPtr指针指向的地址处放入对象，为对象分配的字节会被清零。接着调用类型的构造器（为this参数传递NextObjPtr），new操作符返回对象的引用。就在返回这个引用之前，NextObjPtr指针的值会加上对象占用的字节数来得到一个新值，即下一个对象放入托管堆是的地址

根The root

垃圾收集器寻找不再使用的托管对象时, 其判断依据是当一个对象不再有引用指向它, 就说明此对象是可以释放了. 一些复杂的情况下可以出现一个对象指向第二个对象,第二个对象指向第三个对象,…就象一个链表. 那么, 垃圾收集器从哪里开始查找不再使用的托管对象呢? 以刚才所说的链表为例, 显然是应该从链表的开头开始查找.

那么，在链表开头的是些什么东东呢?

是局部变量, 全局变量, 静态变量, 指向托管堆的CPU寄存器. 在CLR中，它们被称之为根

如何判断这个对象该不该回收?

垃圾收集器首先假定所有在托管堆里面的对象都是不可到达的(或者说没有被引用的,不再需要的), 然后从根上的那些变量开始, 针对每一个根上的变量, 找出其引用的托管堆上的对象, 将找到的对象加入这个图, 然后再沿着这个对象往下找，看看它有没有引用另外一个对象, 有的话，继续将找到的对象加入图中,如果没有的话, 就说明这条链已经找到尾部了. 垃圾收集器就去从根上的另外一个变量开始找, 直到根上的所有变量都找过了, 然后垃圾收集器才停止查找. 值得一提的是, 在查找过程中, 垃圾收集器有些小的优化, 如: 由于对象间的引用关系可能是比较复杂的, 所以有可能找到一个对象, 而此对象已经加入图了, 那么垃圾收集器就不再在此条链上继续查找, 转去其他的链上继续找. 这样对垃圾收集器的性能有所改善.

垃圾收集器建好这个图之后, 剩下那些没有在这个图中的对象就是不再需要的. 垃圾收集器就可以回收它们占用的空间

具体回收步骤:

CLR使用一种引用跟踪算法。引用跟踪算法只关心引用类型的变量，因为只有这种变量才能引用堆上的对象，我们将所有引用类型的变量都称为根。

①CLR开始GC时，首先暂停进程中的所有线程（这样可以防止线程在CLR检查期间访问对象并更改其状态）

②CLR进入GC标记阶段（这个阶段，CLR遍历堆中所有对象，将同步块索引字段中的一位设为0。这表明所有的对象都应该删除）

③CLR检查所有活动根（根为null，则CLR忽略这个根），查看他们引用了那些对象。如果引用了堆上的对象，CLR都会标记那个对象（将对象的同步块索引中的位设置为1）

④检查完毕后，堆中的对象要么标记。要么未标记。已标记的对象不能被垃圾回收，因为至少有一个根在引用它，我们说这些对象时可达的

⑤进入GC的压缩阶段，在这个阶段，CLR对堆中已标记的对象进行“乾坤大挪移”，压缩所有幸存下来的对象，使它们占用连续的内存对象

⑥压缩之后，根现在的引用还是原来的位置，而非移动之后的位置。所以作为压缩阶段的一部分，CLR还要从每个根减去所引用的对象在内存中的偏移的字节数。这样就能保证根还是引用和之前一样的对象；只是对象在内存中换了位置

代的概念

①CLR初始化堆时为0代和1代选择预算容量（以kb为单位）。后期CLR会自动调节预算容量
②如果分配一个新的对象造成第0代超过预算，就必须启动一次垃圾回收
③经过垃圾回收之后，第0代的幸存者被提升到1代（第一代的大小增加）；第0代又空了出来
④由于第0代已满，所以必须垃圾回收。但这一次垃圾回收器发现第1代用完了预算容量。所以这次垃圾回收器决定检查第1代和第0代的所有对象。两代被垃圾回收以后，第1代的幸存者提升到2代，第0代的幸存者提升到1代

2，垃圾回收触发的条件
①最常见触发条件：CLR在检查第0代超过预算时触发一次GC
②代码显示调用Sytem.GC的静态Collect方法
③Windows报告底内存情况
④CLR正在卸载AppDomain
⑤CLR正在关闭（CLR在进程正常终止时）

3，大对象
目前认为85000字节或更大的对象时大对象。（之前讨论的都是小对象）。大对象一般是大字符串（比如XML或JSON）或者用于I/O操作的字节数组（比如从文件或网络将字节读入缓冲区一遍处理）
①大对象不是在小对象的地址空间分配，而是在进程地址空间的其他地方分配
②目前版本的GC不压缩大对象，因为在内存中移动它们的代价过高
③大对象总是第2代，绝不可能是第0代或者第1代