一、JVM性能調優策略
二、性能調優
1、Java線程池（java.util.concurrent.ThreadPoolExecutor）
大多數JVM6上的應用采用的線程池都是JDK自帶的線程池，之所以把成熟的Java線程池進行羅嗦說明，是因為該線程池的行為與我們想象的有點出入。Java線程池有幾個重要的配置參數：
- corePoolSize：核心線程數（最新線程數）
- maximumPoolSize：最大線程數，超過這個數量的任務會被拒絕，用戶可以通過RejectedExecutionHandler接口自定義處理方式
- keepAliveTime：線程保持活動的時間
- workQueue：工作隊列，存放執行的任務
Java線程池需要傳入一個Queue參數（workQueue）用來存放執行的任務，而對Queue的不同選擇，線程池有完全不同的行為：
- SynchronousQueue： 一個無容量的等待隊列，一個線程的insert操作必須等待另一線程的remove操作，采用這個Queue線程池將會為每個任務分配一個新線程
- LinkedBlockingQueue ： 無界隊列，采用該Queue，線程池將忽略 maximumPoolSize參數，僅用corePoolSize的線程處理所有的任務，未處理的任務便在LinkedBlockingQueue中排隊
- ArrayBlockingQueue： 有界隊列，在有界隊列和 maximumPoolSize的作用下，程序將很難被調優：更大的Queue和小的maximumPoolSize將導致CPU的低負載；小的Queue和大的池，Queue就沒起動應有的作用
其實我們的要求很簡單，希望線程池能跟連接池一樣，能設置最小線程數、最大線程數，當最小數<任務<最大數時，應該分配新的線程處理；當任務>最大數時，應該等待有空閑線程再處理該任務。
但線程池的設計思路是，任務應該放到Queue中，當Queue放不下時再考慮用新線程處理，如果Queue滿且無法派生新線程，就拒絕該任務。設計導致 “先放等執行”、“放不下再執行”、“拒絕不等待”。所以，根據不同的Queue參數，要提高吞吐量不能一味地增大maximumPoolSize。
當然，要達到我們的目標，必須對線程池進行一定的封裝，幸運的是ThreadPoolExecutor中留了足夠的自定義接口以幫助我們達到目標。我們封裝的方式是： 以SynchronousQueue作為參數，使maximumPoolSize發揮作用，以防止線程被無限制的分配，同時可以通過提高maximumPoolSize來提高系統吞吐量 自定義一個RejectedExecutionHandler，當線程數超過 maximumPoolSize時進行處理，處理方式為隔一段時間檢查線程池是否可以執行新Task，如果可以把拒絕的Task重新放入到線程池，檢查的 時間依賴keepAliveTime的大小。
2、JVM參數
在JVM啟動參數中，可以設置跟內存、垃圾回收相關的一些參數設置，默認情況不做任何設置JVM會工作的很好，但對一些配置很好的Server和具體的應用必須仔細調優才能獲得最佳性能。通過設置我們希望達到一些目標：
- GC的時間足夠的小
- GC的次數足夠的少
- 發生Full GC的周期足夠的長
前兩個目前是相悖的，要想GC時間小必須要一個更小的堆，要保證GC次數足夠少，必須保證一個更大的堆，我們只能取其平衡。
(1)針對JVM堆的設置，一般可以通過-Xms -Xmx限定其最小、最大值，為了防止垃圾收集器在最小、最大之間收縮堆而產生額外的時間，我們通常把最大、最小設置為相同的值;
(2)年輕代和年老代將根據默認的比例（1：2）分配堆內存， 可以通過調整二者之間的比率NewRadio來調整二者之間的大小，也可以針對回收代，比如年輕代，通過 -XX:newSize -XX:MaxNewSize來設置其絕對大小。同樣，為了防止年輕代的堆收縮，我們通常會把-XX:newSize -XX:MaxNewSize設置為同樣大小;
(3)年輕代和年老代設置多大才算合理？這個我問題毫無疑問是沒有答案的，否則也就不會有調優。我們觀察一下二者大小變化有哪些影響
- 更大的年輕代必然導致更小的年老代，大的年輕代會延長普通GC的周期，但會增加每次GC的時間；小的年老代會導致更頻繁的Full GC
- 更小的年輕代必然導致更大年老代，小的年輕代會導致普通GC很頻繁，但每次的GC時間會更短；大的年老代會減少Full GC的頻率
- 如何選擇應該依賴應用程序對象生命周期的分布情況： 如果應用存在大量的臨時對象，應該選擇更大的年輕代；如果存在相對較多的持久對象，年老代應該適當增大。但很多應用都沒有這樣明顯的特性，在抉擇時應該根 據以下兩點：（A）本着Full GC盡量少的原則，讓年老代盡量緩存常用對象，JVM的默認比例1：2也是這個道理 （B）通過觀察應用一段時間，看其他在峰值時年老代會占多少內存，在不影響Full GC的前提下，根據實際情況加大年輕代，比如可以把比例控制在1：1。但應該給年老代至少預留1/3的增長空間
(4)在配置較好的機器上（比如多核、大內存），可以為年老代選擇並行收集算法： -XX:+UseParallelOldGC ，默認為Serial收集
(5)線程堆棧的設置：每個線程默認會開啟1M的堆棧，用於存放棧幀、調用參數、局部變量等，對大多數應用而言這個默認值太了，一般256K就足用。理論上，在內存不變的情況下，減少每個線程的堆棧，可以產生更多的線程，但這實際上還受限於操作系統。
三、調優實例
1、開發測試機器出現異常：java.lang.OutOfMemoryError: GC overhead limit exceeded，這個異常代表：GC為了釋放很小的空間卻耗費了太多的時間，其原因一般有兩個：1，堆太小，2，有死循環或大對象；
首先排除了第2個原因，因為這個應用同時是在線上運行的，如果有問題，早就掛了。所以懷疑是這台機器中堆設置太小；
使用ps -ef |grep "java"查看，發現：
該應用的堆區設置只有768m，而機器內存有2g，機器上只跑這一個java應用，沒有其他需要占用內存的地方。另外，這個應用比較大，需要占用的內存也比較多。
通過上面的情況判斷，只需要改變堆中各區域的大小設置即可，於是改成下面的情況：
跟蹤運行情況發現，相關異常沒有再出現。
2、一個服務系統，經常出現卡頓，分析原因，發現Full GC時間太長
分析上面的數據，發現Young GC執行了54次，耗時2.047秒，每次Young GC耗時37ms，在正常范圍，而Full GC執行了5次，耗時6.946秒，每次平均1.389s，數據顯示出來的問題是：Full GC耗時較長，分析該系統的是指發現，NewRatio=9，也就是說，新生代和老生代大小之比為1:9，這就是問題的原因：
A)新生代太小，導致對象提前進入老年代，觸發老年代發生Full GC;
B)老年代較大，進行Full GC時耗時較大;
優化的方法是調整NewRatio的值，調整到4，發現Full GC沒有再發生，只有Young GC在執行。這就是把對象控制在新生代就清理掉，沒有進入老年代（這種做法對一些應用是很有用的，但並不是對所有應用都要這么做
3、分析Dump文件
從圖中可以看出，這個線程存在問題，隊列LinkedBlockingQueue所引用的大量對象並未釋放，導致整個線程占用內存高達378m，此時通知開發人員進行代碼優化，將相關對象釋放掉即可。