Java效能 (1) – Java Programming Guidelines

轉載地址：http://blog.csdn.net/jinhuiyu/archive/2008/12/10/3487584.aspx

這一部分包含了Java編碼和效能方面的問題， 這個guidelines不是專門針對應用伺服器的，但這是一些在很多情況下的偶通用的規則，如需瞭解Java coding最佳實務的完整分析探討，請參考 Java Blueprints.
避免序列化（Serialization）和還原序列化(Deserialization)

序列化和還原序列化一個對象都是非常消耗CPU (CPU-intensive) 的過程，很有可能會減緩你的系統運行速度，使用
transient 關鍵字來減少資料的序列化。另外，定製（customized）你的readObject() and
writeOjbect()方法在一些情況下也會多系統效能有好處。

使用StringBuffer進行字串運算

這一段大家都知道就不翻譯了

給長時間不再用的變數賦Null值

明確的給長時間不用的對象賦Null值會協助Java的記憶體回收行程識別出這一部分的記憶體可以被安全的回收，雖然Java支援記憶體管理，但是這並避免不了記憶體流失和過分利用記憶體。

應用程式如果不釋放對象的引用可能會帶來記憶體流失， 也可能阻礙Java記憶體回收行程回收這些對象造成過多的記憶體被佔用。在用完一個對象之後明確的賦空值會讓記憶體回收行程更好的回收記憶體。

檢測記憶體流失的一個方法是使用Profiling Tools在每個一Transaction運行完以後打一個記憶體快照(memory
snapshots), 一個沒有記憶體流失的應用在穩定點下進行記憶體回收後會顯示穩定的動態記憶體堆（Active heap memory）。

在需要的情況下定義方法為Final

比較新的動態最佳化編譯器能進行內部的或者程式互動的最佳化， 就算是Java方法沒有定義成Final的時候。使用Final關鍵字的初衷：為了程式架構和可維護性。

除非你非常確認你的方法不能被重寫才能用Final。

把常量定義成Static Final

如果你把常量定義成static final的，動態編譯器能非常容易的進行一些常量摺疊（constant folding）的最佳化。

避免Finalizers

在代碼裡面加finally方法會讓記憶體回收更昂貴和無法預測。Java虛擬機器不保證finally方法啟動並執行時間，finally方法並不一定保證在程式退出以前被運行。

把方法的參數定義成final的

如果方法的參數在方法內部不被修改，把他們定義成final的，通常情況下把所有的變數設成final的如果他們在方法內部不被修改或者被set成什麼值。

在必需的情況下再同步

不要同步你的程式碼片段或者方法，除非這是必需的。為了避免可測性瓶頸，請保證你的同步程式碼片段或者同步方法儘可能短，如果是非同步的資料結構，請使用Java collections 架構，而不要用更加昂貴的選擇 如java.util.HashTable.

使用DataHandlers for SOAP Attachment

使用一個javax.activation.DataHandler for 一個 SOAP attachment 會提高效能。本段暫時沒有接觸過，略過，等用到了再翻譯。

JAX-RPC specifies:
■ A mapping of certain MIME types to Java types.
■ Any MIME type is mappable to a javax.activation.DataHandler .
As a result, send an attachment (.gif or XML document) as a SOAP attachment to an RPC style
web service by utilizing the Java type mappings. When passing in any of the mandated Java type
mappings (appropriate for the attachment’s MIME type) as an argument for the web service, the
JAX-RPC runtime handles these as SOAP attachments.
For example, to send out an image/gif attachment, use java.awt.Image, or create a
DataHandler wrapper over your image. The advantages of using the wrapper are:
■ Reduced coding: You can reuse generic attachment code to handle the attachments because
theDataHandler determines the content type of the contained data automatically. This
feature is especially useful when using a document style service. Since the content is known
at runtime, there is no need to make calls to attachment.setContent(stringContent,
“image/gif”), for example.
■ Improved Performance: Informal tests have shown that usingDataHandler wrappers
doubles throughput for image/gif MIME types, and multiplies throughput by
approximately 1.5 for text/xml or java.awt.Image for image/* types.