一個j2ee項目的性能會受多方面的影響，比較常見的一個是web前臺的大量訪問，web前臺的程序要能夠處理高併發量的請求，但要達到這種要求了一般從編碼角度來考慮起的作用不太大，我們通常的一個web項目使用MVC模式的一些開源架構作爲基礎，使前臺的程序結構比較明瞭，在有些地方使用LazyLoading的設計模式，一般也就僅此而已，跟多的改善性能的措施一是垂直方式（如增加機器的硬件，設定一些JVM和服務器的優化配置），二是水平方式（採用羣集的方式，在多臺機器上部署web前臺的程序，利用負載均衡的策略將用戶的請求發送到不同的服務器上），通過上述方式來改善web前臺的性能（實際上是用戶體驗）。
我們在這所說的web前臺指的是一些頁面相應的程序和一些簡單的邏輯處理，不包含真正進行業務邏輯處理的功能，當然你可以將所有的一切放在一個項目中，部署到一臺服務器上，完全沒有問題（除了有些功能的完成不是你所寫的而是你調用別的程序來得到結果） ，但在一個大型的j2ee項目中通常是不會由一個程序項目完成的，在這樣的項目中，前臺的程序相應用戶的請求後，將一些信息封裝好後去調用中間件程序或後臺程序，那這些中間件和後臺一般會單獨作爲一個項目部署在其他的機器上，之所以要把它們分開部署，就是可能一個VM的處理效能不夠，而採用分佈式處理的方式，採用分佈式處理可以提升效率，但也帶來了一些問題，如安全性問題，分佈式事務處理的問題等等，好在這些問題一般我們在寫程序是不用考慮太多，相應的分佈式處理框架一般都提供解決的方法，但仍有一些是我們可以通過程序來改善的，比如在安全性問題上，我們在傳輸信息是可以加上自己的密匙（比如一些md5或是base64的字符串，傳輸的信息也可以先轉換成md5或是base64再傳輸，當然這些對應的是些字符串的信息）。雖然通過分佈式處理方式可以提高單個VM的效率，但它要通過網絡來相互調用，而這種遠程的調用要比VM內部的方法調用要慢很多（好幾個數量級），所有我們儘量減少網絡調用的次數，比如運用VO模式，將所有的狀態數據包裝成一個可序列化的對象來傳輸或讀取，從而減少遠程調用的次數。另一方面在分佈式處理的方式中如xmlrpc,web services中我們可以多考慮用異步調用的方式來取代同步調用的方式，這也可以改善調用方的性能（多是web前臺），但有些情況是不能用異步方式調用的，比如調用方等着返回的結果來進行下步的實時操作，但有些比如調用方調用發送郵件的中間件就可以用異步的方法了。
在中間件或後臺程序中不可避免的要同數據庫打交道，持久層的設計也是影響一個j2ee項目的重要原因，這中間有兩方面，一個是同數據庫的連接是個開銷比較大的地方，在這裏我們大多用數據源來連接程序和數據庫；還有一個就是操作數據庫的代碼，這個方面的東西要說的很多，現在一般是用ORM來做數據持久方面的工作，我們將在以後單獨講講。除了持久層方面，中間件部分還有很多別的地方要注意的。一個就是我們在中間件上調用業務邏輯處理這部分，一個用戶調用一個針對他的業務邏輯處理對象，如果用普通的類來做，中間件的負荷也就比較大了，在這裏我們可以用Session facade模式，即用Session bean來封裝業務邏輯部分，用戶的請求到達中間件後有一個相對應的session bean來處理（多爲簡單的無狀態的session bean) ，之所以這麼做是利用了ejb容器對session bean的優化，另一方面在session bean中跨數據庫的事務也很好維持（也是由ejb容器來負責）。對應於session facade,還有message facade，它是利用消息驅動bean和jms來處理一些消息和隊列方面的問題，它也可以是異步的方式（這方面我還沒玩過，等有些經驗後再總結出來）。除了採用session bean來處理用戶的邏輯請求，在中間件中我們還可以採用Service Locator模式來提高中間件的性能，說白了，該模式就是採用緩存機制來響應前臺的調用，多在實際中使用一個static 的hashmap來做爲緩存，存儲一些如EJBHOME,JMS連接工廠，數據源等，從而減少大量的jndi查找和遠程調用的次數。
以上就是我用過的一些改善j2ee程序性能的方法，簡單好用
