JVM配置方面，一般情況可以先用預設配置（基本的一些初始引數可以保證一般的應用跑的比較穩定了），在測試中根據系統執行狀況（會話併發情況、會話時間等），結合gc日誌、記憶體監控、使用的垃圾收集器等進行合理的調整，當老年代記憶體過小時可能引起頻繁Full GC，當記憶體過大時Full GC時間會特別長。

那麼JVM的配置比如新生代、老年代應該配置多大最合適呢？答案是不一定，調優就是找答案的過程，物理記憶體一定的情況下，新生代設定越大，老年代就越小，Full GC頻率就越高，但Full GC時間越短；相反新生代設定越小，老年代就越大，Full GC頻率就越低，但每次Full GC消耗的時間越大。建議如下：

-Xms和-Xmx的值設定成相等，堆大小預設為-Xms指定的大小，預設空閒堆記憶體小於40%時，JVM會擴大堆到-Xmx指定的大小；空閒堆記憶體大於70%時，JVM會減小堆到-Xms指定的大小。如果在Full GC後滿足不了記憶體需求會動態調整，這個階段比較耗費資源。新生代儘量設定大一些，讓物件在新生代多存活一段時間，每次Minor GC 都要儘可能多的收集垃圾物件，防止或延遲物件進入老年代的機會，以減少應用程式發生Full GC的頻率。老年代如果使用CMS收集器，新生代可以不用太大，因為CMS的並行收集速度也很快，收集過程比較耗時的併發標記和併發清除階段都可以與使用者執行緒併發執行。方法區大小的設定，1.6之前的需要考慮系統執行時動態增加的常量、靜態變數等，1.7只要差不多能裝下啟動時和後期動態載入的類資訊就行。

程式碼實現方面，效能出現問題比如程式等待、記憶體洩漏除了JVM配置可能存在問題，程式碼實現上也有很大關係：

避免建立過大的物件及陣列：過大的物件或陣列在新生代沒有足夠空間容納時會直接進入老年代，如果是短命的大物件，會提前出發Full GC。避免同時載入大量資料，如一次從資料庫中取出大量資料，或者一次從Excel中讀取大量記錄，可以分批讀取，用完儘快清空引用。當集合中有物件的引用，這些物件使用完之後要儘快把集合中的引用清空，這些無用物件儘快回收避免進入老年代。可以在合適的場景（如實現快取）採用軟引用、弱引用，比如用軟引用來為ObjectA分配例項：SoftReference objectA=new SoftReference(); 在發生記憶體溢位前，會將objectA列入回收範圍進行二次回收，如果這次回收還沒有足夠記憶體，才會丟擲記憶體溢位的異常。 避免產生死迴圈，產生死迴圈後，迴圈體內可能重複產生大量例項，導致記憶體空間被迅速佔滿。儘量避免長時間等待外部資源（資料庫、網路、裝置資源等）的情況，縮小物件的生命週期，避免進入老年代，如果不能及時返回結果可以適當採用非同步處理的方式等。