1.進行必要的優化。
必須記住最重要的優化原則之壹。除非找到必須要做的優化，否則不要替換任何標準庫，也不要做復雜的邏輯優化。
在大多數情況下，過早的優化會占用大量時間，並使代碼難以閱讀和維護。更糟糕的是，這些優化通常不會帶來任何好處，因為優化應用程序的非關鍵部分會花費大量時間。
2。找到真正的瓶頸
遵循第壹個建議並確定需要改進的部分後，從哪裏開始呢？
有兩種方法可以解決這個問題:
從壹些可疑的或可能引起問題的事情開始。或者通過分析器找到瓶頸。通過分析器找到問題，可以幫助妳更好地理解代碼的性能，同時，妳可以專註於最關鍵的部分。當然，如果妳從來沒有嘗試過用分析儀進行幹業績的分析，估計妳只會靠自己的直覺走反方向。
3.特性試驗
這是壹個非常重要的方法，提前寫好程序的性能測試，這樣妳就可以在妳的性能優化前後運行性能測試，這樣妳就可以在部署程序後，實際評估性能問題的實際解決方案。同時可以避免壹些性能優化帶來的程序問題，比如妳要緩存數據庫，那麽這個就顯得尤為重要。
4.優先考慮最大的瓶頸
創建壹個性能測試程序，用Profiler分析應用程序後，妳會發現有壹大堆問題需要修復，但是問題又來了，妳還是不知道從哪裏入手。
從壹個妳能盡快解決問題、提高績效的地方開始，這也是妳說服團隊績效評估必要性的最好依據。但恰恰相反，我建議從最重要的性能問題入手，這樣也能最大限度的提升性能。到目前為止，壹般的性能優化思路都差不多，我們知道壹些Java語言特有的優化方案。
6.使用+來拼接語句中的字符串。
等等，這個問題不是和5有沖突嗎？其實不是的。由於字符串的不變性，如果在for循環中拼接壹個字符串，每次都會創建壹個新的對象，但語句中的+不是。JVM將在編譯時優化字符串+拼接的性能，並最終使用壹個字符串對象，如下例所示。
7.盡可能使用基本類型而不是包裝類型。
壹種常見的做法是用基本類型代替包裝器類型，比如用int代替integer，用double代替Double，這樣可以讓JVM將變量存儲在Stack而不是Heap中，以降低整體的內存消耗。
8.盡量避免使用Biginteger和BigDecimal。
上面我們已經討論過數據類型了，所以我們繼續來看看Biglnteger和BigDecimal。特別是BigDecimal，在精度上給我們帶來了足夠的好處，但是價格昂貴。
與簡單的long或double相比，BigInteger和BigDecimal需要更多的內存，這大大降低了所有計算的速度。因此，如果基本類型沒有被優先考慮，那麽需要重新考慮存儲的值是否超出了long類型的最大範圍或者精度是否失控。