Net性能优化总结

NET性能优化方面的总结1.C#语言方面1.1垃圾回收垃圾回收解放了手工管理对象的工作，提高了程序的健壮性，但副作用就是程序代码可能对于对象创建变得随意。1.1.1避免不必要的对象创建由于垃圾回收的代价较高，所以C#程序开发要遵循的一个基本原则就是避免不必要的对象创建。以下列举一些常见的情形。避免循环创建对象★如果对象并不会随每次循环而改变状态，那么在循环中反复创建对象将带来性能损耗。高效的做法是将对象提到循环外面创建。在需要逻辑分支中创建对象如果对象只在某些逻辑分支中才被用到，那么应只在该逻辑分支中创建对象。使用常量避免创建对象程序中不应出现如newDecimal(0)之类的代码，这会导致小对象频繁创建及回收，正确的做法是使用Decimal.Zero常量。我们有设计自己的类时，也可以学习这个设计手法，应用到类似的场景中。使用StringBuilder做字符串连接1.1.2不要使用空析构函数★如果类包含析构函数，由创建对象时会在Finalize队列中添加对象的引用，以保证当对象无法可达时，仍然可以调用到Finalize方法。垃圾回收器在运行期间，会启动一个低优先级的线程处理该队列。相比之下，没有析构函数的对象就没有这些消耗。如果析构函数为空，这个消耗就毫无意义，只会导致性能降低！因此，不要使用空的析构函数。在实际情况中，许多曾在析构函数中包含处理代码，但后来因为种种原因被注释掉或者删除掉了，只留下一个空壳，此时应注意把析构函数本身注释掉或删除掉。1.1.3实现IDisposable接口垃圾回收事实上只支持托管内在的回收，对于其他的非托管资源，例如WindowGDI句柄或数据库连接，在析构函数中释放这些资源有很大问题。原因是垃圾回收依赖于内在紧张的情况，虽然数据库连接可能已濒临耗尽，但如果内存还很充足的话，垃圾回收是不会运行的。C#的IDisposable接口是一种显式释放资源的机制。通过提供using语句，还简化了使用方式(编译器自动生成try...finally块，并在finally块中调用Dispose方法)。对于申请非托管资源对象，应为其实现IDisposable接口，以保证资源一旦超出using语句范围，即得到及时释放。这对于构造健壮且性能优良的程序非常有意义！为防止对象的Dispose方法不被调用的情况发生，一般还要提供析构函数，两者调用一个处理资源释放的公共方法。同时，Dispose方法应调用System.GC.SuppressFinalize(this)，告诉垃圾回收器无需再处理Finalize方法了。String操作1.2.1使用StringBuilder做字符串连接String是不变类，使用+操作连接字符串将会导致创建一个新的字符串。如果字符串连接次数不是固定的，例如在一个循环中，则应该使用StringBuilder类来做字符串连接工作。因为StringBuilder内部有一个StringBuffer，连接操作不会每次分配新的字符串空间。只有当连接后的字符串超出Buffer大小时，才会申请新的Buffer空间。典型代码如下：StringBuildersb=newStringBuilder(256);Ifor(inti=0;i<Results.Count;i++)日{Isb.Append(Results[i]);}如果连接次数是固定的并且只有几次，此时应该直接用+号连接，保持程序简洁易读。实际上，编译器已经做了优化，会依据加号次数调用不同参数个数的String.Concat方法。例如：Stringstr=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#在编译时会将程序集中声明的所有字符串常量放到保留池中(internpool)，相同常量不会重复分配。1.3多线程1.3.1线程同步线程同步是编写多线程程序需要首先考虑问题。C#为同步提供了Monitor.Mutex、AutoResetEvent和ManualResetEvent对象来分别包装Win32的临界区、互斥对象和事件对象这几种基础的同步机制。C#还提供了一个lock语句，方便使用，编译器会自动生成适当的Monitor.Enter和Monitor.Exit调用。同步粒度同步粒度可以是整个方法，也可以是方法中某一段代码。为方法指定MethodImplOptions.Synchronized属性将标记对整个方法同步。例如：[Methodlmpl(MethodlmplOptions.Synchronized)]publicstaticSerialManagerGetInstance()|日{Iif(instance==null)申{Iinstance=newSerialManager();}Ireturninstance;}通常情况下，应减小同步的范围，使系统获得更好的性能。简单将整个方法标记为同步不是一个好主意，除非能确定方法中的每个代码都需要受同步保护。同步策略使用lock进行同步，同步对象可以选择Type、this或为同步目的专门构造的成员变量。避免锁定Type*锁定Type对象会影响同一进程中所有AppDomain该类型的所有实例，这不仅可能导致严重的性能问题，还可能导致一些无法预期的行为。这是一个很不好的习惯。即便对于一个只包含static方法的类型，也应额外构造一个static的成员变量，让此成员变量作为锁定对象。避免锁定this锁定this会影响该实例的所有方法。假设对象obj有A和B两个方法，其中A方法使用lock(this)对方法中的某段代码设置同步保护。现在，因为某种原因，B方法也开始使用lock(this)来设置同步保护了，并且可能为了完全不同的目的。这样，A方法就被干扰了，其行为可能无法预知。所以，作为一种良好的习惯，建议避免使用lock(this)这种方式。使用为同步目的专门构造的成员变量这是推荐的做法。方式就是new一个object对象，该对象仅仅用于同步目的。如果有多个方法都需要同步，并且有不同的目的，那么就可以为些分别建立几个同步成员变量。C#为各种集合类型提供了两种方便的同步机制：Synchronized包装器和SyncRoot属性。//CreatesandinitializesanewArrayListArrayListmyAL=newArrayList();myAL.Add("The");myAL.Add("quick");myAL.Add("brown");myAL.Add("fox");//CreatesasynchronizedwrapperaroundtheArrayListArrayListmySyncdAL=ArrayList.Synchronized(myAL);调用Synchronized方法会返回一个可保证所有操作都是线程安全的相同集合对象。考虑mySyncdAL[0]=mySyncdAL[0]+"test"这一语句，读和写一共要用到两个锁。一般讲，效率不高。推荐使用SyncRoot属性，可以做比较精细的控制。使用ThreadStatic替代NameDataSlot★存取NameDataSlot的Thread.GetData和Thread.SetData方法需要线程同步，涉及两个锁:一个是LocalDataStore.SetData方法需要在AppDomain一级加锁，另一个是ThreadNative.GetDomainLocalStore方法需要在Process一级加锁。如果一些底层的基础服务使用了NameDataSlot，将导致系统出现严重的伸缩性问题。规避这个问题的方法是使用ThreadStatic变量。示例如下：publicsealedclassInvokeContextI日{I[ThreadStatic]IprivatestaticInvokeContextcurrent;IprivateHashtablemaps=newHashtable();}1.3.3多线程编程技巧使用DoubleCheck技术创建对象internalIDictionaryKeyTable日{Iget勺{I if(this._keyTable==null)勺 {lock(base._lock)勺{I if(this._keyTable==null)勺 {this._keyTable=newHashtable();}returnthis._keyTable;}创建单例对象是很常见的一种编程情况。一般在lock语句后就会直接创建对象了，但这不够安全。因为在lock锁定对象之前，可能已经有多个线程进入到了第一个if语句中。如果不加第二个if语句，则单例对象会被重复创建，新的实例替代掉旧的实例。如果单例对象中已有数据不允许被破坏或者别的什么原因，则应考虑使用DoubleCheck技术。1.4类型系统1.4.1避免无意义的变量初始化动作CLR保证所有对象在访问前已初始化，其做法是将分配的内存清零。因此，不需要将变量重新初始化为0、false或null。需要注意的是：方法中的局部变量不是从堆而是从栈上分配，所以C#不会做清零工作。如果使用了未赋值的局部变量，编译期间即会报警。不要因为有这个印象而对所有类的成员变量也做赋值动作，两者的机理完全不同！ValueType和ReferenceType以引用方式传递值类型参数值类型从调用栈分配，引用类型从托管堆分配。当值类型用作方法参数时，默认会进行参数值复制，这抵消了值类型分配效率上的优势。作为一项基本技巧，以引用方式传递值类型参数可以提高性能。为ValueType提供Equals方法.net默认实现的ValueType.Equals方法使用了反射技术，依靠反射来获得所有成员变量值做比较，这个效率极低。如果我们编写的值对象其Equals方法要被用到(例如将值对象放到HashTable中)，那么就应该重载Equals方法。publicstructRectangle日｛I public doubleLength;I public doubleBreadth;I public overrideboolEquals (objectob)勺｛I if(obisRectangle)I returnEquels((Rectangle)ob))I elseI returnfalse;｝IprivateboolEquals(Rectanglerect)勺｛Ireturnthis.Length==rect.Length&&this.Breadth==rect.Breach;｝C#可以在值类型和引用类型之间自动转换，方法是装箱和拆箱。装箱需要从堆上分配对象并拷贝值，有一定性能消耗。如果这一过程发生在循环中或是作为底层方法被频繁调用，则应该警惕累计的效应。一种经常的情形出现在使用集合类型时。例如：ArrayListal=newArrayList();for(inti=0;i<1000;i++)日{Ial.Add(i);//ImplicitlyboxedbecauseAdd()takesanobject}intf=(int)al[0]; //Theelementisunboxed1.5异常处理异常也是现代语言的典型特征。与传统检查错误码的方式相比，异常是强制性的(不依赖于是否忘记了编写检查错误码的代码)、强类型的、并带有丰富的异常信息(例如调用栈)。1.5.1不要吃掉异常★关于异常处理的最重要原则就是：不要吃掉异常。这个问题与性能无关，但对于编写健壮和易于排错的程序非常重要。这个原则换一种说法，就是不要捕获那些你不能处理的异常。吃掉异常是极不好的习惯，因为你消除了解决问题的线索。一旦出现错误，定位问题将非常困难。除了这种完全吃掉异常的方式外，只将异常信息写入日志文件但并不做更多处理的做法也同样不妥。1.5.2不要吃掉异常信息★有些代码虽然抛出了异常，但却把异常信息吃掉了。为异常披露详尽的信息是程序员的职责所在。如果不能在保留原始异常信息含义的前提下附加更丰富和更人性化的内容，那么让原始的异常信息直接展示也要强得多。千万不要吃掉异常。1.5.3避免不必要的抛出异常抛出异常和捕获异常属于消耗比较大的操作，在可能的情况下，应通过完善程序逻辑避免抛出不必要不必要的异常。与此相关的一个倾向是利用异常来控制处理逻辑。尽管对于极少数的情况，这可能获得更为优雅的解决方案，但通常而言应该避免。1.5.4避免不必要的重新抛出异常如果是为了包装异常的目的(即加入更多信息后包装成新异常)，那么是合理的。但是有不少代码，捕获异常没有做任何处理就再次抛出，这将无谓地增加一次捕获异常和抛出异常的消耗，对性能有伤害。1.6反射反射是一项很基础的技术，它将编译期间的静态绑定转换为延迟到运行期间的动态绑定。在很多场景下(特别是类框架的设计)，可以获得灵活易于扩展的架构。但带来的问题是与静态绑定相比，动态绑定会对性能造成较大的伤害。1.6.1反射分类typecomparison:类型判断，主要包括is和typeof两个操作符及对象实例上的GetType调用。这是最轻型的消耗，可以无需考虑优化问题。注意typeof运算符比对象实例上的GetType方法要快，只要可能则优先使用typeof运算符。memberenumeration:成员枚举，用于访问反射相关的元数据信息，例如Assembly.GetModule、Module.GetType、Type对象上的IsInterface、IsPublic、GetMethod、GetMethods、GetProperty、GetProperties、GetConstructor调用等。尽管元数据都会被CLR缓存，但部分方法的调用消耗仍非常大，不过这类方法调用频度不会很高，所以总体看性能损失程度中等。memberinvocation:成员调用，包括动态创建对象及动态调用对象方法，主要有Activator.CreateInstance、Type.InvokeMember等。1.6.2动态创建对象C#主要支持5种动态创建对象的方式：Type.InvokeMemberContructorInfo.InvokeActivator.CreateInstance(Type)Activator.CreateInstance(assemblyName,typeName)Assembly.CreateInstance(typeName)最快的是方式3，与DirectCreate的差异在一个数量级之内，约慢7倍的水平。其他方式，至少在40倍以上，最慢的是方式4，要慢三个数量级。1.6.3动态方法调用方法调用分为编译期的早期绑定和运行期的动态绑定两种，称为Early-BoundInvocation和Late-BoundInvocation。Early-BoundInvocation可细分为Direct-call、Interface-call和Delegate-calloLate-BoundInvocation主要有Type.InvokeMember和MethodBase.Invoke，还可以通过使用LCG(LightweightCodeGeneration)技术生成IL代码来实现动态调用。从测试结果看，相比DirectCall,Type.InvokeMember要接近慢三个数量级；MethodBase.Invoke虽然比Type.InvokeMember要快三倍，但比DirectCall仍慢270倍左右。可见动态方法调用的性能是非常低下的。我们的建议是：除非要满足特定的需求，否则不要使用！1.6.4推荐的使用原则模式如果可能，则避免使用反射和动态绑定使用接口调用方式将动态绑定改造为早期绑定使用Activator.CreateInstance(Type)方式动态创建对象使用typeof操作符代替GetType调用反模式1.在已获得Type的情况下，却使用Assembly.CreateInstance(type.FullName)1.7基本代码技巧这里描述一些应用场景下，可以提高性能的基本代码技巧。对处于关键路径的代码，进行这类的优化还是很有意义的。普通代码可以不做要求，但养成一种好的习惯也是有意义的。1.7.1循环写法可以把循环的判断条件用局部变量记录下来。局部变量往往被编译器优化为直接使用寄存器，相对于普通从堆或栈中分配的变量速度快。如果访问的是复杂计算属性的话，提升效果将更明显。for(inti=0,j=collection.GetIndexOf(item);i<j;i++)需要说明的是：这种写法对于CLR集合类的Count属性没有意义，原因是编译器已经按这种方式做了特别的优化。1.7.2拼装字符串拼装好之后再删除是很低效的写法。有些方法其循环长度在大部分情况下为1，这种写法的低效就更为明显了：publicstaticstringToString(MetadataKeyentityKey)日｛Istringstr="”;I object[]vals=entityKey.values;I for(inti=0;i<vals.Length;i++)自{Istr+=","+vals[i].ToString();}I returnstr==""?"":str.Remove(0,1);}推荐下面的写法：if(str.Length==0)str=vals[i].ToString();elsestr+=","+vals[i].ToString();其实这种写法非常自然，而且效率很高，完全不需要用个Remove方法绕来绕去。1.7.3避免两次检索集合元素获取集合元素时，有时需要检查元素是否存在。通常的做法是先调用ContainsKey(或Contains)方法，然后再获取集合元素。这种写法非常符合逻辑。但如果考虑效率，可以先直接获取对象，然后判断对象是否为null来确定元素是否存在。对于Hashtable，这可以节省一次GetHashCode调用和n次Equals比较。如下面的示例：publicIDataGetItemByID(Guidid)日{IIDatadata1=null;Iif(this.idTable.ContainsKey(id.ToString())自{Idata1=this.idTable[id.ToString()]asIData;}Ireturndata1;}其实完全可用一行代码完成：returnthis.idTable[id]asIData;1.7.4避免两次类型转换考虑如下示例，其中包含了两处类型转换：if(objisSomeType)|日{ISomeTypest=(SomeType)obj;Ist.SomeTypeMethod();}效率更高的做法如下：SomeTy