楼猪的上一篇“实现IDisposable接口，手动完成资源回收”本是无心之作，自己的本意是实现类似于微软.net里的某些类，外部调用的时候using一下完事。看了园子里几位高手的留言，楼猪在这里统一感谢他们的不吝赐教。下面楼猪就简单总结并回答一下他们的观点：
1、资源回收代价大，代码中慎用GC回收
楼猪：完全赞同。一直以来楼猪肤浅的认识就是，.net是自动回收机制，早晚它都会调用GC帮我们处理释放内存的。在平时的项目中楼猪从来没有写过用GC回收什么东西，但是看过其他人的一段服务端处理excel的代码中用了GC，第一感觉还是蛮恐怖也蛮高级的。现在想想，那段代码的GC显式回收的应该是非托管资源，估计是怕操作excel占用服务器资源过多，内存飙升，所以才手动启动GC回收的。
2、托管资源就交给系统（“系统”是CLR还是GC还是其他什么呢？）处理
楼猪：部分赞同。
（1）、如果是framework里的非托管的基础类库，那些有Close或者Dispose方法的类（比如数据库连接，流和文件的操作等等），通常楼猪都是不带思考的using一下就over了；其他没有实现IDisposable接口的类，在使用完了之后再让某个实例变量指向null空引用或者什么也不写就让GC自动回收。这个当然完全赞同。
（2）、对于一个自己设计封装完成某些用途的类，比如上文里的Sample4GC类，它里面包含了一个文本流对象，假如现在要在Sample4GC里写三个不同的读写文件的方法，难道我们有必要每次都在类的三个方法里面using一下或fs.Dispose一下或fs.Close;fs=null一下吗？为什么不放在一个公共的地方比如Dispose方法里处理呢？外部调用的时候，using一下然后调用需要使用的方法不是也很方便吗？所以自己设计封装的类，看具体使用情况，该手动及时回收的还是需要自己写点代码处理的（nc楼猪又装13了。虽然一直自命也是个明白人吧，而且确实曾经也写过几个继承自IDisposable接口的公共处理类，但是Dispose基本上都是空方法，没有手动实现过资源回收，请原谅楼猪偏执浅薄的理解，呵呵）。
3、非托管资源由.net显式释放。
楼猪：完全赞同。GC的自动回收设计主要是针对托管资源，非托管资源你不控制它去管，它也管不了啊。
再抛砖，欢迎来拍。