1. 程式人生 > >保持程式碼健壯性的小技巧

保持程式碼健壯性的小技巧

■字串的開銷:字串連線運算子+看似簡單,但實際需要消耗大量系統資源。編譯器可高效地連線字串,但變數字串卻要求可觀的處理器時間。例如,假設s和t是字串變數:
System.out.println("heading" + s +"trailer" + t); 

上述語句要求新建一個StringBuffer(字串緩衝),追加自變數,然後用toString()將結果轉換回一個字串。因此,無論磁碟空間還是處理器時間,都會受到嚴重消耗。若準備追加多個字串,則可考慮直接使用一個字串緩衝——特別是能在一個迴圈裡重複利用它的時候。通過在每次迴圈裡禁止新建一個字串緩衝,可節省980單位的物件建立時間(如前所述)。利用substring()以及其他字串方法,可進一步地改善效能。如果可行,字元陣列的速度甚至能夠更快。也要注意由於同步的關係,所以StringTokenizer會造成較大的開銷。 ■同步:在JDK
直譯器中,呼叫同步方法通常會比呼叫不同步方法慢10倍。經JIT編譯器處理後,這一效能上的差距提升到50到100倍(注意前表總結的時間顯示出要慢97倍)。所以要儘可能避免使用同步方法——若不能避免,方法的同步也要比程式碼塊的同步稍快一些。 ■重複利用物件:要花很長的時間來新建一個物件(根據前表總結的時間,物件的新建時間是賦值時間的980倍,而新建一個小陣列的時間是賦值時間的3100倍)。因此,最明智的做法是儲存和更新老物件的欄位,而不是建立一個新物件。例如,不要在自己的paint()方法中新建一個Font物件。相反,應將其宣告成例項物件,再初始化一次。在這以後,可在paint()裡需要的時候隨時進行更新。參見Bentley編著的《程式設計拾貝》,p.81[15]。 ■異常:只有在不正常的情況下,才應放棄異常處理模組。什麼才叫“不正常”呢?這通常是指程式遇到了問題,而這一般是不願見到的,所以效能不再成為優先考慮的目標。進行優化時,將小的“try-catch
”塊合併到一起。由於這些塊將程式碼分割成小的、各自獨立的片斷,所以會妨礙編譯器進行優化。另一方面,若過份熱衷於刪除異常處理模組,也可能造成程式碼健壯程度的下降。 ■雜湊處理:首先,Java 1.0和1.1的標準“散列表”(Hashtable)類需要造型以及特別消耗系統資源的同步處理(570單位的賦值時間)。其次,早期的JDK庫不能自動決定最佳的表格尺寸。最後,雜湊函式應針對實際使用項(Key)的特徵設計。考慮到所有這些原因,我們可特別設計一個雜湊類,令其與特定的應用程式配合,從而改善常規散列表的效能。注意Java 1.2集合庫的雜湊對映(HashMap)具有更大的靈活性,而且不會自動同步。 ■方法內嵌:只有在方法屬於final
(最終)、private(專用)或static(靜態)的情況下,Java編譯器才能內嵌這個方法。而且某些情況下,還要求它絕對不可以有區域性變數。若程式碼花大量時間呼叫一個不含上述任何屬性的方法,那麼請考慮為其編寫一個“final”版本。 ■I/O:應儘可能使用緩衝。否則,最終也許就是一次僅輸入/輸出一個位元組的惡果。注意JDK 1.0的I/O類採用了大量同步措施,所以若使用象readFully()這樣的一個“大批量”呼叫,然後由自己解釋資料,就可獲得更佳的效能。也要注意Java 1.1的“reader”和“writer”類已針對性能進行了優化。 ■造型和例項:造型會耗去2到200個單位的賦值時間。開銷更大的甚至要求上溯繼承(遺傳)結構。其他高代價的操作會損失和恢復更低層結構的能力。 ■圖形:利用剪下技術,減少在repaint()中的工作量;倍增緩衝區,提高接收速度;同時利用圖形壓縮技術,縮短下載時間。來自JavaWorld的“Java Applets”以及來自Sun的“Performing Animation”是兩個很好的教程。請記著使用最貼切的命令。例如,為根據一系列點畫一個多邊形,和drawLine()相比,drawPolygon()的速度要快得多。如必須畫一條單畫素粗細的直線,drawLine(x,y,x,y)的速度比fillRect(x,y,1,1)快。 ■使用API類:儘量使用來自JavaAPI的類,因為它們本身已針對機器的效能進行了優化。這是用Java難於達到的。比如在複製任意長度的一個數組時,arraryCopy()比使用迴圈的速度快得多。 ■替換API類:有些時候,API類提供了比我們希望更多的功能,相應的執行時間也會增加。因此,可定做特別的版本,讓它做更少的事情,但可更快地執行。例如,假定一個應用程式需要一個容器來儲存大量陣列。為加快執行速度,可將原來的Vector(向量)替換成更快的動態物件陣列。