本篇文章是我閱讀葛一鳴的《java程序性能調優》第一章總結
一、評價性能的主要指標
對於客戶端程序而言，拙劣的性能會嚴重影響用戶體驗。以web服務器為例，服務器的響應時間和吞吐量是兩個重要的參數性能。當服務器承受巨大的訪問壓力的時候，可能會出現響應時間變長，吞吐量下降，甚至是拋出內存溢出異常而崩潰。
一般來說，程序性能通過以下幾個方面來表現：
- 執行速度：程序的反應是否迅速，響應時間是否足夠短
- 內存分配：內存分配是否合理，是否過多的消耗內存和存在內存泄漏
- 啟動時間：從程序啟動到能正常處理業務需要花費多少時間
- 負載承受能力：當系統壓力上升時，系統的執行速度、響應時間的上升曲線是否平緩
為了能夠科學的進行性能分析，對性能指標進行定量評測是非常重要的。主要的定量評測的性能指標有：
- 執行時間：一段代碼從開始執行到運行結束的時間
- cpu時間： 線程占用CPU的時間
- 內存分配：程序運行時占用的內存空間
- 磁盤吞吐量：描述I/O的使用情況
- 響應時間：系統對用戶行為或者事件做出響應的時間。
二、性能瓶頸
木桶原理大家都很清楚了，即決定一個木桶能裝多少水，不在於桶壁上的最高的木塊，而在於 桶壁上最短的那一塊。同理運用在系統性能優化上，如果一個系統用於足夠的CPU資源和內存資源，但是磁盤I/O性能底下，那么系統的性能取決於當前最慢的磁盤I/O速度，而不是內存和CPU。如果要提升系統性能，我們只能提升磁盤I/O的性能，優化CPU和內存是毫無必要的，因此磁盤I/O是系統的性能瓶頸。
最有可能成為系統瓶頸的計算資源如下：
- 磁盤I/O 磁盤I/O的讀寫的速度要比內存慢很多
- 網絡操作 與磁盤I/O類似，由於網絡環境的不穩定，可能網絡操作會更慢
- CPU 對計算資源要求較高的應用，由於長時間，不間斷的占用占用CPU資源，那么對CPU的爭奪將導致性能問題。
- 異常 java的異常捕獲和處理是十分消耗資源的。如果程序高頻率的進行異常處理，整體性能會有明顯下降
- 數據庫 等待數據庫完成操作或者返回請求的結果集，緩慢的同步會成為系統瓶頸
- 鎖競爭 對於高並發的程序來說，如果存在激烈的鎖競爭，會增加線程上下文切換的開銷，白白占用包括的CPU資源
- 內存 內存大小不足
三 Amdahl定律(阿姆達爾定律)
阿姆達爾定律 定義了串行系統並行化后加速比的計算公式和理論上限
加速比=優化前的系統耗時/優化后的系統耗時
加速比越高，表明優化結果越明顯
阿姆達爾定律還定義了加速比與系統並行度和CPU數量的關系
speed為加速比 ， F為系統中串行化程序的比重，N為CPU的數量
如果CPU的數量為無限大，則加速比=1/F,即加速比與系統的串行化律成反比，如果系統中必須有50%的代碼串行，則加速比是2
下面舉個例子
假設有個系統分為以下步驟執行，每個步驟耗時100個時間單位
該系統為串行運行，將耗時500個時間單位
若將步驟二和五並行化，則步驟二和五耗時將是50個時間單位。系統的整體耗時為400個時間單位
加速比為=500/400=1.25
5個步驟，3個串行，則系統串行比率為F=3/5=0.6，將加速比和F帶入上面的公式，可以得出N=2，即處理器的個數為2
若在極端的情況下，系統的串行率依然為50%，但是並行處理器為無數個，則步驟2和5的處理時間趨於0，系統的消耗時間為300個時間單位
加速比=500/300=1.67
即僅提高處理器的數量不一定起有效的作用，需要提高系統中並行化模塊的比重，並在此基礎上合理增加並行處理器數量，才能已最小的投入，獲得最大的加速比