资源
资源分2种 托管资源 和 非托管资源
非托管资源： 所有的Window内核对象（句柄）都是非托管资源，如Stream,数据库连接，GDI相关对象，还有Com对象等等。这些资源并不是收到CLR管理
托管资源：由CLR管理分配和释放的资源，即由CLR里new出来的对象。
非托管资源：需要显式释放的，也即需要你写代码释放
托管资源：并不需要显示释放，但是如果引用类型本身含有非托管资源，则需要进行现实释放
释放资源的方法
1：实现IDisposable接口的Dispose方法；
2：析构方法（终结器）；
3：提供显示释放方法，比如常用的Close方法；
托管对像的生命周期
1.当我们创建一个对象的时候，运行构造函数，为其分配一块内存，我们称之为一个活对象。
2.当一个对象或者它的任何部分在后续的程序执行过程中不再可能被访问的时候，它就被视为不再被使用的对象，满足了销毁的条件，GC就会做出判断，该对象是否满足回收的条件，之后开始干活，你懂得。
3.当GC觉得你这个对象应该挂了，他就会启动这个对象的自杀式武器（如果该对象有析构函数）来自我结果，至于他什么时候要你挂，完全要看他的心情，或许就是她觉得你这个对象没什么利用价值了，正所谓飞鸟尽良弓藏。
4.当你这个对象运行析构函数(要挂)的时候，可能在存在运行析构函数的时候在析构函数内部重新指向了一个对象的情况。所以只有当该对象包括在析构函数的一切后续程序中都在没有可能被访问的时候GC才会认为是满足了回收条件。
5.当对象满足被回收的条件的时候，GC就会释放对象所占的所有内存。
能否自己控制垃圾回收？
说到这里我们是否考虑到能否自己控制垃圾回收呢，答案是肯定的，我们可以使用GC类提供的GC.Collect方法来使应用程序在一定程度上直接控制垃圾回收器，但是一般不要去手动干预GC。没有特殊理由，不要去调用GC.Collect()，让它自己决定什么时候去回收内存。还是人家的比较严谨。
是的，我们可以在确定某个时间点的内存使用量大量减少的时候叫服务员过来收一下盘子（GC.Collect()一下)，但是如果我们频繁的叫服务员过来清理垃圾是不是会影响我们吃饭呢，这就好比，服务员过来收拾垃圾，对大家说，先生们先别吃请抬一下手，我先擦一下桌子，接着刚又下手吃的还没尽兴，又
有个同桌小妞叫服务员有过来收拾垃圾，又说先生们再抬一下手，姐又要收拾下空盘子...!#$@,你妹呀，自己喊过来喊过去的，原来还是很影响自己吃饭呀，以后一定要有个约定积累到一定的量在叫服务员过来服务，这样还不如用他们店里自己的回收垃圾规则啊，人家毕竟是干这行的，顾客至善，人家啥时候来GC那才叫专业。所以还是在遇到服务员开小差le再去叫她，一般不要主动叫啦。
这个叫小姐过来服务的的过程她会要我们先停手，这就可以很好理解，在垃圾回收器执行回收之前，它会挂起当前正在执行（吃）的所有线程。如果不必要的多次进行GC.Collect（）方法，则可能（影响吃饭）降低程序执行的性能。从而人为地削弱了垃圾回收器本身优化引擎的作用。