摘要：能夠讓的周期利用的更充分對于多線程應用運行在多處理器和多核系統(tǒng)上至很有挑戰(zhàn)性的。另外，當達到飽和狀態(tài)的時候并不能說明的性能和伸縮性已經達到了最佳的狀態(tài)。磁盤如果應用有對磁盤進行操作，我們需要對磁盤進行監(jiān)控，來監(jiān)測可能出現(xiàn)的磁盤性能問題。

對于 Java 性能比較關心的同學大概都知道《Java Performance》這本書，一般而言，很多同學在日常寫 Java Code 的時候很少去關心性能問題，但是在我們寫 Code 的過程中必須考慮到性能對程序的影響。小到我們使用位運算來實現(xiàn)算術運算，大到我們對 Java 代碼的總體架構設計，「性能」其實離我們很近。本篇文章主要提到幾個點，希望能夠對大家有所啟發(fā)。

對于性能調優(yōu)而言，通常我們需要經過以下三個步驟：1，性能監(jiān)控；2，性能剖析；3，性能調優(yōu)

作為國內在技術層面遙遙領先的 APM 廠商，One APM 的 Ai 產品對于 Java Application 性能優(yōu)化提供了非常完善的指標：

性能監(jiān)控：
影響 Java 性能多維度指標監(jiān)控

性能剖析：
Application 性能剖析

性能調優(yōu)：通過分析影響Application性能問題根源，進行優(yōu)化Application；

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

1.CPU 利用率

對于一個應用來說，為了讓應用達到最好的性能和可擴展性，我們不僅僅要充分利用 CPU 周期內可用的部分，而且要讓這部分 CPU 的使用更有價值，而不是浪費。能夠讓 CPU 的周期利用的更充分對于多線程應用運行在多處理器和多核系統(tǒng)上至很有挑戰(zhàn)性的。另外，當 CPU 達到飽和狀態(tài)的時候并不能說明 CPU 的性能和伸縮性已經達到了最佳的狀態(tài)。

為了區(qū)分應用是如何利用 CPU 資源的，我們必須從操作系統(tǒng)級別來檢測。在很多操作系統(tǒng)上，CPU 的利用率統(tǒng)計報告通常包括用戶和系統(tǒng)或內核對操作系統(tǒng)的使用。用戶對 CPU 的使用是指應用用來執(zhí)行應用代碼執(zhí)行所需要的時間。相比之下，內核和系統(tǒng)對 CPU 的使用是指應用用來執(zhí)行操作系統(tǒng)內核代碼鎖花費的時間。高的內核或者系統(tǒng) CPU 使用率可以表明共享資源緊迫，或者是有大量的 I/O 設備交互。理想的狀態(tài)為了提高應用的性能和伸縮性，讓內核或系統(tǒng) CPU 時間為 0%，因為花在執(zhí)行內核或系統(tǒng)代碼的時間是可以用來執(zhí)行應用代碼的。因此 CPU 使用優(yōu)化的一個正確方向就是盡可能減少 CPU 花在執(zhí)行內核代碼或者系統(tǒng)代碼上的時間。

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

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

2.CPU 調度隊列

除了對 CPU 使用的監(jiān)控，我們也可以通過監(jiān)控 CPU 執(zhí)行隊列來檢查系統(tǒng)是否已經滿負載。執(zhí)行隊列是用來存儲輕量級進程，這些進程通常是已經準備好執(zhí)行了但是正在等待 CPU 調度而在調度隊列等待的一種狀態(tài)，當輕量級進程別當前處理器能來得及處理的數(shù)量更多的時候，調度隊列將會產生。比較深的 CPU 調度隊列表明系統(tǒng)已經滿負荷了。系統(tǒng)的執(zhí)行隊列深度等于虛擬處理器執(zhí)行不了的等待數(shù)，虛擬處理器數(shù)等于系統(tǒng)的硬件線程數(shù)。我們可以用 JAVA 的 API 來拿到虛擬處理器數(shù)。

Runtime.avaliableProcessors()。當執(zhí)行隊列深度大于虛擬處理器個數(shù)的四倍或更多的時候，操作系統(tǒng)將會出現(xiàn)反應遲鈍的現(xiàn)象。

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

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

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

3.內存利用率

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

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

虛擬機的垃圾收集器在交換的時候性能非常差，因為垃圾收集器所訪問的大部分區(qū)域都是不可達的，也就是垃圾收集器會引起交換活動的發(fā)生。場景是戲劇性的，如果垃圾收集的堆區(qū)域已經被交換到了磁盤空間，這個時候將會以頁為單位發(fā)生交換，這樣才能夠被垃圾收集器所掃描到，在交換的過程中會戲劇性的引發(fā)垃圾收集器的收集時間延長，這個時候如果垃圾收集器是
「Stop The World」（使得應用響應停止）的，那么這個時間就會被延長。

4.網(wǎng)絡 I/O

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

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

5.磁盤 I/O

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

OneAPM for Java 能夠深入到所有 Java 應用內部完成應用性能管理和監(jiān)控，包括代碼級別性能問題的可見性、性能瓶頸的快速識別與追溯、真實用戶體驗監(jiān)控、服務器監(jiān)控和端到端的應用性能管理。想閱讀更多技術文章，請訪問 OneAPM 官方博客。