接口设计对软件性能的影响

《接口设计对软件性能的影响》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、性能方面的问题有好多种。最容易修正的一种是，在执行一项计算任务时使用了一个性能不好的算法，例如，在对数目很多的数据进行排序时采用了起泡算法，每次使用时对一个经常使用的数据项进行计算而不是将它保存起来，这些问题一般我们都能很容易发现，而且一旦发现后，都能很方便地进行改正。然而，许多Java程序性能方面的问题都是是由一些比较深奥的、不容易修改的代码━━程序组件的接口设计引起的。　　大多数的程序都是由内部人员开发的或从外部购买的组件"组装"而成的。即使软件不完全依赖于原有的组件，面向对象的设计过程也使得应用程序在开发时采用组

2、件形式，因为这样可以简化程序的设计、开发和调试方面的工作。尽管采用组件的好处是不可否认的，我们还应该意识到组件的接口会对使用它们的程序的性能和运行状态产生重大的影响。　　也许会有读者问，接口跟性能有什么关系？一个类的接口不但定义了类可以完成的功能，而且还定义了它的对象创建行为和使用它所需要调用的方法的顺序，一个类如何定义它的构造器和方法会影响这个对象是否可以重用，是它本身的方法创建还是要求其客户创建中间对象，客户要使用这个类需要调用多少个方法。　　所有这些因素都会影响到程序的性能。Java软件性能管理方面的基本原理之一

3、是：避免创建过多的对象。这并不意味着你不能创建任何对象从而不充分利用面象对象语言带来的诸多好处，而是说在开发对性能敏感的代码时需要对对象的创建保持谨慎。对象创建的代价相当高昂，我们应该在对性能敏感的软件中尽量避免创建临时或中间对象。　　在处理字符的程序中，String类是引起对象创建的最大源。因为String类是不可变的，每当一个String类的对象被修改或构造时，都会创建一个新的对象。因此，一个具有性能意识的编程人员总是避免过多地使用String类对象。然而，尽管你在编程中尽量避免使用String对象，还是会经常发现

4、使用的组件接口必须使用String对象，因此，你不可能不使用String类对象。　　例子：表达式的匹配　　作为一个例子，可以假设你在编写一个名字为MailBot的邮件服务器。MailBot需要处理每个邮件顶部的MIME头部━━例如发送日期或者发送者的邮件地址，它将通过使用一个匹配表达式的组件处理MIME头部，以使这一处理过程会更简单一些。它把输入的字符放在一个字符缓冲区中，通过对缓冲区进行索引处理标题。由于MailBot将调用这一表达式匹配子程序来处理每一个标题，因此这个匹配子程序的性能将十分地重要。　　我们首先来看一

5、个性能十分低下的表达式匹配类的接口：　　publicclassAwfulRegExpMatcher{　　　/**创建一个给定表达式的匹配过程，它将对给定的字符串进行处理*/　　　publicAwfulRegExpMatcher(StringregExp,StringinputText);　　　/**找到针对输入文本的下一个匹配模式，如果匹配，返回匹配的文本，否则返回一个空字符*/　　　publicStringgetNextMatch();　　}即使这个类采用了一个很高效的匹配算法，大量调用它的程序的性能也不会很好。因为

6、匹配器对象是与输入文本捆绑在一起的，每次调用它时，都需要首先生成一个新的匹配器对象。由于我们的目标是减少不必要的对象创建工作，实现对匹配过程代码的重用应该是一个良好的开端。　　下面的这个类定义了匹配器的另一种可能的接口，它允许匹配器重用，但性能仍然不够好：　　publicclassBadRegExpMatcher{　　　publicBadRegExpMatcher(StringregExp);　　　/**试图针对输入文本匹配指定的表达式，如果匹配则返回匹配的文本，否则返回一个空白字符串*/　　　publicString

7、match(StringinputText);　　　/**得到下一个匹配的字符，否则返回一个空白字符*/　　　publicStringgetNextMatch();　　}避开返回的匹配子表达式等敏感的表达式匹配问题不谈，这个类的定义有什么问题吗？如果仅仅从其功能方面看，它没有任何问题，但如果从性能方面来考虑，则它存在许多问题。首先，匹配器要求其调用者创建一个String类来表示被匹配的文本。MailBot应该尽量避免生成String对象，但当它发现一个需要处理的标题时，它必须创建一个String对象供BadRegExp

8、Matcher调用：　　BadRegExpMatcherdateMatcher=newBadRegExpMatcher(...);　　　while(...){　　　　...　　　　StringheaderLine=newString(myBuffer,thisHeaderStart,　　　　　　thisHeaderEnd-this