构建高性能ASP.NET站点 第七章 如何解决内存的问题(后篇)—托管资源优化—监常用优化措施
前言：有段时间没有写这个系列了,希望大家见谅,本篇主要将会介绍一些常用的CLR优化措施.
本篇的议题如下：
内存问题概述(前篇)
托管资源优化（前篇）
对象的生命周期（前篇）
对象的”代“（前篇）
大对象堆(LOH) （前篇）
CLR计数器的使用 （中篇）
CLR Profiler的使用（中篇）
垃圾回收器的不同版本（中篇）
对象使用注意事项（后篇）
常用优化措施（后篇）
非托管资源优化
Session会话的优化
对象使用注意事项
在之前的内容,我们讲述了CLR的托管堆的相关知识,同时也讲述了CLR的垃圾回收机制,对于对象,言有一点要记住:尽可能晚的创对象。目的是使得对象的“代”尽可能的小，让没有必要生存很长时间的对象尽可能早的被回收。
下面是对象使用的注意事项：
1. 不要过早的创建大对象，然后再很久之后才用，而是在要用的才创建，如下：
不要这样：
而要这样：
同样，这个原则也适用于消耗资源很多的对象，例如Transaction事务对象，要尽可能晚的打开事务，尽可能早的关闭事务。
2. 如果在.NET4 中，可以考虑使用Lazy<T>。它可以使得我们定义事先定义一个对象，知道需要的时候才实例化它。如下：
通过以下语句在需要时，获取这个对象：
3. 对于确定不再需要的对象，尽早的释放，将其引用设为null，如下：
常用优化措施
1. 使用StringBuilder进行字符串拼接
不要这样：
要这样:
不要这样：
要这样：
注:
1.如果需要拼接的字符串超过了6个以上，那么就可以用StringBuilder，如果没有超过6个，那么可以直接将其拼接，两者区别不大。
2. 如果可以知道估算出字符串的长度，可以在使用StringBuilder拼接的时候，尽量的声明StringBuilder的容量，例如new StringBuilder(1000);因为如果不声明容量，StringBuilder的默认容量是16，如果字符串过长，那么CLR会重新为StringBuilder分配新的容量和内存，把原来的字符串copy过来，这样，原来的字符串保存空间就浪费，直到 CLR垃圾回收才释放。
2.使用Compare进行字符串的大小比较
比较字符串是否相等的时候，一般如下：
但是，这样会更好：
因为在Compare方法比较的时候是一个字节一个字节的比较，这样会更快。
3.使用Response.Write来输出缓冲
在ASP.NET中，采用Response.Write来讲数据发送到浏览器，
不要采用：
要采用：
本文转自yanyangtian51CTO博客，原文链接：http://blog.51cto.com/yanyangtian/518321 ，如需转载请自行联系原作者