深刻理解JVM—性能調優

時間 2019-11-29

標籤深刻理解 jvm 性能欄目 Java 简体版

原文原文鏈接

在上文中咱們分析了不少性能監控工具，介紹這些工具的目的只有一個，那就是找出對應的性能瓶頸。盲目的性能調優是沒有效果的，只有充分知道了哪裏出了問題，針對性的結果纔是立竿見影的。解決了主要的性能問題，那些次要的性能問題也就不足爲慮了！html

咱們知道，性能問題無非就這麼幾種：CPU、內存、磁盤IO、網絡。那咱們來逐一介紹如下相關的現象和一些可能出現的問題。java

1、CPU太高。ios

查看CPU最簡單的咱們使用任務管理器查看，以下圖所示，windows下使用任務管理器查看，Linux下使用top查看。web

通常咱們的服務器都採用Linux，所以咱們重點關注一下Linux(注：windows模式下相信你們已經很熟悉了，而且前面咱們已經提到，使用資源監視器能夠很清楚的看到系統的各項參數，在這裏我就很少作介紹了)算法

在top視圖下，對於多核的CPU，顯示的CPU資源有可能超過100%，由於這裏顯示的是全部CPU佔用百分百的總和，若是你須要看單個CPU的佔用狀況，直接按鍵1就能夠看到。以下圖所示，個人一臺測試機爲8核16GB內存。sql

在top視圖下，按鍵shift+h後，會顯示各個線程的CPU資源消耗狀況，以下圖所示：數據庫

咱們也能夠經過sysstat工具集的pidstat來查看windows

注：sysstat下載地址：http://sebastien.godard.pagesperso-orange.fr/download.html緩存

安裝方法:服務器

1、chmod +x configure

2、./configure

3、make

4、make install

如輸入pidstat 1 2就會隔一秒在控制檯輸出一次固然CPU的狀況，共輸出2次

除了top、pidstat之外，vmstat也能夠進行採樣分析

相關

top、pidstat、mstat的用法你們能夠去網上查找。

下面咱們主要來介紹如下當出現CPU太高的時候，或者CPU不正常的時候，咱們該如何去處理？

CPU消耗太高主要分爲用戶進程佔用CPU太高和內核進程佔用CPU太高（在Linux下top視圖下us指的是用戶進程，而sy是指內核進程），咱們來看一個案例：

程序運行前，系統運行平穩，其中藍色的線表示總的CPU利用率，而紅色的線條表示內核使用率。部署war測試程序，運行以下圖所示：

對於一個web程序，尚未任何請求就佔用這麼多CPU資源，顯然是不正常的。而且咱們看到，不是系統內核佔用的大量CPU，而是系統進程，那是哪個進程的呢？咱們來看一下。

很明顯是咱們的java進程，那是那個地方致使的呢？這就須要用到咱們以前提到的性能監控工具。在此咱們使用可視化監控工具VisualVM。

首先咱們排除了是GC過於頻繁而致使大CPU太高，由於很明顯監控視圖上沒有GC的活動。而後咱們打開profilter去查看如下，是那個線程致使了CPU的太高？

前面一些線程都是容器使用的，而下面一個線程也一直在執行，那是什麼地方調用的呢？查找代碼中使用ThredPoolExecutor的地方。終於發現如下代碼。

private BlockingQueue<SendMsg> queue;

private Executor executor;

//……

public void run() {

while(true){

try {

SendMsg sendMsg = queue.poll();//從隊列中取出

if(null != sendMsg) {

sendForQueue(sendMsg);

}

} catch (Exception e) {

e.printStackTrace();

}

問題很顯然了，咱們看一下對應BlockingQueue的poll方法的API文檔。

不難理解了，雖然使用了阻塞的隊列，可是使用了非阻塞的取法，當數據爲空時直接返回null，那這個語句就等價於下面的語句。

@Override

public void run() {

while(true){

}

至關於死循環麼，很顯然是很是耗費CPU資源的，而且咱們還能夠發現這樣的死循環是耗費的單顆CPU資源，所以能夠解釋上圖爲啥有一顆CPU佔用特別高。咱們來看一下部署在Linux下的top視圖。

猛一看，不是很高麼？咱們按鍵1來看每一個單獨CPU的狀況！

這下看的很清楚了吧！明顯一顆CPU被跑滿了。（由於一個單獨的死循環只能用到一顆CPU，都是單線程運行的）。

問題找到，立刻修復代碼爲阻塞時存取，以下所示：

@Override

public void run() {

while(true){

try {

SendMsg sendMsg = queue.take();//從隊列中取出

sendForQueue(sendMsg);

} catch (Exception e) {

e.printStackTrace();

}

再來監控CPU的變換，咱們能夠看到，基本上不消耗CPU資源（是我沒作任何的訪問哦，有用戶創建線程就會消耗）。

再來看java進程的消耗，基本上不消耗CPU資源

再來看VisualVM的監控，咱們就能夠看到基本上都是容器的一些線程了

以上示例展現了CPU消耗太高狀況下用戶線程佔用特別高的狀況。也就是Linux下top視圖中us比較高的狀況。發生這種狀況的緣由主要有如下幾種：程序不停的在執行無阻塞的循環、正則或者純粹的數學運算、GC特別頻繁。

CPU太高還有一種狀況是內核佔用CPU很高。咱們來看另一個示例。

package com.yhj.jvm.monitor.cpu.sy;

import java.util.Random;

import java.util.concurrent.ExecutorService;

import java.util.concurrent.Executors;

/**

* @Described：系統內核佔用CPU太高測試用例

* @author YHJ create at 2012-3-28 下午05:27:33

* @FileNmae com.yhj.jvm.monitor.cpu.sy.SY_Hign_TestCase.java

public class SY_Hign_TestCase {

private final static int LOCK_COUNT = 1000;

//默認初始化LOCK_COUNT個鎖對象

private Object [] locks = new Object[LOCK_COUNT];

private Random random = new Random();

//構造時初始化對應的鎖對象

public SY_Hign_TestCase() {

for(int i=0;i<LOCK_COUNT;++i)

locks[i]=new Object();

}

abstract class Task implements Runnable{

protected Object lock;

public Task(int index) {

this.lock= locks[index];

}

@Override

public void run() {

while(true){ //循環執行本身要作的事情

doSth();

}

//作類本身要作的事情

public abstract void doSth();

}

//任務A 休眠本身的鎖

class TaskA extends Task{

public TaskA(int index) {

super(index);

}

@Override

public void doSth() {

synchronized (lock) {

try {

lock.wait(random.nextInt(10));

} catch (InterruptedException e) {

e.printStackTrace();

}

//任務B 喚醒全部鎖

class TaskB extends Task{

public TaskB(int index) {

super(index);

}

@Override

public void doSth() {

try {

synchronized (lock) {

lock.notifyAll();

Thread.sleep(random.nextInt(10));

}

} catch (InterruptedException e) {

e.printStackTrace();

}

//啓動函數

public void start(){

ExecutorService service = Executors.newCachedThreadPool();

for(int i=0;i<LOCK_COUNT;++i){

service.execute(new TaskA(i));

service.execute(new TaskB(i));

}

//主函數入口

public static void main(String[] args) {

new SY_Hign_TestCase().start();

}

代碼很簡單，就是建立了2000個線程，讓必定的線程去等待，另一個線程去釋放這些資源，這樣就會有大量的線程切換，咱們來看下效果。

很明顯，CPU的內核佔用率很高，咱們拿具體的資源監視器看一下：

很明顯能夠看出有不少線程切換佔用了大量的CPU資源。一樣的程序部署在Linux下，top視圖以下圖所示：

展開對應的CPU資源，咱們能夠清晰的看到以下情形：

你們能夠看到有大量的sy內核佔用，可是也有很多的us，us是由於咱們啓用了大量的循環，而sy是由於大量線程切換致使的。

咱們也可使用vmstat來查看，以下圖所示：

2、文件IO消耗過大，磁盤隊列高。在windows環境下，咱們可使用資源監視器查看對應的IO消耗，以下圖所示：

這裏不但能夠看到當前磁盤的負載信息，隊列詳情，還能看到每一個單獨的進程的資源消耗狀況。

Linux下主要使用pidstat、iostat等進行分析。以下圖所示

Pidstat –d –t –p [pid] {time} {count}

如：pidstat -d -t -p 18720 1 1

Iostat

Iostat –x xvda 1 10作定時採樣

廢話很少說，直接來示例，上乾貨！

package com.yhj.jvm.monitor.io;

import java.io.BufferedWriter;

import java.io.FileWriter;

import java.io.IOException;

import java.util.concurrent.ExecutorService;

import java.util.concurrent.Executors;

/**

* @Described：IO測試用例

* @author YHJ create at 2012-3-29 上午09:56:06

* @FileNmae com.yhj.jvm.monitor.io.IO_TestCase.java

public class IO_TestCase {

private String fileNmae = "monitor.log";

private String context ;

// 和CPU處理器個數相同，既充分利用CPU資源，又致使線程頻繁切換

private final static int THRED_COUNT = Runtime.getRuntime().availableProcessors();

public IO_TestCase() {//加長寫文件的內容，拉長每次寫入的時間

StringBuilder sb = new StringBuilder();

for(int i=0;i<1000;++i){

sb.append("context index :")

.append(i)

.append("\n");

this.context= new String(sb);

}

//寫文件任務

class Task implements Runnable{

@Override

public void run() {

while(true){

BufferedWriter writer = null;

try {

writer = new BufferedWriter(new FileWriter(fileNmae,true));//追加模式

writer.write(context);

} catch (Exception e) {

e.printStackTrace();

}finally{

try {

writer.close();

} catch (IOException e) {

e.printStackTrace();

}

//啓動函數

public void start(){

ExecutorService service = Executors.newCachedThreadPool();

for(int i=0;i<THRED_COUNT;++i)

service.execute(new Task());

}

//主函數入口

public static void main(String[] args) {

new IO_TestCase().start();

}

這段示例很簡單，經過建立一個和CPU個數相同的線程池，而後開啓這麼多線程一塊兒讀寫同一個文件，這樣就會因IO資源的競爭而致使IO的隊列很高，以下圖所示：

關掉以後立刻就下來了

咱們把這個部署到Linux上觀看。

這裏的%idle指的是系統沒有完成寫入的數量佔用IO總量的百分百，爲何這麼高咱們的系統還能承受？由於我這臺機器的內存爲16GB的，咱們來查看如下top視圖就能夠清晰的看到。

佔用了大量的內存資源。

3、內存消耗

對於JVM的內存模型你們已經很清楚了，前面咱們講了JVM的性能監控工具。對於Java應用來講，出現問題主要消耗在於JVM的內存上，而JVM的內存，JDK已經給咱們提供了不少的工具。在實際的生成環境，大部分應用會將-Xms和-Xmx設置爲相同的，避免運行期間不斷開闢內存。

對於內存消耗，還有一部分是直接物理內存的，不在堆空間，前面咱們也寫過對應的示例。以前一個系統就是由於有大量的NIO操做，而NIO是使用物理內存的，而且開闢的物理內存是在觸發FULL GC的時候才進行回收的，可是當時的機器總內存爲16GB 給堆的內存是14GB Edon爲1.5GB，也就是實際剩下給物理呢哦村的只有0.5GB，最終致使老是發生內存溢出，但監控堆、棧的內存消耗都不大。在這裏我就很少寫了！

4、網絡消耗過大

Windows下使用本地網絡視圖能夠監控當前的網絡流量大小

更詳細的資料能夠打開資源監視器，以下圖所示

Linux平臺可使用如下sar命令查看

sar -n DEV 1 2

字段說明：

rxpck/s：每秒鐘接收的數據包

txpck/s：每秒鐘發送的數據包

rxbyt/s：每秒鐘接收的字節數

txbyt/s：每秒鐘發送的字節數

rxcmp/s：每秒鐘接收的壓縮數據包

txcmp/s：每秒鐘發送的壓縮數據包