Java程序的性能優化StringBuffer與Vector

2019-11-18 13:14:53

字體：大中小

來源：轉載

供稿：網友

　　java使得復雜應用的開發變得相對簡單。毫無疑問，它的這種易用性對Java的大范圍流行功不可沒。然而，這種易用性實際上是一把雙刃劍。一個設計良好的Java程序，性能表現往往不如一個同樣設計良好的C++程序。在Java程序中，性能問題的大部分原因并不在于Java語言，而是在于程序本身。養成好的代碼編寫習慣非常重要，比如正確地、巧妙地運用java.lang.String類和java.util.Vector類，它能夠顯著地提高程序的性能。下面我們就來具體地分析一下這方面的問題。
　　
　　在java中，使用最頻繁、同時也是濫用最多的一個類或許就是java.lang.String，它也是導致代碼性能低下最主要的原因之一。請考慮下面這個例子：
　　
　　String s1 = "Testing String";
　　String s2 = "Concatenation Performance";
　　String s3 = s1 + " " + s2;
　　
　　幾乎所有的Java程序員都知道上面的代碼效率不高。那么，我們應該怎么辦呢？也許可以試試下面這種代碼：
　　
　　StringBuffer s = new StringBuffer();
　　s.append("Testing String");
　　s.append(" ");
　　s.append("Concatenation Performance");
　　String s3 = s.toString();
　　
　　這些代碼會比第一個代碼片段效率更高嗎？答案是否定的。這里的代碼實際上正是編譯器編譯第一個代碼片段之后的結果。既然與使用多個獨立的String對象相比，StringBuffer并沒有使代碼有任何效率上的提高，那為什么有那么多的Java書籍批評第一種方法、推薦使用第二種方法？
　　
　　第二個代碼片段用到了StringBuffer類（編譯器在第一個片段中也將使用StringBuffer類），我們來分析一下StringBuffer類的默認構造函數，下面是它的代碼：
　　
　　public StringBuffer() { this(16); }
　　
　　默認構造函數預設了16個字符的緩存容量?，F在我們再來看看StringBuffer類的append()方法：
　　
　　public synchronized StringBuffer append(String str) {
　　if (str == null) {
　　str = String.valueOf(str);
　　}
　　int len = str.length();
　　int newcount = count + len;
　　if (newcount > value.length) eXPandCapacity(newcount);
　　str.getChars(0, len, value, count);
　　count = newcount; return this;
　　}
　　
　　append()方法首先計算字符串追加完成后的總長度，假如這個總長度大于StringBuffer的存儲能力，append()方法調用私有的expandCapacity()方法。expandCapacity()方法在每次被調用時使StringBuffer存儲能力加倍，并把現有的字符數組內容復制到新的存儲空間。
　　
　　在第二個代碼片段中（以及在第一個代碼片段的編譯結果中），由于字符串追加操作的最后結果是“Testing String Concatenation Performance”，它有40個字符，StringBuffer的存儲能力必須擴展兩次，從而導致了兩次代價昂貴的復制操作。因此，我們至少有一點可以做得比編譯器更好，這就是分配一個初始存儲容量大于或者等于40個字符的StringBuffer，如下所示：
　　
　　StringBuffer s = new StringBuffer(45);
　　s.append("Testing String");
　　s.append(" ");
　　s.append("Concatenation Performance");
　　String s3 = s.toString();
　　
　　再考慮下面這個例子：
　　
　　String s = "";
　　int sum = 0;
　　for(int I=1; I<10; I++) {
　　sum += I;
　　s = s + "+" +I ;
　　}
　　s = s + "=" + sum;
　　
　　分析一下為何前面的代碼比下面的代碼效率低：
　　
　　StringBuffer sb = new StringBuffer();
　　int sum = 0;
　　for(int I=1;
　　I<10; I++){
　　sum + = I;
　　sb.append(I).append("+");
　　}
　　String s = sb.append("=").append(sum).toString();
　　
　　原因就在于每個s = s + "+" + I操作都要創建并拆除一個StringBuffer對象以及一個String對象。這完全是一種浪費，而在第二個例子中我們避免了這種情況。
　　
　　我們再來看看另外一個常用的Java類——java.util.Vector。簡單地說，一個Vector就是一個java.lang.Object實例的數組。Vector與數組相似，它的元素可以通過整數形式的索引訪問。但是，Vector類型的對象在創建之后，對象的大小能夠根據元素的增加或者刪除而擴展、縮小。請考慮下面這個向Vector加入元素的例子：
　　
　　Object obj = new Object();
　　Vector v = new Vector(100000);
　　for(int I=0;
　　I<100000; I++) { v.add(0,obj); }
　　
　　除非有絕對充足的理由要求每次都把新元素插入到Vector的前面，否則上面的代碼對性能不利。在默認構造函數中，Vector的初始存儲能力是10個元素，假如新元素加入時存儲能力不足，則以后存儲能力每次加倍。Vector類就象StringBuffer類一樣，每次擴展存儲能力時，所有現有的元素都要復制到新的存儲空間之中。下面的代碼片段要比前面的例子快幾個數量級：
　　
　　Object obj = new Object();
　　Vector v = new Vector(100000);
　　for(int I=0; I<100000; I++) { v.add(obj); }
　　
　　同樣的規則也適用于Vector類的remove()方法。由于Vector中各個元素之間不能含有“空隙”，刪除除最后一個元素之外的任意其他元素都導致被刪除元素之后的元素向前移動。也就是說，從Vector刪除最后一個元素要比刪除第一個元素“開銷”低好幾倍。
　　
　　假設要從前面的Vector刪除所有元素，我們可以使用這種代碼：
　　
　　for(int I=0; I<100000; I++){ v.remove(0); }
　　
　　但是，與下面的代碼相比，前面的代碼要慢幾個數量級：
　　
　　for(int I=0; I<100000; I++){ v.remove(v.size()-1); }
　　
　　從Vector類型的對象v刪除所有元素的最好方法是：
　　
　　v.removeAllElements();
　　
　　假設Vector類型的對象v包含字符串“Hello”?？紤]下面的代碼，它要從這個Vector中刪除“Hello”字符串：
　　
　　String s = "Hello"; int i = v.indexOf(s); if(I != -1) v.remove(s);
　　
　　這些代碼看起來沒什么錯誤，但它同樣對性能不利。在這段代碼中，indexOf()方法對v進行順序搜索尋找字符串“Hello”，remove(s)方法也要進行同樣的順序搜索。改進之后的版本是：
　　
　　String s = "Hello"; int i = v.indexOf(s); if(I != -1) v.remove(i);
　　
　　這個版本中我們直接在remove()方法中給出待刪除元素的精確索引位置，從而避免了第二次搜索。一個更好的版本是：
　　
　　String s = "Hello"; v.remove(s);
　　
　　最后，我們再來看一個有關Vector類的代碼片段：
　　
　　for(int I=0; I
　　
　　假如v包含100,000個元素，這個代碼片段將調用v.size()方法100,000次。雖然size方法是一個簡單的方法，但它仍然需要一次方法調用的開銷，至少JVM需要為它配置以及清除堆棧環境。在這里，for循環內部的代碼不會以任何方式修改Vector類型對象v的大小，因此上面的代碼最好改寫成下面這種形式：
　　
　　int size = v.size(); for(int I=0; I
　　
　　雖然這是一個簡單的改動，但它仍然贏得了性能。究竟，每一個CPU周期都是寶貴的。
　　
　　拙劣的代碼編寫方式導致代碼性能下降。但是，正如本文例子所顯示的，我們只要采取一些簡單的措施就能夠顯著地改善代碼性能。

上一篇：事務：在控制之中嗎？--附一些高深內容

下一篇：桌面系統的第二次戰役 -- 難解難分