JAVA內存優化和性能優化

1. 沒有必要時請不用使用靜態變量

當某個對象被定義爲stataic變量所引用，這個對象所佔有的內存將不會被回收。有時，開發者會將常常調用的對象或者變量定義爲static，以便提升程序的運行性能。所以，不是經常使用到的對象或者變量，不要定義爲static類型的變量。 2. 充分利用單例機制

實用單例能夠減小對資源的加載，縮短運行的時間，提升系統效率。可是，單例並非全部地方都適用於。單例能夠適用於如下兩個方面：

• 控制資源的使用，經過線程同步來控制資源的併發訪問；
• 控制實例的產生，以達到節約資源的目的

3. 減小對象的建立

儘可能避免在常常調用的方法中循環使用new對象，因爲系統不只要花費時間來建立對象，並且還要花時間對這些對象進行垃圾回收和處理。設計模式中的享元模式就是爲了減小對象的屢次建立而來的。在咱們能夠控制的範圍內，最大限度的重用對象；在有些時候，最好能用基本的數據類型或數組來替代對象。 4. 使用final修飾符

帶有final修飾符的類是不可派生的。在Java核心API中，有許多應用 final的例子，例如java.lang.String。爲String類指定final防止了使用者覆蓋length()方法。另外，若是一個類是 final的，則該類全部方法都是final的。Java編譯器會尋找機會內聯（inline）全部的final方法（這和具體的編譯器實現有關）。此舉可以使性能平均提升50%。 5. 儘可能使用局部變量

調用方法時傳遞的參數以及在調用中建立的臨時變量都保存在分配給改方法的棧（Stack）中，速度較快。其餘變量，如靜態變量、實例變量等，都在堆（Heap）中建立，速度較慢。 6. 處理好包裝類型和基本類型二者的使用場所

雖然包裝類型和基本類型在使用過程當中是能夠相互轉換，但它們二者所產生的內存區域是徹底不一樣的，基本類型數據產生和處理都在棧中處理，而包裝類型是對象，是在堆中產生實例。在集合類對象，有對象方面須要的處理適用包裝類型，其餘的狀況，建議提倡使用基本類型。 7. 使用StringBuilder和StringBuffer替換String

單線程使用StringBuilder，多線程狀況下使用StringBuffer，這樣性能會有很大提高。 8. 儘可能不要使用finalize方法

因爲GC的工做量很大，尤爲是回收Young代內存時，大都會引發應用程序暫停，因此再選擇使用finalize方法進行資源清理，會致使GC負擔更大，程序運行效率更差 9. 儘可能使用基本數據類型代替對象 10. 減小對變量的重複計算

for(int i=0;i<list.size();i++)

應該改寫爲：

for(int i=0,len=list.size();i<len;i++)

或者

for(int i = list.size(); I > -1; i--)

而且在循環中應該避免使用複雜的表達式，在循環中，循環條件會被反覆計算，若是不使用複雜表達式，而使循環條件值不變的話，程序將會運行的更快。 11. 儘可能在finally塊中釋放資源

程序中使用到的資源應當被釋放，以免資源泄漏。這最好在finally塊中去作。無論程序執行的結果如何，finally塊老是會執行的，以確保資源的正確關閉。 12. 儘可能早釋放無用對象的引用

大部分時，方法局部引用變量所引用的對象 會隨着方法結束而變成垃圾，所以，大部分時候程序無需將局部，引用變量顯式設爲null。 13. 儘可能緩存常用的對象

儘量將常用的對象進行緩存，可使用數組，或HashMap的容器來進行緩存，但這種方式可能致使系統佔用過多的緩存，性能降低，推薦可使用一些第三方的開源工具，如EhCache，Oscache進行緩存，他們基本都實現了FIFO/FLU等緩存算法。 14. 儘可能避免很是大的內存分配

有時候問題不是由當時的堆狀態形成的，而是由於分配失敗形成的。分配的內存塊都必須是連續的，而隨着堆heap愈來愈滿，找到較大的連續塊愈來愈困難。 15. 慎用異常

當建立一個異常時，須要收集一個棧跟蹤(stack track)，這個棧跟蹤用於描述異常是在何處建立的。構建這些棧跟蹤時須要爲運行時棧作一份快照，正是這一部分開銷很大。當須要建立一個 Exception 時，JVM 不得不說：先別動，我想就您如今的樣子存一份快照，因此暫時中止入棧和出棧操做。棧跟蹤不僅包含運行時棧中的一兩個元素，而是包含這個棧中的每個元素。

若是建立一個 Exception ，就得付出代價。好在捕獲異常開銷不大，所以可使用 try-catch 將核心內容包起來。從技術上講，您甚至能夠隨意地拋出異常，而不用花費很大的代價。招致性能損失的並非 throw 操做——儘管在沒有預先建立異常的狀況下就拋出異常是有點不尋常。真正要花代價的是建立異常。幸運的是，好的編程習慣已教會咱們，不該該無論三七二十一就拋出異常。異常是爲異常的狀況而設計的，使用時也應該牢記這一原則。

參考文獻：

http://www.open-open.com/lib/view/open1399884636989.html