這篇文章節(jié)選自《java performance》，對java性能比較關(guān)心的同學(xué)大概都知道這本書，性能這個東西可能是很多同學(xué)在日常寫java code的時候很少去關(guān)心的，但是在我們寫code的過程中確又時時離不開對程序性能的影響，小到我們使用位運算來實現(xiàn)算術(shù)運算，大到我們對JAVA代碼的總體架構(gòu)設(shè)計，性能其實離我們很近。本片文章主要提到幾個點，主要是在性能領(lǐng)域我們比較關(guān)注的一些問題，并且是有啟發(fā)性的，如果同學(xué)對性能較感興趣，那么我們可以一起深入研究各個點。

對于性能調(diào)優(yōu)，通常會有三個步驟：1，性能監(jiān)控；2，性能剖析；3，性能調(diào)優(yōu)

我們對于操作系統(tǒng)的性能關(guān)注主要在下面幾個點上：CPU利用率、CPU調(diào)度執(zhí)行隊列、內(nèi)存利用率、網(wǎng)絡(luò)I/O、磁盤I/O。

對于一個應(yīng)用來說，為了讓應(yīng)用達(dá)到最好的性能和可擴(kuò)展性，我們不僅僅要充分利用CPU周期內(nèi)可用的部分，而且要讓這部分CPU的使用更有價值，而不是浪費。能夠讓CPU的周期利用的更充分對于多線程應(yīng)用運行在多處理器和多核系統(tǒng)上至很有挑戰(zhàn)性的。另外，當(dāng)CPU達(dá)到飽和狀態(tài)的時候并不能說明CPU的性能和伸縮性已經(jīng)達(dá)到了最佳的狀態(tài)。為了區(qū)分應(yīng)用是如何利用CPU資源的，我們必須從操作系統(tǒng)級別來檢測。在很多操作系統(tǒng)上，CPU的利用率統(tǒng)計報告通常包括用戶和系統(tǒng)或內(nèi)核對操作系統(tǒng)的使用。用戶對CPU的使用是指應(yīng)用用來執(zhí)行應(yīng)用代碼執(zhí)行所需要的時間。相比之下，內(nèi)核和系統(tǒng)對CPU的使用是指應(yīng)用用來執(zhí)行操作系統(tǒng)內(nèi)核代碼鎖花費的時間。高的內(nèi)核或者系統(tǒng)CPU使用率可以表明共享資源緊迫，或者是有大量的I/O設(shè)備交互。理想的狀態(tài)為了提高應(yīng)用的性能和伸縮性，讓內(nèi)核或系統(tǒng)CPU時間為0%，因為花在執(zhí)行內(nèi)核或系統(tǒng)代碼的時間是可以用來執(zhí)行應(yīng)用代碼的。因此CPU使用優(yōu)化的一個正確方向就是盡可能減少CPU花在執(zhí)行內(nèi)核代碼或者系統(tǒng)代碼上的時間。

對于計算密集型應(yīng)用，性能監(jiān)控比監(jiān)測用戶CPU使用和內(nèi)核或系統(tǒng)CPU使用要更深層次，在計算密集型應(yīng)用中，我們需要監(jiān)測CPU時鐘周期內(nèi)的執(zhí)行執(zhí)行條數(shù)（Instructions per clock；IPC）或者是每條CPU執(zhí)行所使用的CPU周期（cycles per instruction；CPI）。對于計算密集型應(yīng)用來說我們從這兩個維度來監(jiān)測CPU是不錯的選擇，因為現(xiàn)代操作系統(tǒng)的打包CPU性能報告工具通常只會打印CPU的利用率，而不會打印CPU周期內(nèi)CPU用來執(zhí)行指令的時間。這意味著當(dāng)CPU正在等待內(nèi)存中的數(shù)據(jù)的時候，操作系統(tǒng)CPU性能報告工具也會認(rèn)為CPU是正在使用的狀態(tài)，我們把這個場景叫做“Stall”，“Stall”場景經(jīng)常會發(fā)生，比如在CPU正在執(zhí)行指令的任何時候，只要是指令需要的數(shù)據(jù)沒有準(zhǔn)備好，也就是沒有在寄存器或者CPU緩存內(nèi)，都會發(fā)生“Stall”場景。

當(dāng)“Stall”場景發(fā)生的時候CPU會浪費時鐘周期，因為CPU必須要等待指令需要的數(shù)據(jù)到達(dá)寄存器或者緩沖器。而且在這個場景中，數(shù)百個CPU時鐘周期被浪費是很正常的事情，因此在計算密集型應(yīng)用中，提高性能的策略是減少“Stall”場景的發(fā)生或者是增強(qiáng)CPU的緩存使用從而使得更少的CPU周期因為等待數(shù)據(jù)而浪費掉。這類的性能監(jiān)控知識已經(jīng)超越了本書的內(nèi)容，需要性能專家的幫助了。然而，后面講到的Oracle Solaris Studio Performance Analyzer這種性能剖析工具將會包括此類數(shù)據(jù)。

除了對CPU使用的監(jiān)控，我們也可以通過監(jiān)控CPU執(zhí)行隊列來檢查系統(tǒng)是否已經(jīng)滿負(fù)載。執(zhí)行隊列是用來存儲輕量級進(jìn)程，這些進(jìn)程通常是已經(jīng)準(zhǔn)備好執(zhí)行了但是正在等待CPU調(diào)度而在調(diào)度隊列等待的一種狀態(tài)，當(dāng)輕量級進(jìn)程別當(dāng)前處理器能來得及處理的數(shù)量更多的時候，調(diào)度隊列將會產(chǎn)生。比較深的CPU調(diào)度隊列表明系統(tǒng)已經(jīng)滿負(fù)荷了。系統(tǒng)的執(zhí)行隊列深度等于虛擬處理器執(zhí)行不了的等待數(shù)，虛擬處理器數(shù)等于系統(tǒng)的硬件線程數(shù)。我們可以用java的api來拿到虛擬處理器數(shù)，Runtime.avaliableProcessors()。當(dāng)執(zhí)行隊列深度大于虛擬處理器個數(shù)的四倍或更多的時候，操作系統(tǒng)將會出現(xiàn)反應(yīng)遲鈍的現(xiàn)象。

對于CPU調(diào)度隊列的檢測的一個通用指導(dǎo)是當(dāng)我們發(fā)現(xiàn)隊列深度高于虛擬進(jìn)程數(shù)一倍的時候就要注意了，但是沒有必要立即采取行動。當(dāng)大于三倍或四倍或者更高的時候就要注意了，解決問題刻不容緩。

通常有兩個可選的途徑來觀察隊列的深度，第一個是通過增加CPU來分擔(dān)負(fù)載或者減少對現(xiàn)有CPU的負(fù)載。這種途徑從本質(zhì)上減少了每個執(zhí)行單元的負(fù)載線程數(shù)，從而減少執(zhí)行執(zhí)行隊列的深度。

另外的一種途徑是通過剖析系統(tǒng)運行的應(yīng)用來增加CPU的使用率，換個說法就是尋找一種可以減少花費在垃圾回收上的CPU周期，或者尋找更好的算法來以更少的CPU周期來執(zhí)行CPU指令。性能專家通常專注后面的一種途徑:減少代碼的執(zhí)行路徑長度和更好的CPU指令選擇。JAVA程序員可以通過更好的執(zhí)行算法和數(shù)據(jù)結(jié)構(gòu)來提高代碼的執(zhí)行效率。

除了CPU的使用率，系統(tǒng)的內(nèi)存屬性也需要被監(jiān)控，這些屬性包括比如：分頁、交換、鎖、多線程引起的上下文交換等。

交換通常發(fā)生在當(dāng)應(yīng)用需要的內(nèi)存大于實際的物理內(nèi)存的時候，處理這種情況操作系統(tǒng)通常會配置一個相應(yīng)的區(qū)域叫做交換區(qū)。交換區(qū)通常位于物理磁盤上，當(dāng)物理內(nèi)存內(nèi)應(yīng)用耗盡的時候，操作系統(tǒng)會將一部分內(nèi)存數(shù)據(jù)暫時交換到磁盤空間上，這部分內(nèi)存區(qū)域通常是訪問頻率最低的一塊區(qū)域，而不會影響比較“忙”的內(nèi)存區(qū)域；當(dāng)被交換到磁盤區(qū)域的內(nèi)存又被應(yīng)用訪問的時候，這個時候就需要從磁盤交換區(qū)將以頁為單位讀入內(nèi)存，交換會影響應(yīng)用的性能。

虛擬機(jī)的垃圾收集器在交換的時候性能非常差，因為垃圾收集器所訪問的大部分區(qū)域都是不可達(dá)的，也就是垃圾收集器會引起交換活動的發(fā)生。場景是戲劇性的，如果垃圾收集的堆區(qū)域已經(jīng)被交換到了磁盤空間，這個時候?qū)皂摓閱挝话l(fā)生交換，這樣才能夠被垃圾收集器所掃描到，在交換的過程中會戲劇性的引發(fā)垃圾收集器的收集時間延長，這個時候如果垃圾收集器是“Stop The World”（使得應(yīng)用響應(yīng)停止）的，那么這個時間就會被延長。

分布式JAVA應(yīng)用的性能和伸縮性會受到網(wǎng)絡(luò)帶寬和網(wǎng)絡(luò)性能的限制。例如，如果我們往網(wǎng)絡(luò)接口發(fā)送比他能夠處理的更多的數(shù)據(jù)包，數(shù)據(jù)包將會堆積在操作系統(tǒng)的緩沖區(qū)內(nèi)，這將會引發(fā)應(yīng)用延遲，另外其他的情況也會導(dǎo)致網(wǎng)絡(luò)應(yīng)用的延遲。

區(qū)分和監(jiān)控的工具通常在操作系統(tǒng)的打包工具中很難找到。盡管linux提供了netstat命令，linux和solaris都提供了網(wǎng)絡(luò)使用情況的實現(xiàn)，他們都提供了包括每秒發(fā)包、接包、錯包、沖突等信息的統(tǒng)計。在以太網(wǎng)中，一小部分包沖突是很正常的現(xiàn)象。如果錯包情況比較多那可能是網(wǎng)卡有問題了。同時，盡管netstat可以統(tǒng)計網(wǎng)絡(luò)接口的發(fā)送和接收數(shù)據(jù)情況，這很難斷定網(wǎng)卡是否被充分利用。例如，如果netstat -i顯示現(xiàn)在每秒有2500個包從網(wǎng)卡發(fā)出，但是我們?nèi)匀粺o法判斷當(dāng)前的網(wǎng)絡(luò)利用率是100%還是1%，我們僅僅能夠知道目前有流量。這僅僅是在不知道網(wǎng)絡(luò)包大小的情況下能夠得到的結(jié)論。簡單的說我們無法通過linux和solaris提供的netstat來判斷當(dāng)前網(wǎng)絡(luò)是否影響了性能。我們需要一些其他的工具在我們的JAVA應(yīng)用運行的過程中來監(jiān)測網(wǎng)絡(luò)。

如果應(yīng)用有對磁盤進(jìn)行操作，我們需要對磁盤進(jìn)行監(jiān)控，來監(jiān)測可能出現(xiàn)的磁盤性能問題。一些應(yīng)用是I/O密集型的，比如數(shù)據(jù)庫。磁盤的使用通常還存在于應(yīng)用日志系統(tǒng)，日志通常是我們用來記錄系統(tǒng)運行過程中重要信息的。