1.string.split(seg);的時間是stringutils.split(str, seg);的1.5倍.
2.string.replaceall(regex, replacement)的時間是stringutils.replace(text, searchstring, replacement)的1.86倍。
3.如果是單個字元替換stringutils.replace(text, searchstring, replacement)的時間是stringutils.replacechars(str, searchchar, replacechar)的15倍。
4.如果是字串替換stringutils.replace(text, searchstring, replacement) 是stringutils.replacechars(str, searchstring, replacestring)1.4倍。
一句話：能不用正規表示式的地方盡量不用，哪怕自己寫方法來實現。
5.如果必須到正則匹配，則需要宣告為final型別，以便在編譯期間就編譯好。final pattern pattern = pattern.compile(match)。
1.輸出到console是輸出到本地磁碟(無快取)的1.33倍
2.無快取輸出到本地磁碟是加快取輸出到本地磁碟的1.09倍(根據實際情況buffersize不一樣，效能也不一樣)
3.輸出到本地磁碟(無快取)+輸出到console是輸出到本地磁碟（無快取）的1.48倍。
注：時間比例視try包圍的**執行時間而定，**執行時間越長，try catch對整體時間的影響越小。這裡只是為證明加catch 與不加catch對效能的影響。
1. 迴圈執行字串比較方法stringutils.equals(str1, str2); 加catch是不加catch執行時間的1.16倍。
2.迴圈執行字串比較方法rr.equals(str2)，都加catch，拋空指標異常是不拋異常執行時間的7400倍。
結論：加try catch對效能有輕微影響，所以不要濫用try-catch，但是對於有可能拋異常的地方也不要吝於加try-catch。 拋異常與不拋異常對效能影響很大，對於空指標等可以從**端上fix上的異常一定要及時修復。
2.xml解析器效能對比，**推薦xstream+xpp**組合。
JAVA效能優化
1.string 比stringbuffer 更佔記憶體空間，拼接字串時 原因 string 這個物件的實際占用記憶體數量與其自身的位元組數不相符。結論 應該少用string 這東西，特別是string 的 操作，不僅原來的string 物件 不能繼續使用，而且又要產生多個新物件，因此會較高的占用記...
java效能優化
1.減少gc的壓力,gc 執行緒是乙個優先順序比較低的執行緒,他是乙個守護執行緒 服務於主線程 我們的堆記憶體 2.盡量避免我們的new操作 總結 避免物件建立和gc 物件使用完成後進行置空 string string a new string a string a1 a string a2 a b...
JAVA效能優化
多使用區域性變數，減少使用靜態變數。區域性變數被建立在棧中，訪問速度快。靜態變數則是在堆記憶體 避免使用finalize，該方法會給gc增添很大的負擔 如果是單執行緒，盡量使用非多執行緒安全的，因為執行緒安全來自於同步機制，同步機制會降低效能。例如，單執行緒程式，能使用hashmap，就不要用has...