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

對于性能調優而言，通常我們需要經過以下三個步驟：

1. 性能監控；
2. 性能剖析；
3. 性能調優.

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

1.CPU 利用率

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

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

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

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

2.CPU 調度隊列

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

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

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

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

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

3.內存利用率

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

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

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

4.網絡 I/O

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

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

5.磁盤 I/O

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

本文根據ITeye《如何優化Java性能？》整理

Java IDE MyEclipse Spring多買優惠活動正在進行中，買就送iPhone 6 Plus>>