.NET 性能优化方法总结
2012-01-05 10:08
363 查看
1. C#语言方面
1.1 垃圾回收
垃圾回收解放了手工管理对象的工作，提高了程序的健壮性，但副作用就是程序代码可能对于对象创建变得随意。
1.1.1避免不必要的对象创建
由于垃圾回收的代价较高，所以C#程序开发要遵循的一个基本原则就是避免不必要的对象创建。以下列举一些常见的情形。
1.1.1.1避免循环创建对象 ★
如果对象并不会随每次循环而改变状态，那么在循环中反复创建对象将带来性能损耗。高效的做法是将对象提到循环外面创建。
1.1.1.2在需要逻辑分支中创建对象
如果对象只在某些逻辑分支中才被用到，那么应只在该逻辑分支中创建对象。
1.1.1.3使用常量避免创建对象
程序中不应出现如 new Decimal(0) 之类的代码，这会导致小对象频繁创建及回收，正确的做法是使用Decimal.Zero常量。我们有设计自己的类时，也可以学习这个设计手法，应用到类似的场景中。
1.1.1.4使用StringBuilder做字符串连接
1.1.2不要使用空析构函数 ★
如果类包含析构函数，由创建对象时会在 Finalize 队列中添加对象的引用，以保证当对象无法可达时，仍然可以调用到Finalize 方法。垃圾回收器在运行期间，会启动一个低优先级的线程处理该队列。相比之下，没有析构函数的对象就没有这些消耗。如果析构函数为空，这个消耗就毫无意义，只会导致性能降低！因此，不要使用空的析构函数。
在实际情况中，许多曾在析构函数中包含处理代码，但后来因为种种原因被注释掉或者删除掉了，只留下一个空壳，此时应注意把析构函数本身注释掉或删除掉。
1.1.3实现 IDisposable接口
垃圾回收事实上只支持托管内在的回收，对于其他的非托管资源，例如Window GDI 句柄或数据库连接，在析构函数中释放这些资源有很大问题。原因是垃圾回收依赖于内在紧张的情况，虽然数据库连接可能已濒临耗尽，但如果内存还很充足的话，垃圾回收是不会运行的。
C#的 IDisposable 接口是一种显式释放资源的机制。通过提供 using 语句，还简化了使用方式（编译器自动生成 try ... finally 块，并在 finally 块中调用 Dispose 方法）。对于申请非托管资源对象，应为其实现 IDisposable 接口，以保证资源一旦超出 using 语句范围，即得到及时释放。这对于构造健壮且性能优良的程序非常有意义！
为防止对象的 Dispose 方法不被调用的情况发生，一般还要提供析构函数，两者调用一个处理资源释放的公共方法。同时，Dispose 方法应调用 System.GC.SuppressFinalize(this)，告诉垃圾回收器无需再处理 Finalize 方法了。
1.2 String 操作
1.2.1使用StringBuilder 做字符串连接
String 是不变类，使用 + 操作连接字符串将会导致创建一个新的字符串。如果字符串连接次数不是固定的，例如在一个循环中，则应该使用 StringBuilder 类来做字符串连接工作。因为 StringBuilder 内部有一个 StringBuffer ，连接操作不会每次分配新的字符串空间。只有当连接后的字符串超出 Buffer 大小时，才会申请新的 Buffer 空间。典型代码如下：
StringBuilder sb = new StringBuilder( 256 );
for (int i = 0 ; i < Results.Count; i ++ )
{
sb.Append (Results[i]);
}
如果连接次数是固定的并且只有几次，此时应该直接用 + 号连接，保持程序简洁易读。实际上，编译器已经做了优化，会依据加号次数调用不同参数个数的 String.Concat 方法。例如：
String str = str1 + str2 + str3 + str4;
会被编译为 String.Concat(str1, str2,str3, str4)。该方法内部会计算总的String 长度，仅分配一次，并不会如通常想象的那样分配三次。作为一个经验值，当字符串连接操作达到 10 次以上时，则应该使用StringBuilder。
这里有一个细节应注意：StringBuilder 内部 Buffer 的缺省值为 16 ，这个值实在太小。按 StringBuilder 的使用场景，Buffer 肯定得重新分配。经验值一般用 256 作为 Buffer 的初值。当然，如果能计算出最终生成字符串长度的话，则应该按这个值来设定Buffer 的初值。使用 newStringBuilder(256) 就将 Buffer
的初始长度设为了256。
1.2.2避免不必要的调用ToUpper 或 ToLower 方法
String是不变类，调用ToUpper或ToLower方法都会导致创建一个新的字符串。如果被频繁调用，将导致频繁创建字符串对象。这违背了前面讲到的“避免频繁创建对象”这一基本原则。
例如，bool.Parse方法本身已经是忽略大小写的，调用时不要调用ToLower方法。
另一个非常普遍的场景是字符串比较。高效的做法是使用 Compare 方法，这个方法可以做大小写忽略的比较，并且不会创建新字符串。
还有一种情况是使用 HashTable 的时候，有时候无法保证传递 key 的大小写是否符合预期，往往会把 key 强制转换到大写或小写方法。实际上 HashTable 有不同的构造形式，完全支持采用忽略大小写的 key: newHashTable(StringComparer.OrdinalIgnoreCase)。
1.2.3最快的空串比较方法
将String对象的Length属性与0比较是最快的方法：if (str.Length == 0)
其次是与String.Empty常量或空串比较：if (str == String.Empty)或if (str == "")
注：C#在编译时会将程序集中声明的所有字符串常量放到保留池中（intern pool），相同常量不会重复分配。
1.3 多线程
1.3.1线程同步
线程同步是编写多线程程序需要首先考虑问题。C#为同步提供了 Monitor、Mutex、AutoResetEvent 和 ManualResetEvent 对象来分别包装 Win32 的临界区、互斥对象和事件对象这几种基础的同步机制。C#还提供了一个lock语句，方便使用，编译器会自动生成适当的 Monitor.Enter 和 Monitor.Exit 调用。
1.3.1.1同步粒度
同步粒度可以是整个方法，也可以是方法中某一段代码。为方法指定MethodImplOptions.Synchronized 属性将标记对整个方法同步。例如：
[MethodImpl(MethodImplOptions.Synchronized)]
public static SerialManagerGetInstance()
{
if (instance == null )
{
instance = new SerialManager();
}
return instance;
}
通常情况下，应减小同步的范围，使系统获得更好的性能。简单将整个方法标记为同步不是一个好主意，除非能确定方法中的每个代码都需要受同步保护。
1.3.1.2同步策略
使用 lock 进行同步，同步对象可以选择 Type、this 或为同步目的专门构造的成员变量。
避免锁定Type★
锁定Type对象会影响同一进程中所有AppDomain该类型的所有实例，这不仅可能导致严重的性能问题，还可能导致一些无法预期的行为。这是一个很不好的习惯。即便对于一个只包含static方法的类型，也应额外构造一个static的成员变量，让此成员变量作为锁定对象。
避免锁定 this
锁定 this 会影响该实例的所有方法。假设对象 obj 有 A 和 B 两个方法，其中 A 方法使用 lock(this) 对方法中的某段代码设置同步保护。现在，因为某种原因，B 方法也开始使用 lock(this) 来设置同步保护了，并且可能为了完全不同的目的。这样，A 方法就被干扰了，其行为可能无法预知。所以，作为一种良好的习惯，建议避免使用 lock(this) 这种方式。
使用为同步目的专门构造的成员变量
这是推荐的做法。方式就是 new 一个 object 对象， 该对象仅仅用于同步目的。
如果有多个方法都需要同步，并且有不同的目的，那么就可以为些分别建立几个同步成员变量。
1.3.1.4集合同步
C#为各种集合类型提供了两种方便的同步机制：Synchronized 包装器和 SyncRoot 属性。
// Creates and initializes a new ArrayList
ArrayList myAL = new ArrayList();
myAL.Add( " The " );
myAL.Add( " quick " );
myAL.Add( " brown " );
myAL.Add( " fox " );
// Creates a synchronized wrapper around the ArrayList
ArrayList mySyncdAL = ArrayList.Synchronized(myAL);
调用 Synchronized 方法会返回一个可保证所有操作都是线程安全的相同集合对象。考虑mySyncdAL[0] = mySyncdAL[0] + "test" 这一语句，读和写一共要用到两个锁。一般讲，效率不高。推荐使用 SyncRoot 属性，可以做比较精细的控制。
1.3.2使用ThreadStatic 替代NameDataSlot ★
存取 NameDataSlot 的 Thread.GetData 和 Thread.SetData 方法需要线程同步，涉及两个锁：一个是LocalDataStore.SetData 方法需要在 AppDomain 一级加锁，另一个是 ThreadNative.GetDomainLocalStore 方法需要在 Process 一级加锁。如果一些底层的基础服务使用了 NameDataSlot，将导致系统出现严重的伸缩性问题。
规避这个问题的方法是使用 ThreadStatic 变量。示例如下：
public sealed class InvokeContext
{
[ThreadStatic]
private static InvokeContext current;
private Hashtable maps = new Hashtable();
}
1.3.3多线程编程技巧
1.3.3.1使用 DoubleCheck 技术创建对象
internal IDictionary KeyTable
{
get
{
if ( this ._keyTable == null )
{
lock ( base ._lock)
{
if ( this ._keyTable == null)
{
this ._keyTable = new Hashtable();
}
}
}
return this ._keyTable;
}
}
创建单例对象是很常见的一种编程情况。一般在 lock 语句后就会直接创建对象了，但这不够安全。因为在 lock 锁定对象之前，可能已经有多个线程进入到了第一个 if 语句中。如果不加第二个 if语句，则单例对象会被重复创建，新的实例替代掉旧的实例。如果单例对象中已有数据不允许被破坏或者别的什么原因，则应考虑使用 Double Check 技术。
1.4 类型系统
1.4.1避免无意义的变量初始化动作
CLR保证所有对象在访问前已初始化，其做法是将分配的内存清零。因此，不需要将变量重新初始化为0、false或null。
需要注意的是：方法中的局部变量不是从堆而是从栈上分配，所以C#不会做清零工作。如果使用了未赋值的局部变量，编译期间即会报警。不要因为有这个印象而对所有类的成员变量也做赋值动作，两者的机理完全不同！
1.4.2ValueType 和ReferenceType
1.4.2.1以引用方式传递值类型参数
值类型从调用栈分配，引用类型从托管堆分配。当值类型用作方法参数时，默认会进行参数值复制，这抵消了值类型分配效率上的优势。作为一项基本技巧，以引用方式传递值类型参数可以提高性能。
1.4.2.2为 ValueType 提供 Equals 方法
.net 默认实现的 ValueType.Equals方法使用了反射技术，依靠反射来获得所有成员变量值做比较，这个效率极低。如果我们编写的值对象其 Equals 方法要被用到（例如将值对象放到 HashTable 中），那么就应该重载 Equals 方法。
public struct Rectangle
{
public double Length;
public double Breadth;
public override bool Equals ( object ob)
{
if (ob is Rectangle)
return Equels ((Rectangle)ob))
else
return false ;
}
private bool Equals (Rectangle rect)
{
return this .Length == rect.Length && this .Breadth == rect.Breach;
}
}
1.4.2.3避免装箱和拆箱
C#可以在值类型和引用类型之间自动转换，方法是装箱和拆箱。装箱需要从堆上分配对象并拷贝值，有一定性能消耗。如果这一过程发生在循环中或是作为底层方法被频繁调用，则应该警惕累计的效应。
一种经常的情形出现在使用集合类型时。例如：
ArrayList al = new ArrayList();
for (int i = 0 ; i < 1000 ; i ++ )
{
al.Add(i); // Implicitly boxed because Add() takes anobject
}
int f = ( int )al[ 0 ]; // The element is unboxed
1.5 异常处理
异常也是现代语言的典型特征。与传统检查错误码的方式相比，异常是强制性的（不依赖于是否忘记了编写检查错误码的代码）、强类型的、并带有丰富的异常信息（例如调用栈）。
1.5.1不要吃掉异常★
关于异常处理的最重要原则就是：不要吃掉异常。这个问题与性能无关，但对于编写健壮和易于排错的程序非常重要。这个原则换一种说法，就是不要捕获那些你不能处理的异常。
吃掉异常是极不好的习惯，因为你消除了解决问题的线索。一旦出现错误，定位问题将非常困难。除了这种完全吃掉异常的方式外，只将异常信息写入日志文件但并不做更多处理的做法也同样不妥。
1.5.2不要吃掉异常信息★
有些代码虽然抛出了异常，但却把异常信息吃掉了。
为异常披露详尽的信息是程序员的职责所在。如果不能在保留原始异常信息含义的前提下附加更丰富和更人性化的内容，那么让原始的异常信息直接展示也要强得多。千万不要吃掉异常。
1.5.3避免不必要的抛出异常
抛出异常和捕获异常属于消耗比较大的操作，在可能的情况下，应通过完善程序逻辑避免抛出不必要不必要的异常。与此相关的一个倾向是利用异常来控制处理逻辑。尽管对于极少数的情况，这可能获得更为优雅的解决方案，但通常而言应该避免。
1.5.4避免不必要的重新抛出异常
如果是为了包装异常的目的（即加入更多信息后包装成新异常），那么是合理的。但是有不少代码，捕获异常没有做任何处理就再次抛出，这将无谓地增加一次捕获异常和抛出异常的消耗，对性能有伤害。
1.6 反射
反射是一项很基础的技术，它将编译期间的静态绑定转换为延迟到运行期间的动态绑定。在很多场景下（特别是类框架的设计），可以获得灵活易于扩展的架构。但带来的问题是与静态绑定相比，动态绑定会对性能造成较大的伤害。
1.6.1反射分类
type comparison ：类型判断，主要包括 is 和 typeof 两个操作符及对象实例上的 GetType 调用。这是最轻型的消耗，可以无需考虑优化问题。注意 typeof 运算符比对象实例上的 GetType 方法要快，只要可能则优先使用 typeof 运算符。
member enumeration ： 成员枚举，用于访问反射相关的元数据信息，例如Assembly.GetModule、Module.GetType、Type对象上的IsInterface、IsPublic、GetMethod、GetMethods、GetProperty、GetProperties、GetConstructor调用等。尽管元数据都会被CLR缓存，但部分方法的调用消耗仍非常大，不过这类方法调用频度不会很高，所以总体看性能损失程度中等。
member invocation：成员调用，包括动态创建对象及动态调用对象方法，主要有Activator.CreateInstance、Type.InvokeMember等。
1.6.2动态创建对象
C#主要支持 5 种动态创建对象的方式：
1. Type.InvokeMember
2. ContructorInfo.Invoke
3. Activator.CreateInstance(Type)
4. Activator.CreateInstance(assemblyName, typeName)
5. Assembly.CreateInstance(typeName)
最快的是方式 3 ，与 Direct Create 的差异在一个数量级之内，约慢 7 倍的水平。其他方式，至少在 40 倍以上，最慢的是方式 4 ，要慢三个数量级。
1.6.3动态方法调用
方法调用分为编译期的早期绑定和运行期的动态绑定两种，称为Early-BoundInvocation和Late-BoundInvocation。Early-BoundInvocation可细分为Direct-call、Interface-call和Delegate-call。Late-Bound Invocation主要有Type.InvokeMember和MethodBase.Invoke，还可以通过使用LCG（Lightweight
Code Generation）技术生成IL代码来实现动态调用。
从测试结果看，相比Direct Call，Type.InvokeMember要接近慢三个数量级；MethodBase.Invoke虽然比Type.InvokeMember要快三倍，但比Direct Call仍慢270倍左右。可见动态方法调用的性能是非常低下的。我们的建议是：除非要满足特定的需求，否则不要使用！
1.6.4推荐的使用原则
模式
1． 如果可能，则避免使用反射和动态绑定
2． 使用接口调用方式将动态绑定改造为早期绑定
3． 使用Activator.CreateInstance(Type)方式动态创建对象
4． 使用typeof操作符代替GetType调用
反模式
1． 在已获得Type的情况下，却使用Assembly.CreateInstance(type.FullName)
1.7 基本代码技巧
这里描述一些应用场景下，可以提高性能的基本代码技巧。对处于关键路径的代码，进行这类的优化还是很有意义的。普通代码可以不做要求，但养成一种好的习惯也是有意义的。
1.7.1循环写法
可以把循环的判断条件用局部变量记录下来。局部变量往往被编译器优化为直接使用寄存器，相对于普通从堆或栈中分配的变量速度快。如果访问的是复杂计算属性的话，提升效果将更明显。for (int i = 0, j = collection.GetIndexOf(item); i < j; i++)
需要说明的是：这种写法对于CLR集合类的Count属性没有意义，原因是编译器已经按这种方式做了特别的优化。
1.7.2拼装字符串
拼装好之后再删除是很低效的写法。有些方法其循环长度在大部分情况下为1，这种写法的低效就更为明显了：
public static string ToString(MetadataKey entityKey)
{
string str = "" ;
object [] vals = entityKey.values;
for ( int i = 0 ; i < vals.Length; i ++ )
{
str += " , " + vals[i].ToString();
}
return str == "" ? "" : str.Remove( 0 , 1 );
}
推荐下面的写法：
if (str.Length == 0 )
str = vals[i].ToString();
else
str += " , " + vals[i].ToString();
其实这种写法非常自然，而且效率很高，完全不需要用个Remove方法绕来绕去。
1.7.3避免两次检索集合元素
获取集合元素时，有时需要检查元素是否存在。通常的做法是先调用ContainsKey（或Contains）方法，然后再获取集合元素。这种写法非常符合逻辑。
但如果考虑效率，可以先直接获取对象，然后判断对象是否为null来确定元素是否存在。对于Hashtable，这可以节省一次GetHashCode调用和n次Equals比较。
如下面的示例：
public IData GetItemByID(Guid id)
{
IData data1 = null ;
if ( this.idTable.ContainsKey(id.ToString())
{
data1 = this .idTable[id.ToString()] as IData;
}
return data1;
}
其实完全可用一行代码完成：returnthis.idTable[id] as IData;
1.7.4避免两次类型转换
考虑如下示例，其中包含了两处类型转换：
if (obj is SomeType)
{
SomeType st = (SomeType)obj;
st.SomeTypeMethod();
}
效率更高的做法如下：
SomeType st = obj as SomeType;
if (st != null )
{
st.SomeTypeMethod();
}
1.8 Hashtable
Hashtable是一种使用非常频繁的基础集合类型。需要理解影响Hashtable的效率有两个因素：一是散列码（GetHashCode方法），二是等值比较（Equals方法）。Hashtable首先使用键的散列码将对象分布到不同的存储桶中，随后在该特定的存储桶中使用键的Equals方法进行查找。
良好的散列码是第一位的因素，最理想的情况是每个不同的键都有不同的散列码。Equals方法也很重要，因为散列只需要做一次，而存储桶中查找键可能需要做多次。从实际经验看，使用Hashtable时，Equals方法的消耗一般会占到一半以上。
System.Object类提供了默认的GetHashCode实现，使用对象在内存中的地址作为散列码。我们遇到过一个用Hashtable来缓存对象的例子，每次根据传递的OQL表达式构造出一个ExpressionList对象，再调用QueryCompiler的方法编译得到CompiledQuery对象。以ExpressionList对象和CompiledQuery对象作为键值对存储到Hashtable中。ExpressionList对象没有重载GetHashCode实现，其超类ArrayList也没有，这样最后用的就是System.Object类的GetHashCode实现。由于ExpressionList对象会每次构造，因此它的HashCode每次都不同，所以这个CompiledQueryCache根本就没有起到预想的作用。这个小小的疏漏带来了重大的性能问题，由于解析OQL表达式频繁发生，导致CompiledQueryCache不断增长，造成服务器内存泄漏！解决这个问题的最简单方法就是提供一个常量实现，例如让散列码为常量0。虽然这会导致所有对象汇聚到同一个存储桶中，效率不高，但至少可以解决掉内存泄漏问题。当然，最终还是会实现一个高效的GetHashCode方法的。
以上介绍这些Hashtable机理，主要是希望大家理解：如果使用Hashtable，你应该检查一下对象是否提供了适当的GetHashCode和Equals方法实现。否则，有可能出现效率不高或者与预期行为不符的情况。
2. Ado.Net
2.1 应用Ado.net的一些思考原则
1. 根据数据使用的方式来设计数据访问层
2. 缓存数据，避免不必要的操作
3. 使用服务帐户进行连接
4. 必要时申请，尽早释放
5. 关闭可关闭的资源
6. 减少往返
7. 仅返回需要的数据
8. 选择适当的事务类型
9. 使用存储过程
2.2 Connection
数据库连接是一种共享资源，并且打开和关闭的开销较大。Ado.net默认启用了连接池机制，关闭连接不会真的关闭物理连接，而只是把连接放回到连接池中。因为池中共享的连接资源始终是有限的，如果在使用连接后不尽快关闭连接，那么就有可能导致申请连接的线程被阻塞住，影响整个系统的性能表现。
2.2.1在方法中打开和关闭连接
这个原则有几层含义：
1. 主要目的是为了做到必要时申请和尽早释放
2. 不要在类的构造函数中打开连接、在析构函数中释放连接。因为这将依赖于垃圾回收，而垃圾回收只受内存影响，回收时机不定
3. 不要在方法之间传递连接，这往往导致连接保持打开的时间过长
这里强调一下在方法之间传递连接的危害：曾经在压力测试中遇到过一个测试案例，当增大用户数的时候，这个案例要比别的案例早很久就用掉连接池中的所有连接。经分析，就是因为A方法把一个打开的连接传递到了B方法，而B方法又调用了一个自行打开和关闭连接的C方法。在A方法的整个运行期间，它至少需要占用两条连接才能够成功工作，并且其中的一条连接占用时间还特别长，所以造成连接池资源紧张，影响了整个系统的可伸缩性！
2.2.2显式关闭连接
Connection对象本身在垃圾回收时可以被关闭，而依赖垃圾回收是很不好的策略。推荐使用using语句显式关闭连接，如下例：
using (SqlConnection conn = newSqlConnection(connString))
{
conn.Open();
} // Dispose is automatically called on the conn variable here
2.2.3确保连接池启用
Ado.net是为每个不同的连接串建立连接池，因此应该确保连接串不会出现与具体用户相关的信息。另外，要注意连接串是大小写敏感的。
2.2.4不要缓存连接
例如，把连接缓存到Session或Application中。在启用连接池的情况下，这种做法没有任何意义。
2.3 Command
2.3.1使用ExecuteScalar和ExecuteNonQuery
如果想返回像Count(*)、Sum(Price)或Avg(Quantity)那样的单值，可以使用ExecuteScalar方法。ExecuteScalar返回第一行第一列的值，将结果集作为标量值返回。因为单独一步就能完成，所以ExecuteScalar不仅简化了代码，还提高了性能。
使用不返回行的SQL语句时，例如修改数据（INSERT、UPDATE或DELETE）或仅返回输出参数或返回值，请使用ExecuteNonQuery。这避免了用于创建空DataReader的任何不必要处理。
2.3.2使用Prepare
当需要重复执行同一SQL语句多次，可考虑使用Prepare方法提升效率。需要注意的是，如果只是执行一次或两次，则完全没有必要。例如：
cmd.CommandText = "insert into Table1( Col1, Col2 ) values ( @val1, @val2 )";
cmd.Parameters.Add( "@val1",SqlDbType.Int, 4, "Col1" );
cms.Parameters.Add( "@val2",SqlDbType.NChar, 50, "Col2");
cmd.Parameters[0].Value = 1;
cmd.Parameters[1].Value = "XXX";
cmd.Prepare();
cmd.ExecuteNonQuery();
cmd.Parameters[0].Value = 2;
cmd.Parameters[1].Value = "YYY";
cmd.ExecuteNonQuery();
cmd.Parameters[0].Value = 3;
cmd.Parameters[1].Value = "ZZZ";
cmd.ExecuteNonQuery();
2.3.3使用绑定变量 ★
SQL语句需要先被编译成执行计划，然后再执行。如果使用绑定变量的方式，那么这个执行计划就可以被后续执行的SQL语句所复用。而如果直接把参数合并到了SQL语句中，由于参数值千变万化，执行计划就难以被复用了。例如上面Prepare一节给出的示例，如果把参数值直接写到insert语句中，那么上面的四次调用将需要编译四次执行计划。
为避免这种情况造成性能损失，要求一律使用绑定变量方式。
2.4 DataReader
DataReader最适合于访问只读的单向数据集。与DataSet不同，数据集并不全部在内存中，而是随不断发出的read请求，一旦发现数据缓冲区中的数据均被读取，则从数据源传输一个数据缓冲区大小的数据块过来。另外，DataReader保持连接，DataSet则与连接断开。
2.4.1显式关闭DataReader
与连接类似，也需要显式关闭DataReader。另外，如果与DataReader关联的Connection仅为DataReader服务的话，可考虑使用Command对象的ExecuteReader(CommandBehavior.CloseConnection)方式。这可以保证当DataReader关闭时，同时自动关闭Connection。
2.4.2用索引号访问代替名称索引号访问属性
从Row中访问某列属性，使用索引号的方式比使用名称方式有细微提高。如果会被频繁调用，例如在循环中，那么可考虑此类优化。示例如下：
cmd.CommandText = "select Col1, Col2from Table1" ;
SqlDataReader dr = cmd.ExecuteReader();
int col1 = dr.GetOrdinal("Col1");
int col2 = dr.GetOrdinal("Col2");
while (dr.Read())
{
Console.WriteLine( dr[col1] + "_" + dr[col2]);
}
2.4.3使用类型化方法访问属性
从Row中访问某列属性，用GetString、GetInt32这种显式指明类型的方法，其效率较通用的GetValue方法有细微提高，因为不需要做类型转换。
2.4.4使用多数据集
部分场景可以考虑一次返回多数据集来降低网络交互次数，提升效率。示例如下：
cmd.CommandText ="StoredProcedureName"; //The stored procedure returns multiple result sets.
SqlDataReader dr = cmd.ExecuteReader();
while (dr.read())
// read first result set
dr.NextResult();
while (dr.read())
//
2.5 DataSet
2.5.1利用索引加快查找行的效率
如果需要反复查找行，建议增加索引。有两种方式：
1. 设置DataTable的PrimaryKey
适用于按PrimaryKey查找行的情况。注意此时应调用DataTable.Rows.Find方法，一般惯用的Select方法不能利用索引。
2. 使用DataView
适用于按Non-PrimaryKey查找行的情况。可为DataTable创建一个DataView，并通过SortOrder参数指示建立索引。此后使用Find或FindRows查找行。
2007-1-7周计划
工作上，上周末刚被调到另一个项目组救火，估计这周工作轻松不了，业余时间的学习计划也就订灵活点，复习一下数据结构和算法方面的知识，每种结构写一个Demo：
线性表
数组
矩阵
特殊矩阵
稀疏矩阵
堆栈
队列
跳表和散列
树
聊聊封装、继承
在C++中封装的概念是把一个对象的外观接口同实际工作方式（实现）分离开来，但是C++的封装是不完全的，编译器必须知道一个对象的所有部分的声明，以便创建和管理它。我们可以想象一种只需声明一个对象的公共接口部分的编程语言，而将私有的实现部分隐藏起来。C + +在编译期间要尽可能多地做静态类型检查。这意味着尽早捕获错误，也意味着程序具有更高的效率。然而这对私有的实现部分来说带来两个影响：一是即使程序员不能轻易地访问实现部分，但他可以看到它；二是造成一些不必要的重复编译。
然而C++并没有将这个原则应用到二进制层次上，这是因为C++的类既是描述了一个接口同时也描述了实现的过程,示例如下：
class CMyString
{
private:
const int m_cch;
char *m_psz;
public:
CMyString(const char *psz);
~CMyString();
intLength() const;
intIndex(const char *psz) const;
}
CMyStirng对外过多的暴露了内存布局实现的细节，这些信息过度的依赖于这些成员变量的大小和顺序，从而导致了客户过度依赖于可执行代码之间的二进制耦合关系，这样的接口不利于跨语言跨平台的软件开发和移植。
1.1.1 Handle-Body模式
解决这个问题的技术有一种叫句柄类（ handle classes）。有关实现的任何东西都消失了，只剩一个单一的指针“m_pThis”。该指针指向一个结构，该结构的定义与其所有的成员函数的定义都出现在实现文件中。这样，只要接口部分不改变，头文件就不需变动。而实现部分可以按需要任意更动，完成后只要对实现文件进行重新编译，然后再连接到项目中。
下面是这项技术的简单例子。头文件中只包含公共的接口和一个简单的没有完全指定的类指针。
class CMyStringHandle
{
private:
class CMyString；
CMyString *m_pThis;
public:
CMyStringHandle (const char *psz);
~CMyStringHandle ();
intLength() const;
intIndex(const char *psz) const;
}；
CMyStringHandle:: CMyStringHandle(constchar *psz)
:m_pThis(new CMyString(psz));
{
}
CMyStringHandle::~ CMyStringHandle()
{
delete m_pThis;
}
int CMyStringHandle::Length()
{
return m_pThis->Length();
}
int CMyStringHandle::Index(const char *psz)
{
return m_pThis->Index(psz);
}
这是所有客户程序员都能看到的。
class CMyString；
是一个没有完全指定的类型说明或类声明（一个类的定义包含类的主体）。它告诉编译器，CMyString是一个结构的名字，但没有提供有关该结构的任何东西。这对产生一个指向结构的指针来说已经足够了。但我们在提供一个结构的主体部分之前不能创建一个对象。在这种技术里，包含具体实现的结构主体被隐藏在实现文件中。
在设计模式中，这就叫做Handle-Body 模式，Handle-Body只含有一个实体指针，服务的数据成员永远被封闭在服务系统中。
Handle-Body的布局结构永远不会随着实现类数据成员的加入或者删除或者修改而导致Handle-Body的修改，即Handle-Body协议不依赖于C++实现类的任何细节。这就有效的对用户的编译器隐藏了这些细节，用户在使用对这项技术时候，Handle-Body 接口成了它唯一的入口。
然而Handle-Body模式也有自己的弱点：
1、接口类必须把每一个方法调用显示的传递给实现类，这在一个只有一个构造和一个析构的类来说显然不构成负担，但是如果一个庞大的类库，它有上百上千个方法时候，光是编写这些方法传递就有可能非常冗长，这也增加了出错的可能性。
2、对于关注于性能的应用每一个方法都得有两层的函数调用，嵌套的开销也不理想
3、由于句柄的存在，依然存在编译连接器兼容性问题。
1.1.2 抽象接口
使用了“接口与实现的分离”技术的 Handle-Body 解决了编译器/链接器的大部分问题，而C++面向对象编程中的抽象接口同样是运用了“接口与实现分离”的思想，而采用抽象接口对于解决这类问题是一个极其完美的解决方案。
1、抽象接口的语言描述：
class IMyString
{
virtual int Length() const = 0;//这表示是一个纯虚函数，具有纯虚函数的接口
virtual int Index(const char*psz) const = 0;
}；
2、抽象接口的内存结构：
抽象接口采用虚函数表来调用成员方法。
3、 抽象接口的实现代码：
接口：
class IMyString
实现：
class CMyString：public IMyString
{
private:
const int m_cch;
char *m_psz;
public:
CMyString(const char *psz);
virtual ~CMyString();
int Length() const;
int Index(const char *psz) const;
}
从上面采用抽象接口的实例来看，抽象接口解决了Handle-Body所遗留下来的全部缺陷。
抽象接口的一个典型应用：
抽象工厂（AbstractFactroy）
1.2 多继承与菱形缺陷、this跳转等
多重继承是C++语言独有的继承方式，其它几乎所有语言都秉承了单一继承的思想。这是因为多重继承致命的缺陷导致的：
1.2.1 菱形缺陷
当继承基类时，在派生类中就获得了基类所有的数据成员副本。假如类B 从A1和A2两个类多重继承而来，这样B类就包含A1、A2类的数据成员副本。
考虑如果A1、A2都从某基类派生，该基类称为Base，现在继承关系将出现菱形继承关系。
class Base{…… }；
class A1 :public Base {… … }；
class A2 :public Base {… … }；
class B :public A1,public A2 {… … }；
那么A1、A2都具有Base的副本。这样B就包含了Base的两个副本，副本发生了重叠，不但增加了存储空间，同时也引入了二义性。这就是菱形缺陷，菱形缺陷的两个缺陷：
1、子对象重叠
2、向上映射的二义性。
菱形缺陷的其中一种解决办法是使用虚拟继承。
在C++世界里最广泛的使用虚拟继承解决菱形缺陷的应用便是标准C++的输入/输出iostream；
1.2.2 多重接口与方法名冲突问题（Siamese twins）
对继承而来的虚函数改写很容易，但是如果是在改写一个“在两个基类都有相同原型”的虚函数情况就不那么容易了。
提出问题：
假设汽车最大速度的接口为ICar，潜艇最大速度的接口为 IBoat，有一个两栖类的交通工具它可以奔跑在马路上，也可以航行在大海中，那么它就同时拥有ICar、IBoat两种交通工具的最大速度特性，我们定义它的接口为ICarBoat；
class ICar
{
virtual int GetMaxSpeed（）= 0；
}；
class IBoat
{
virtual int GetMaxSpeed（）= 0；
}；
我们先对ICarBoat的接口做一个尝试：
class CCarBoat
{
virtual int GetMaxSpeed（）；//既完成ICar的GetMaxSpeed（）接口方法又 //完成IBoat的接口方法？显然不能够
};
解决问题：
显然上面这个尝试根本就无法成功，只用一个实现方法，怎么能够求出这个ICarBoat交通工具奔跑在马路上的最高时速，同时也能够求出航行在大海上的最大航行速度呢。
上面这一问题矛盾就在一一个方法，却需要两个答案。看来ICarBoat要返回两个答案就必须有两个方法了，我们假设一个方法是求在陆地上奔跑的速度，名称为GetCarMaxSpeed（）；另一个方法是求在大海上航行的最大速度，名称为GetBoatMaxSpeed（）；那这两个方法又怎么和GetMaxSpeed（）接口方法联系起来呢；
幸运的是，我们找到了解决办法，而且解决办法有很多种，下面介绍一下继承法。
class IXCar :public ICar
{
virtual int GetMaxSpeed（）
{
GetCarMaxSpeed();
}
virtual int GetCarMaxSpeed（） = 0;
}；
class IXBoat:public IBoat
{
virtual int GetMaxSpeed（）
{
GetBoatMaxSpeed();
}
virtual int GetBoatMaxSpeed（） = 0;
}；
classCCarBoat: public IXCar , public IXBoat
{
virtual int GetCarMaxSpeed（）
{
… …
}
virtual int GetBoatMaxSpeed（）
{
… …
}
};
1.2.3 this跳转
this跳转是指的“对象同一性”问题。
在单一继承的世界内，无论继承关系怎么复杂，针对于同一对象，无论它的子类或者父类的this指针永远相等。即如果 B从A继承，那么对于一个已经实例化B类的对象 bObject，永远有（B*）&bObject ==(A*)&bObject 成立。
但是在多继承的世界内，上面的等式就不能恒成立，对象的同一性受到了挑战。
特别的是，在多继承世界内如果菱形关系存在情况下，如果对于已经实例化B类的对象bObject; （Base*）（A1*）&bObject!= （Base*）（A2*）&bObject 成立，当这种事情发生的时候我们就只能特殊处理了。这种情况在COM应用中处处都会发生。
1.3 C++多态的两种多态形式和区别
C++有两种多态多态形式：
1、编译时刻多态，编译时刻多态依靠函数重载或者模板实现
2、运行时刻多态。运行时刻多态依靠需函数虚接口实现
我们C++语言来描述这种继承关系：
{
virtual int Length() const = 0;//这表示是一个纯虚函数，具有纯虚函数的接口
virtual int Index(const char*psz) const = 0;
}；
二叉树
准备在接下来的一周复习一下树的常用应用（优先队列、二叉搜索树、AVL树、红-黑树、B-树等）。再花一周学习一下图。然后就是算法了。
计划订得不具体，大概是因为业余时间，不确定因素太多，如（工作、自己懒惰等等），但自己有个习惯，每天睡前会把当天所做的事情用十多个字记在台历的日期旁边的空白处。看着密密麻麻的小台历，比起如今流行的每年一次的“阅之有字，言之无物”的工作总结，心里透着一种踏实。真希望每天一个目标，睡前问问自己“否达到了自己定下的目标”。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/sunchaohuang/archive/2009/04/03/4046801.aspx
1.1 垃圾回收
垃圾回收解放了手工管理对象的工作，提高了程序的健壮性，但副作用就是程序代码可能对于对象创建变得随意。
1.1.1避免不必要的对象创建
由于垃圾回收的代价较高，所以C#程序开发要遵循的一个基本原则就是避免不必要的对象创建。以下列举一些常见的情形。
1.1.1.1避免循环创建对象 ★
如果对象并不会随每次循环而改变状态，那么在循环中反复创建对象将带来性能损耗。高效的做法是将对象提到循环外面创建。
1.1.1.2在需要逻辑分支中创建对象
如果对象只在某些逻辑分支中才被用到，那么应只在该逻辑分支中创建对象。
1.1.1.3使用常量避免创建对象
程序中不应出现如 new Decimal(0) 之类的代码，这会导致小对象频繁创建及回收，正确的做法是使用Decimal.Zero常量。我们有设计自己的类时，也可以学习这个设计手法，应用到类似的场景中。
1.1.1.4使用StringBuilder做字符串连接
1.1.2不要使用空析构函数 ★
如果类包含析构函数，由创建对象时会在 Finalize 队列中添加对象的引用，以保证当对象无法可达时，仍然可以调用到Finalize 方法。垃圾回收器在运行期间，会启动一个低优先级的线程处理该队列。相比之下，没有析构函数的对象就没有这些消耗。如果析构函数为空，这个消耗就毫无意义，只会导致性能降低！因此，不要使用空的析构函数。
在实际情况中，许多曾在析构函数中包含处理代码，但后来因为种种原因被注释掉或者删除掉了，只留下一个空壳，此时应注意把析构函数本身注释掉或删除掉。
1.1.3实现 IDisposable接口
垃圾回收事实上只支持托管内在的回收，对于其他的非托管资源，例如Window GDI 句柄或数据库连接，在析构函数中释放这些资源有很大问题。原因是垃圾回收依赖于内在紧张的情况，虽然数据库连接可能已濒临耗尽，但如果内存还很充足的话，垃圾回收是不会运行的。
C#的 IDisposable 接口是一种显式释放资源的机制。通过提供 using 语句，还简化了使用方式（编译器自动生成 try ... finally 块，并在 finally 块中调用 Dispose 方法）。对于申请非托管资源对象，应为其实现 IDisposable 接口，以保证资源一旦超出 using 语句范围，即得到及时释放。这对于构造健壮且性能优良的程序非常有意义！
为防止对象的 Dispose 方法不被调用的情况发生，一般还要提供析构函数，两者调用一个处理资源释放的公共方法。同时，Dispose 方法应调用 System.GC.SuppressFinalize(this)，告诉垃圾回收器无需再处理 Finalize 方法了。
1.2 String 操作
1.2.1使用StringBuilder 做字符串连接
String 是不变类，使用 + 操作连接字符串将会导致创建一个新的字符串。如果字符串连接次数不是固定的，例如在一个循环中，则应该使用 StringBuilder 类来做字符串连接工作。因为 StringBuilder 内部有一个 StringBuffer ，连接操作不会每次分配新的字符串空间。只有当连接后的字符串超出 Buffer 大小时，才会申请新的 Buffer 空间。典型代码如下：
StringBuilder sb = new StringBuilder( 256 );
for (int i = 0 ; i < Results.Count; i ++ )
{
sb.Append (Results[i]);
}
如果连接次数是固定的并且只有几次，此时应该直接用 + 号连接，保持程序简洁易读。实际上，编译器已经做了优化，会依据加号次数调用不同参数个数的 String.Concat 方法。例如：
String str = str1 + str2 + str3 + str4;
会被编译为 String.Concat(str1, str2,str3, str4)。该方法内部会计算总的String 长度，仅分配一次，并不会如通常想象的那样分配三次。作为一个经验值，当字符串连接操作达到 10 次以上时，则应该使用StringBuilder。
这里有一个细节应注意：StringBuilder 内部 Buffer 的缺省值为 16 ，这个值实在太小。按 StringBuilder 的使用场景，Buffer 肯定得重新分配。经验值一般用 256 作为 Buffer 的初值。当然，如果能计算出最终生成字符串长度的话，则应该按这个值来设定Buffer 的初值。使用 newStringBuilder(256) 就将 Buffer
的初始长度设为了256。
1.2.2避免不必要的调用ToUpper 或 ToLower 方法
String是不变类，调用ToUpper或ToLower方法都会导致创建一个新的字符串。如果被频繁调用，将导致频繁创建字符串对象。这违背了前面讲到的“避免频繁创建对象”这一基本原则。
例如，bool.Parse方法本身已经是忽略大小写的，调用时不要调用ToLower方法。
另一个非常普遍的场景是字符串比较。高效的做法是使用 Compare 方法，这个方法可以做大小写忽略的比较，并且不会创建新字符串。
还有一种情况是使用 HashTable 的时候，有时候无法保证传递 key 的大小写是否符合预期，往往会把 key 强制转换到大写或小写方法。实际上 HashTable 有不同的构造形式，完全支持采用忽略大小写的 key: newHashTable(StringComparer.OrdinalIgnoreCase)。
1.2.3最快的空串比较方法
将String对象的Length属性与0比较是最快的方法：if (str.Length == 0)
其次是与String.Empty常量或空串比较：if (str == String.Empty)或if (str == "")
注：C#在编译时会将程序集中声明的所有字符串常量放到保留池中（intern pool），相同常量不会重复分配。
1.3 多线程
1.3.1线程同步
线程同步是编写多线程程序需要首先考虑问题。C#为同步提供了 Monitor、Mutex、AutoResetEvent 和 ManualResetEvent 对象来分别包装 Win32 的临界区、互斥对象和事件对象这几种基础的同步机制。C#还提供了一个lock语句，方便使用，编译器会自动生成适当的 Monitor.Enter 和 Monitor.Exit 调用。
1.3.1.1同步粒度
同步粒度可以是整个方法，也可以是方法中某一段代码。为方法指定MethodImplOptions.Synchronized 属性将标记对整个方法同步。例如：
[MethodImpl(MethodImplOptions.Synchronized)]
public static SerialManagerGetInstance()
{
if (instance == null )
{
instance = new SerialManager();
}
return instance;
}
通常情况下，应减小同步的范围，使系统获得更好的性能。简单将整个方法标记为同步不是一个好主意，除非能确定方法中的每个代码都需要受同步保护。
1.3.1.2同步策略
使用 lock 进行同步，同步对象可以选择 Type、this 或为同步目的专门构造的成员变量。
避免锁定Type★
锁定Type对象会影响同一进程中所有AppDomain该类型的所有实例，这不仅可能导致严重的性能问题，还可能导致一些无法预期的行为。这是一个很不好的习惯。即便对于一个只包含static方法的类型，也应额外构造一个static的成员变量，让此成员变量作为锁定对象。
避免锁定 this
锁定 this 会影响该实例的所有方法。假设对象 obj 有 A 和 B 两个方法，其中 A 方法使用 lock(this) 对方法中的某段代码设置同步保护。现在，因为某种原因，B 方法也开始使用 lock(this) 来设置同步保护了，并且可能为了完全不同的目的。这样，A 方法就被干扰了，其行为可能无法预知。所以，作为一种良好的习惯，建议避免使用 lock(this) 这种方式。
使用为同步目的专门构造的成员变量
这是推荐的做法。方式就是 new 一个 object 对象， 该对象仅仅用于同步目的。
如果有多个方法都需要同步，并且有不同的目的，那么就可以为些分别建立几个同步成员变量。
1.3.1.4集合同步
C#为各种集合类型提供了两种方便的同步机制：Synchronized 包装器和 SyncRoot 属性。
// Creates and initializes a new ArrayList
ArrayList myAL = new ArrayList();
myAL.Add( " The " );
myAL.Add( " quick " );
myAL.Add( " brown " );
myAL.Add( " fox " );
// Creates a synchronized wrapper around the ArrayList
ArrayList mySyncdAL = ArrayList.Synchronized(myAL);
调用 Synchronized 方法会返回一个可保证所有操作都是线程安全的相同集合对象。考虑mySyncdAL[0] = mySyncdAL[0] + "test" 这一语句，读和写一共要用到两个锁。一般讲，效率不高。推荐使用 SyncRoot 属性，可以做比较精细的控制。
1.3.2使用ThreadStatic 替代NameDataSlot ★
存取 NameDataSlot 的 Thread.GetData 和 Thread.SetData 方法需要线程同步，涉及两个锁：一个是LocalDataStore.SetData 方法需要在 AppDomain 一级加锁，另一个是 ThreadNative.GetDomainLocalStore 方法需要在 Process 一级加锁。如果一些底层的基础服务使用了 NameDataSlot，将导致系统出现严重的伸缩性问题。
规避这个问题的方法是使用 ThreadStatic 变量。示例如下：
public sealed class InvokeContext
{
[ThreadStatic]
private static InvokeContext current;
private Hashtable maps = new Hashtable();
}
1.3.3多线程编程技巧
1.3.3.1使用 DoubleCheck 技术创建对象
internal IDictionary KeyTable
{
get
{
if ( this ._keyTable == null )
{
lock ( base ._lock)
{
if ( this ._keyTable == null)
{
this ._keyTable = new Hashtable();
}
}
}
return this ._keyTable;
}
}
创建单例对象是很常见的一种编程情况。一般在 lock 语句后就会直接创建对象了，但这不够安全。因为在 lock 锁定对象之前，可能已经有多个线程进入到了第一个 if 语句中。如果不加第二个 if语句，则单例对象会被重复创建，新的实例替代掉旧的实例。如果单例对象中已有数据不允许被破坏或者别的什么原因，则应考虑使用 Double Check 技术。
1.4 类型系统
1.4.1避免无意义的变量初始化动作
CLR保证所有对象在访问前已初始化，其做法是将分配的内存清零。因此，不需要将变量重新初始化为0、false或null。
需要注意的是：方法中的局部变量不是从堆而是从栈上分配，所以C#不会做清零工作。如果使用了未赋值的局部变量，编译期间即会报警。不要因为有这个印象而对所有类的成员变量也做赋值动作，两者的机理完全不同！
1.4.2ValueType 和ReferenceType
1.4.2.1以引用方式传递值类型参数
值类型从调用栈分配，引用类型从托管堆分配。当值类型用作方法参数时，默认会进行参数值复制，这抵消了值类型分配效率上的优势。作为一项基本技巧，以引用方式传递值类型参数可以提高性能。
1.4.2.2为 ValueType 提供 Equals 方法
.net 默认实现的 ValueType.Equals方法使用了反射技术，依靠反射来获得所有成员变量值做比较，这个效率极低。如果我们编写的值对象其 Equals 方法要被用到（例如将值对象放到 HashTable 中），那么就应该重载 Equals 方法。
public struct Rectangle
{
public double Length;
public double Breadth;
public override bool Equals ( object ob)
{
if (ob is Rectangle)
return Equels ((Rectangle)ob))
else
return false ;
}
private bool Equals (Rectangle rect)
{
return this .Length == rect.Length && this .Breadth == rect.Breach;
}
}
1.4.2.3避免装箱和拆箱
C#可以在值类型和引用类型之间自动转换，方法是装箱和拆箱。装箱需要从堆上分配对象并拷贝值，有一定性能消耗。如果这一过程发生在循环中或是作为底层方法被频繁调用，则应该警惕累计的效应。
一种经常的情形出现在使用集合类型时。例如：
ArrayList al = new ArrayList();
for (int i = 0 ; i < 1000 ; i ++ )
{
al.Add(i); // Implicitly boxed because Add() takes anobject
}
int f = ( int )al[ 0 ]; // The element is unboxed
1.5 异常处理
异常也是现代语言的典型特征。与传统检查错误码的方式相比，异常是强制性的（不依赖于是否忘记了编写检查错误码的代码）、强类型的、并带有丰富的异常信息（例如调用栈）。
1.5.1不要吃掉异常★
关于异常处理的最重要原则就是：不要吃掉异常。这个问题与性能无关，但对于编写健壮和易于排错的程序非常重要。这个原则换一种说法，就是不要捕获那些你不能处理的异常。
吃掉异常是极不好的习惯，因为你消除了解决问题的线索。一旦出现错误，定位问题将非常困难。除了这种完全吃掉异常的方式外，只将异常信息写入日志文件但并不做更多处理的做法也同样不妥。
1.5.2不要吃掉异常信息★
有些代码虽然抛出了异常，但却把异常信息吃掉了。
为异常披露详尽的信息是程序员的职责所在。如果不能在保留原始异常信息含义的前提下附加更丰富和更人性化的内容，那么让原始的异常信息直接展示也要强得多。千万不要吃掉异常。
1.5.3避免不必要的抛出异常
抛出异常和捕获异常属于消耗比较大的操作，在可能的情况下，应通过完善程序逻辑避免抛出不必要不必要的异常。与此相关的一个倾向是利用异常来控制处理逻辑。尽管对于极少数的情况，这可能获得更为优雅的解决方案，但通常而言应该避免。
1.5.4避免不必要的重新抛出异常
如果是为了包装异常的目的（即加入更多信息后包装成新异常），那么是合理的。但是有不少代码，捕获异常没有做任何处理就再次抛出，这将无谓地增加一次捕获异常和抛出异常的消耗，对性能有伤害。
1.6 反射
反射是一项很基础的技术，它将编译期间的静态绑定转换为延迟到运行期间的动态绑定。在很多场景下（特别是类框架的设计），可以获得灵活易于扩展的架构。但带来的问题是与静态绑定相比，动态绑定会对性能造成较大的伤害。
1.6.1反射分类
type comparison ：类型判断，主要包括 is 和 typeof 两个操作符及对象实例上的 GetType 调用。这是最轻型的消耗，可以无需考虑优化问题。注意 typeof 运算符比对象实例上的 GetType 方法要快，只要可能则优先使用 typeof 运算符。
member enumeration ： 成员枚举，用于访问反射相关的元数据信息，例如Assembly.GetModule、Module.GetType、Type对象上的IsInterface、IsPublic、GetMethod、GetMethods、GetProperty、GetProperties、GetConstructor调用等。尽管元数据都会被CLR缓存，但部分方法的调用消耗仍非常大，不过这类方法调用频度不会很高，所以总体看性能损失程度中等。
member invocation：成员调用，包括动态创建对象及动态调用对象方法，主要有Activator.CreateInstance、Type.InvokeMember等。
1.6.2动态创建对象
C#主要支持 5 种动态创建对象的方式：
1. Type.InvokeMember
2. ContructorInfo.Invoke
3. Activator.CreateInstance(Type)
4. Activator.CreateInstance(assemblyName, typeName)
5. Assembly.CreateInstance(typeName)
最快的是方式 3 ，与 Direct Create 的差异在一个数量级之内，约慢 7 倍的水平。其他方式，至少在 40 倍以上，最慢的是方式 4 ，要慢三个数量级。
1.6.3动态方法调用
方法调用分为编译期的早期绑定和运行期的动态绑定两种，称为Early-BoundInvocation和Late-BoundInvocation。Early-BoundInvocation可细分为Direct-call、Interface-call和Delegate-call。Late-Bound Invocation主要有Type.InvokeMember和MethodBase.Invoke，还可以通过使用LCG（Lightweight
Code Generation）技术生成IL代码来实现动态调用。
从测试结果看，相比Direct Call，Type.InvokeMember要接近慢三个数量级；MethodBase.Invoke虽然比Type.InvokeMember要快三倍，但比Direct Call仍慢270倍左右。可见动态方法调用的性能是非常低下的。我们的建议是：除非要满足特定的需求，否则不要使用！
1.6.4推荐的使用原则
模式
1． 如果可能，则避免使用反射和动态绑定
2． 使用接口调用方式将动态绑定改造为早期绑定
3． 使用Activator.CreateInstance(Type)方式动态创建对象
4． 使用typeof操作符代替GetType调用
反模式
1． 在已获得Type的情况下，却使用Assembly.CreateInstance(type.FullName)
1.7 基本代码技巧
这里描述一些应用场景下，可以提高性能的基本代码技巧。对处于关键路径的代码，进行这类的优化还是很有意义的。普通代码可以不做要求，但养成一种好的习惯也是有意义的。
1.7.1循环写法
可以把循环的判断条件用局部变量记录下来。局部变量往往被编译器优化为直接使用寄存器，相对于普通从堆或栈中分配的变量速度快。如果访问的是复杂计算属性的话，提升效果将更明显。for (int i = 0, j = collection.GetIndexOf(item); i < j; i++)
需要说明的是：这种写法对于CLR集合类的Count属性没有意义，原因是编译器已经按这种方式做了特别的优化。
1.7.2拼装字符串
拼装好之后再删除是很低效的写法。有些方法其循环长度在大部分情况下为1，这种写法的低效就更为明显了：
public static string ToString(MetadataKey entityKey)
{
string str = "" ;
object [] vals = entityKey.values;
for ( int i = 0 ; i < vals.Length; i ++ )
{
str += " , " + vals[i].ToString();
}
return str == "" ? "" : str.Remove( 0 , 1 );
}
推荐下面的写法：
if (str.Length == 0 )
str = vals[i].ToString();
else
str += " , " + vals[i].ToString();
其实这种写法非常自然，而且效率很高，完全不需要用个Remove方法绕来绕去。
1.7.3避免两次检索集合元素
获取集合元素时，有时需要检查元素是否存在。通常的做法是先调用ContainsKey（或Contains）方法，然后再获取集合元素。这种写法非常符合逻辑。
但如果考虑效率，可以先直接获取对象，然后判断对象是否为null来确定元素是否存在。对于Hashtable，这可以节省一次GetHashCode调用和n次Equals比较。
如下面的示例：
public IData GetItemByID(Guid id)
{
IData data1 = null ;
if ( this.idTable.ContainsKey(id.ToString())
{
data1 = this .idTable[id.ToString()] as IData;
}
return data1;
}
其实完全可用一行代码完成：returnthis.idTable[id] as IData;
1.7.4避免两次类型转换
考虑如下示例，其中包含了两处类型转换：
if (obj is SomeType)
{
SomeType st = (SomeType)obj;
st.SomeTypeMethod();
}
效率更高的做法如下：
SomeType st = obj as SomeType;
if (st != null )
{
st.SomeTypeMethod();
}
1.8 Hashtable
Hashtable是一种使用非常频繁的基础集合类型。需要理解影响Hashtable的效率有两个因素：一是散列码（GetHashCode方法），二是等值比较（Equals方法）。Hashtable首先使用键的散列码将对象分布到不同的存储桶中，随后在该特定的存储桶中使用键的Equals方法进行查找。
良好的散列码是第一位的因素，最理想的情况是每个不同的键都有不同的散列码。Equals方法也很重要，因为散列只需要做一次，而存储桶中查找键可能需要做多次。从实际经验看，使用Hashtable时，Equals方法的消耗一般会占到一半以上。
System.Object类提供了默认的GetHashCode实现，使用对象在内存中的地址作为散列码。我们遇到过一个用Hashtable来缓存对象的例子，每次根据传递的OQL表达式构造出一个ExpressionList对象，再调用QueryCompiler的方法编译得到CompiledQuery对象。以ExpressionList对象和CompiledQuery对象作为键值对存储到Hashtable中。ExpressionList对象没有重载GetHashCode实现，其超类ArrayList也没有，这样最后用的就是System.Object类的GetHashCode实现。由于ExpressionList对象会每次构造，因此它的HashCode每次都不同，所以这个CompiledQueryCache根本就没有起到预想的作用。这个小小的疏漏带来了重大的性能问题，由于解析OQL表达式频繁发生，导致CompiledQueryCache不断增长，造成服务器内存泄漏！解决这个问题的最简单方法就是提供一个常量实现，例如让散列码为常量0。虽然这会导致所有对象汇聚到同一个存储桶中，效率不高，但至少可以解决掉内存泄漏问题。当然，最终还是会实现一个高效的GetHashCode方法的。
以上介绍这些Hashtable机理，主要是希望大家理解：如果使用Hashtable，你应该检查一下对象是否提供了适当的GetHashCode和Equals方法实现。否则，有可能出现效率不高或者与预期行为不符的情况。
2. Ado.Net
2.1 应用Ado.net的一些思考原则
1. 根据数据使用的方式来设计数据访问层
2. 缓存数据，避免不必要的操作
3. 使用服务帐户进行连接
4. 必要时申请，尽早释放
5. 关闭可关闭的资源
6. 减少往返
7. 仅返回需要的数据
8. 选择适当的事务类型
9. 使用存储过程
2.2 Connection
数据库连接是一种共享资源，并且打开和关闭的开销较大。Ado.net默认启用了连接池机制，关闭连接不会真的关闭物理连接，而只是把连接放回到连接池中。因为池中共享的连接资源始终是有限的，如果在使用连接后不尽快关闭连接，那么就有可能导致申请连接的线程被阻塞住，影响整个系统的性能表现。
2.2.1在方法中打开和关闭连接
这个原则有几层含义：
1. 主要目的是为了做到必要时申请和尽早释放
2. 不要在类的构造函数中打开连接、在析构函数中释放连接。因为这将依赖于垃圾回收，而垃圾回收只受内存影响，回收时机不定
3. 不要在方法之间传递连接，这往往导致连接保持打开的时间过长
这里强调一下在方法之间传递连接的危害：曾经在压力测试中遇到过一个测试案例，当增大用户数的时候，这个案例要比别的案例早很久就用掉连接池中的所有连接。经分析，就是因为A方法把一个打开的连接传递到了B方法，而B方法又调用了一个自行打开和关闭连接的C方法。在A方法的整个运行期间，它至少需要占用两条连接才能够成功工作，并且其中的一条连接占用时间还特别长，所以造成连接池资源紧张，影响了整个系统的可伸缩性！
2.2.2显式关闭连接
Connection对象本身在垃圾回收时可以被关闭，而依赖垃圾回收是很不好的策略。推荐使用using语句显式关闭连接，如下例：
using (SqlConnection conn = newSqlConnection(connString))
{
conn.Open();
} // Dispose is automatically called on the conn variable here
2.2.3确保连接池启用
Ado.net是为每个不同的连接串建立连接池，因此应该确保连接串不会出现与具体用户相关的信息。另外，要注意连接串是大小写敏感的。
2.2.4不要缓存连接
例如，把连接缓存到Session或Application中。在启用连接池的情况下，这种做法没有任何意义。
2.3 Command
2.3.1使用ExecuteScalar和ExecuteNonQuery
如果想返回像Count(*)、Sum(Price)或Avg(Quantity)那样的单值，可以使用ExecuteScalar方法。ExecuteScalar返回第一行第一列的值，将结果集作为标量值返回。因为单独一步就能完成，所以ExecuteScalar不仅简化了代码，还提高了性能。
使用不返回行的SQL语句时，例如修改数据（INSERT、UPDATE或DELETE）或仅返回输出参数或返回值，请使用ExecuteNonQuery。这避免了用于创建空DataReader的任何不必要处理。
2.3.2使用Prepare
当需要重复执行同一SQL语句多次，可考虑使用Prepare方法提升效率。需要注意的是，如果只是执行一次或两次，则完全没有必要。例如：
cmd.CommandText = "insert into Table1( Col1, Col2 ) values ( @val1, @val2 )";
cmd.Parameters.Add( "@val1",SqlDbType.Int, 4, "Col1" );
cms.Parameters.Add( "@val2",SqlDbType.NChar, 50, "Col2");
cmd.Parameters[0].Value = 1;
cmd.Parameters[1].Value = "XXX";
cmd.Prepare();
cmd.ExecuteNonQuery();
cmd.Parameters[0].Value = 2;
cmd.Parameters[1].Value = "YYY";
cmd.ExecuteNonQuery();
cmd.Parameters[0].Value = 3;
cmd.Parameters[1].Value = "ZZZ";
cmd.ExecuteNonQuery();
2.3.3使用绑定变量 ★
SQL语句需要先被编译成执行计划，然后再执行。如果使用绑定变量的方式，那么这个执行计划就可以被后续执行的SQL语句所复用。而如果直接把参数合并到了SQL语句中，由于参数值千变万化，执行计划就难以被复用了。例如上面Prepare一节给出的示例，如果把参数值直接写到insert语句中，那么上面的四次调用将需要编译四次执行计划。
为避免这种情况造成性能损失，要求一律使用绑定变量方式。
2.4 DataReader
DataReader最适合于访问只读的单向数据集。与DataSet不同，数据集并不全部在内存中，而是随不断发出的read请求，一旦发现数据缓冲区中的数据均被读取，则从数据源传输一个数据缓冲区大小的数据块过来。另外，DataReader保持连接，DataSet则与连接断开。
2.4.1显式关闭DataReader
与连接类似，也需要显式关闭DataReader。另外，如果与DataReader关联的Connection仅为DataReader服务的话，可考虑使用Command对象的ExecuteReader(CommandBehavior.CloseConnection)方式。这可以保证当DataReader关闭时，同时自动关闭Connection。
2.4.2用索引号访问代替名称索引号访问属性
从Row中访问某列属性，使用索引号的方式比使用名称方式有细微提高。如果会被频繁调用，例如在循环中，那么可考虑此类优化。示例如下：
cmd.CommandText = "select Col1, Col2from Table1" ;
SqlDataReader dr = cmd.ExecuteReader();
int col1 = dr.GetOrdinal("Col1");
int col2 = dr.GetOrdinal("Col2");
while (dr.Read())
{
Console.WriteLine( dr[col1] + "_" + dr[col2]);
}
2.4.3使用类型化方法访问属性
从Row中访问某列属性，用GetString、GetInt32这种显式指明类型的方法，其效率较通用的GetValue方法有细微提高，因为不需要做类型转换。
2.4.4使用多数据集
部分场景可以考虑一次返回多数据集来降低网络交互次数，提升效率。示例如下：
cmd.CommandText ="StoredProcedureName"; //The stored procedure returns multiple result sets.
SqlDataReader dr = cmd.ExecuteReader();
while (dr.read())
// read first result set
dr.NextResult();
while (dr.read())
//
2.5 DataSet
2.5.1利用索引加快查找行的效率
如果需要反复查找行，建议增加索引。有两种方式：
1. 设置DataTable的PrimaryKey
适用于按PrimaryKey查找行的情况。注意此时应调用DataTable.Rows.Find方法，一般惯用的Select方法不能利用索引。
2. 使用DataView
适用于按Non-PrimaryKey查找行的情况。可为DataTable创建一个DataView，并通过SortOrder参数指示建立索引。此后使用Find或FindRows查找行。
2007-1-7周计划
工作上，上周末刚被调到另一个项目组救火，估计这周工作轻松不了，业余时间的学习计划也就订灵活点，复习一下数据结构和算法方面的知识，每种结构写一个Demo：
线性表
数组
矩阵
特殊矩阵
稀疏矩阵
堆栈
队列
跳表和散列
树
聊聊封装、继承
在C++中封装的概念是把一个对象的外观接口同实际工作方式（实现）分离开来，但是C++的封装是不完全的，编译器必须知道一个对象的所有部分的声明，以便创建和管理它。我们可以想象一种只需声明一个对象的公共接口部分的编程语言，而将私有的实现部分隐藏起来。C + +在编译期间要尽可能多地做静态类型检查。这意味着尽早捕获错误，也意味着程序具有更高的效率。然而这对私有的实现部分来说带来两个影响：一是即使程序员不能轻易地访问实现部分，但他可以看到它；二是造成一些不必要的重复编译。
然而C++并没有将这个原则应用到二进制层次上，这是因为C++的类既是描述了一个接口同时也描述了实现的过程,示例如下：
class CMyString
{
private:
const int m_cch;
char *m_psz;
public:
CMyString(const char *psz);
~CMyString();
intLength() const;
intIndex(const char *psz) const;
}
CMyStirng对外过多的暴露了内存布局实现的细节，这些信息过度的依赖于这些成员变量的大小和顺序，从而导致了客户过度依赖于可执行代码之间的二进制耦合关系，这样的接口不利于跨语言跨平台的软件开发和移植。
1.1.1 Handle-Body模式
解决这个问题的技术有一种叫句柄类（ handle classes）。有关实现的任何东西都消失了，只剩一个单一的指针“m_pThis”。该指针指向一个结构，该结构的定义与其所有的成员函数的定义都出现在实现文件中。这样，只要接口部分不改变，头文件就不需变动。而实现部分可以按需要任意更动，完成后只要对实现文件进行重新编译，然后再连接到项目中。
下面是这项技术的简单例子。头文件中只包含公共的接口和一个简单的没有完全指定的类指针。
class CMyStringHandle
{
private:
class CMyString；
CMyString *m_pThis;
public:
CMyStringHandle (const char *psz);
~CMyStringHandle ();
intLength() const;
intIndex(const char *psz) const;
}；
CMyStringHandle:: CMyStringHandle(constchar *psz)
:m_pThis(new CMyString(psz));
{
}
CMyStringHandle::~ CMyStringHandle()
{
delete m_pThis;
}
int CMyStringHandle::Length()
{
return m_pThis->Length();
}
int CMyStringHandle::Index(const char *psz)
{
return m_pThis->Index(psz);
}
这是所有客户程序员都能看到的。
class CMyString；
是一个没有完全指定的类型说明或类声明（一个类的定义包含类的主体）。它告诉编译器，CMyString是一个结构的名字，但没有提供有关该结构的任何东西。这对产生一个指向结构的指针来说已经足够了。但我们在提供一个结构的主体部分之前不能创建一个对象。在这种技术里，包含具体实现的结构主体被隐藏在实现文件中。
在设计模式中，这就叫做Handle-Body 模式，Handle-Body只含有一个实体指针，服务的数据成员永远被封闭在服务系统中。
Handle-Body的布局结构永远不会随着实现类数据成员的加入或者删除或者修改而导致Handle-Body的修改，即Handle-Body协议不依赖于C++实现类的任何细节。这就有效的对用户的编译器隐藏了这些细节，用户在使用对这项技术时候，Handle-Body 接口成了它唯一的入口。
然而Handle-Body模式也有自己的弱点：
1、接口类必须把每一个方法调用显示的传递给实现类，这在一个只有一个构造和一个析构的类来说显然不构成负担，但是如果一个庞大的类库，它有上百上千个方法时候，光是编写这些方法传递就有可能非常冗长，这也增加了出错的可能性。
2、对于关注于性能的应用每一个方法都得有两层的函数调用，嵌套的开销也不理想
3、由于句柄的存在，依然存在编译连接器兼容性问题。
1.1.2 抽象接口
使用了“接口与实现的分离”技术的 Handle-Body 解决了编译器/链接器的大部分问题，而C++面向对象编程中的抽象接口同样是运用了“接口与实现分离”的思想，而采用抽象接口对于解决这类问题是一个极其完美的解决方案。
1、抽象接口的语言描述：
class IMyString
{
virtual int Length() const = 0;//这表示是一个纯虚函数，具有纯虚函数的接口
virtual int Index(const char*psz) const = 0;
}；
2、抽象接口的内存结构：
抽象接口采用虚函数表来调用成员方法。
3、 抽象接口的实现代码：
接口：
class IMyString
实现：
class CMyString：public IMyString
{
private:
const int m_cch;
char *m_psz;
public:
CMyString(const char *psz);
virtual ~CMyString();
int Length() const;
int Index(const char *psz) const;
}
从上面采用抽象接口的实例来看，抽象接口解决了Handle-Body所遗留下来的全部缺陷。
抽象接口的一个典型应用：
抽象工厂（AbstractFactroy）
1.2 多继承与菱形缺陷、this跳转等
多重继承是C++语言独有的继承方式，其它几乎所有语言都秉承了单一继承的思想。这是因为多重继承致命的缺陷导致的：
1.2.1 菱形缺陷
当继承基类时，在派生类中就获得了基类所有的数据成员副本。假如类B 从A1和A2两个类多重继承而来，这样B类就包含A1、A2类的数据成员副本。
考虑如果A1、A2都从某基类派生，该基类称为Base，现在继承关系将出现菱形继承关系。
class Base{…… }；
class A1 :public Base {… … }；
class A2 :public Base {… … }；
class B :public A1,public A2 {… … }；
那么A1、A2都具有Base的副本。这样B就包含了Base的两个副本，副本发生了重叠，不但增加了存储空间，同时也引入了二义性。这就是菱形缺陷，菱形缺陷的两个缺陷：
1、子对象重叠
2、向上映射的二义性。
菱形缺陷的其中一种解决办法是使用虚拟继承。
在C++世界里最广泛的使用虚拟继承解决菱形缺陷的应用便是标准C++的输入/输出iostream；
1.2.2 多重接口与方法名冲突问题（Siamese twins）
对继承而来的虚函数改写很容易，但是如果是在改写一个“在两个基类都有相同原型”的虚函数情况就不那么容易了。
提出问题：
假设汽车最大速度的接口为ICar，潜艇最大速度的接口为 IBoat，有一个两栖类的交通工具它可以奔跑在马路上，也可以航行在大海中，那么它就同时拥有ICar、IBoat两种交通工具的最大速度特性，我们定义它的接口为ICarBoat；
class ICar
{
virtual int GetMaxSpeed（）= 0；
}；
class IBoat
{
virtual int GetMaxSpeed（）= 0；
}；
我们先对ICarBoat的接口做一个尝试：
class CCarBoat
{
virtual int GetMaxSpeed（）；//既完成ICar的GetMaxSpeed（）接口方法又 //完成IBoat的接口方法？显然不能够
};
解决问题：
显然上面这个尝试根本就无法成功，只用一个实现方法，怎么能够求出这个ICarBoat交通工具奔跑在马路上的最高时速，同时也能够求出航行在大海上的最大航行速度呢。
上面这一问题矛盾就在一一个方法，却需要两个答案。看来ICarBoat要返回两个答案就必须有两个方法了，我们假设一个方法是求在陆地上奔跑的速度，名称为GetCarMaxSpeed（）；另一个方法是求在大海上航行的最大速度，名称为GetBoatMaxSpeed（）；那这两个方法又怎么和GetMaxSpeed（）接口方法联系起来呢；
幸运的是，我们找到了解决办法，而且解决办法有很多种，下面介绍一下继承法。
class IXCar :public ICar
{
virtual int GetMaxSpeed（）
{
GetCarMaxSpeed();
}
virtual int GetCarMaxSpeed（） = 0;
}；
class IXBoat:public IBoat
{
virtual int GetMaxSpeed（）
{
GetBoatMaxSpeed();
}
virtual int GetBoatMaxSpeed（） = 0;
}；
classCCarBoat: public IXCar , public IXBoat
{
virtual int GetCarMaxSpeed（）
{
… …
}
virtual int GetBoatMaxSpeed（）
{
… …
}
};
1.2.3 this跳转
this跳转是指的“对象同一性”问题。
在单一继承的世界内，无论继承关系怎么复杂，针对于同一对象，无论它的子类或者父类的this指针永远相等。即如果 B从A继承，那么对于一个已经实例化B类的对象 bObject，永远有（B*）&bObject ==(A*)&bObject 成立。
但是在多继承的世界内，上面的等式就不能恒成立，对象的同一性受到了挑战。
特别的是，在多继承世界内如果菱形关系存在情况下，如果对于已经实例化B类的对象bObject; （Base*）（A1*）&bObject!= （Base*）（A2*）&bObject 成立，当这种事情发生的时候我们就只能特殊处理了。这种情况在COM应用中处处都会发生。
1.3 C++多态的两种多态形式和区别
C++有两种多态多态形式：
1、编译时刻多态，编译时刻多态依靠函数重载或者模板实现
2、运行时刻多态。运行时刻多态依靠需函数虚接口实现
我们C++语言来描述这种继承关系：
{
virtual int Length() const = 0;//这表示是一个纯虚函数，具有纯虚函数的接口
virtual int Index(const char*psz) const = 0;
}；
二叉树
准备在接下来的一周复习一下树的常用应用（优先队列、二叉搜索树、AVL树、红-黑树、B-树等）。再花一周学习一下图。然后就是算法了。
计划订得不具体，大概是因为业余时间，不确定因素太多，如（工作、自己懒惰等等），但自己有个习惯，每天睡前会把当天所做的事情用十多个字记在台历的日期旁边的空白处。看着密密麻麻的小台历，比起如今流行的每年一次的“阅之有字，言之无物”的工作总结，心里透着一种踏实。真希望每天一个目标，睡前问问自己“否达到了自己定下的目标”。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/sunchaohuang/archive/2009/04/03/4046801.aspx
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- .NET 性能优化方法总结
- .NET 性能优化方法总结
- .NET 性能优化方法总结==转
- .NET 性能优化方法总结
- [转].NET 性能优化方法总结
- .NET 性能优化方法总结
- .NET 性能优化方法总结(转)
- .NET 性能优化方法总结
- .NET 性能优化方法总结
- .NET 性能优化方法总结
- .NET 性能优化方法总结==转
- Unity+NGUI性能优化方法总结
- .NET性能优化方面的总结
- 【转帖】 整理：.NET 性能优化方法总结
- HBase性能优化方法总结(转)
- HBase性能优化方法总结
- HBase性能优化方法总结
- HBASE性能优化方法总结
- HBase应用设计性能优化方法总结
- HBase性能优化方法总结（二）：写表操作