3.2 字符串的調優
下面列出一些常見的關于字符串優化的策略，簡單的我就不多作解釋了。
1) 使用規則表達式處理字符串匹配代替復雜的字符串查找和復制操作；
2) 使用不拷貝字符串中字符的高效方法，例如String.subString()方法；
3) 盡可能不要使用需要拷貝字符串中字符的低效方法，例如String.toUpperCase()和String.toLowercase()；
4) 在編譯期使用String的“+”操作符來執行連接操作，在運行期使用StringBuffer執行連接操作；
這里特別強調一下，因為我已經在網上看到好多文章都推薦使用StringBuffer的append()方法來做字符串的連接操作。其實在JVM能夠在編譯期就能確定結果的情形，使用String的“+”操作符的性能要好很多。
3.3 異常，類型轉換和變量
1) 考慮在拋出異常的時候是否可以不即時生成堆棧信息而使用一個已有的異常實例；
創建異常的開銷很大。當創建一個異常時，需要收集一個棧跟蹤（Stack Trace），這個棧跟蹤用于描述異常是在何處創建的。構建這些棧跟蹤時需要為運行時棧做一份快照，正是這一部分開銷很大。運行時棧不是為有效的異常創建而設計的，而是設計用來讓運行時盡可能快地運行。入棧，出棧，入棧，出棧。讓這樣的工作順利完成，而沒有任何不必要的延遲。但是，當需要創建一個Exception時，JVM不得不說：“先別動，我想就你現在的樣子存一份快照，所以按時停止入棧和出棧操作，笑著等我拍完快照吧。”棧跟蹤不只包含運行時棧中的一兩個元素，而是包含這個棧中的每一個元素，從棧頂到棧底，還有行號和一切應有的東西。
因此，創建異常這一部分開銷很大。從技術上講，棧跟蹤快照是在本地方法Throwable.fillInStackTrace()中發生的，這個方法不是從Throwable contructor那里調用的。但是這并并沒有什么影響——如果你創建了一個Exception，就得付出代價。好在捕獲異常開銷不大，因此可以用try-catch將核心內容包起來。你也可以在方法定義中定義throws子句，這樣對性能不會造成什么損失。從技術上講，你甚至可以隨意地拋出異常，而不用花費很大的代價。招致性能損失的并不是throw操作——盡管在沒有預先創建異常的情況下就拋出異常是有點不尋常。真正要花代價的是創建異常。
幸運的是，好的編程習慣已教會我們，不應該不管三七二十一就拋出異常。異常是為異常的情況而設計的，使用時也應該牢記這一原則。但是，萬一你不想遵從好的編程習慣，Java語言就會讓你知道，那樣就可以讓你的程序運行的更快，從而鼓勵你去那樣做。
2) 用instanceof替代在try-catch中做投機的強制類型轉換方法；
3) 盡可能少的使用強制類型轉換方法，尤其是使用類型特定的集合類時；
4) 使用int優先于其他所有的數據類型；
5) 盡可能使用基本數據類型做臨時變量；
6) 考慮直接獲取實例變量而不通過get，set方法獲取（注意：這不符合面向對象的封裝原則，不推薦使用）。
3.4 循環，選擇和遞歸
1) 在循環中消除不必要的代碼，做盡可能少的事情；
2) Switch語句中使用連續的case值；
3) 確定是否真的需要用到遞歸，最好轉為用循環來實現。
3.5 輸入輸出操作
1) 在程序中盡量不要使用System.out這樣的語句，而使用log4j這樣的日志工具替換，以在程序正式上線的時候可以關閉所有不必要的日志操作提高性能；
2) 當程序中有大量的I/O操作時，考慮將日志寫入不同的文件做到并行化操作以提高性能，并可以用一個后臺線程執行I/O操作而不打斷正常程序的執行；
3) 正確的使用序列化機制，沒有必要序列化的成員變量需要標識為transient；
4) 使用NIO技術。
1) 使用正確的JDBC驅動，盡可能地選擇最新的JDBC驅動；
最新的JDBC驅動不僅優化了性能，而且提供了更多的性能更好的接口供開發人員使用。
2) 使用應用服務器自帶的連接池，而不要使用自己的連接池或干脆不用連接池；
3) 在使用完數據庫資源后，需依次關閉ResultSet，Statement和Connection；
4) 手動控制事務，使用connection.setAutoCommit(false)關閉自動提交，使用executeBatch()進行批量更新；
5) 業務復雜或者大數據量操作時使用存儲過程；
6) ResultSet.next()極其消耗性能，建議使用RowSet替代ResultSet；
7) 把所有的字符數據都保存為Unicode，Java以UniCode形式處理所有數據，數據庫驅動程序不必再執行轉換過程；
8) 盡可能的優化SQL語句；
9) 少用join，多用index；
10) 使用EXPLAIN工具監控SQL語句的執行，以確定瓶頸所在；
11) 不要使用 SELECT * ..., 使用 SELECT Field1, Field1 ...；
12) 通過index獲取字段，而不要使用名字去獲取，例如resultSet.getString(1) 而不是 resultSet.getString("field1")；
13) 緩存數據，避免重復查詢；
14) 考慮使用內存數據庫；
15) 調整fetch size進行批量查詢；
16) 盡可能的使Java數據類型和數據庫類型相匹配，轉換數據在匹配不好的數據類型間效率太差；
17) 避免使用低效的metadata調用，尤其是getBestRowIdentifier( ), getColumns( ), getCrossReference( ), getExportedKeys( ), getImportedKeys( ), getPrimaryKeys( ), getTables( ), and getVersionColumns( )；
18) 使用metadata查詢減少數據庫網絡通信量；
19) 使用最低的事務隔離級別；
20) 使用樂觀鎖機制；
21) 把應用服務器和數據庫分散在不同的機器中，性能可能會更好。
1) Session的使用；
應用服務器保存很多會話時，容易造成內存不足，所以盡量減少Session的使用，放置到Session中的對象不應該是大對象，最好是簡單的小對象，實現串行化接口。當會話不再需要時，應當及時調用invalidate()方法清除會話。而當某個變量不需要時，及時調用removeAttribute()方法清除變量。當session終止時需要清除不必要的資源，實現HttpSessionBindingListener接口的valueUnbound()方法。
2) 使用include directive，而不使用include action；
目前在JSP頁面中引入外部資源的方法主要有兩種：include directive和include action。Include directive：例如<%@ include file=”copyright.html” %>，該指令在編譯時引入指定的資源。在編譯之前，帶有include指令的頁面和指定的資源被合并成一個文件。被引用的資源在編譯時就確定，比運行時才確定資源更高效。Include action：例如< jsp:include page=”copyright.jsp” />，該動作引入指定頁面執行后生成的結果。由于它在運行時完成，因此對輸出結果的控制更加靈活。但是，只有當引用的內容被頻繁改變時，或者在對主頁面的請求沒有出現之前，被引用的頁面無法確定時，使用include action才合算。
3) 對于那些無需跟蹤會話狀態的jsp，關閉自動創建的會話可以節省一些資源。使用如下page指令： < %@ page session=”false” %>；
4) 盡量不要把jsp頁面定義為單線程，應設置為< %@page isThreadSafe=”true” %>；
5) 在jsp頁面最好使用輸出緩存功能，如：< %@page buffer=”32kb” %>；
6) 在servlet之間跳轉時，forward比sendRedirect更有效；
7) 設置HttpServletResponse緩沖區，如：response.setBufferSize(20000)；
8) 建議在servlet里使用ServletOutputStream輸出圖片等對象；
9) 不要使用SingleThreadModel，使Servlet是線程安全的，但是盡可能的減少消耗在同步代碼上的時間，使用足夠多的servlet去響應用戶的請求；
10) 盡可能的使useBean的范圍在page范圍內；
11) Servlet的inti()和destroy()或jspInit()和jspDestroy()方法用于創建和刪除昂貴的資源，例如緩存對象和數據庫連接；
12) 避免使用反向DNS查找；
13) 預編譯JSP頁面；
14) 盡可能的在客戶段校驗數據；
15) 禁止自動裝載特色防止周期性的裝載servlet和jsp。
由于EJB2.0已經很少項目在用了，EJB3.0再成熟一點，我再補充這一部分吧！