1、CPU 使用率怎么計(jì)算？

CPU% = (1 - idleTime / sysTime) * 100

• idleTime：CPU處于空閑狀態(tài)的時(shí)間

• sysTime：CPU處于用戶態(tài)和內(nèi)核臺(tái)的時(shí)間總和

2、CPU 使用率跟啥有關(guān)系？

常聽說計(jì)算密集型的程序是比較耗 CPU 使用率的。

3、CPU 與進(jìn)程、線程有關(guān)系么？

現(xiàn)在分時(shí)操作系統(tǒng)是通過循輪方式分配時(shí)間片進(jìn)行進(jìn)程調(diào)度的，如果進(jìn)程在等待或阻塞，不會(huì)造成 CPU 資源使用。線程稱為輕進(jìn)程，共享進(jìn)程資源，關(guān)于線程的調(diào)度，CPU 對(duì)于線程也是分時(shí)調(diào)度。而在 Java 中，線程的調(diào)用由 JVM 負(fù)責(zé)，線程的調(diào)度一般有兩種模式，分時(shí)調(diào)度和搶占式調(diào)度。

4、一個(gè) while 死循環(huán)，會(huì)不會(huì)引起 CPU 使用率飚升？

會(huì)的。

先不說別的，死循環(huán)會(huì)調(diào)用 CPU 寄存器進(jìn)行計(jì)數(shù)，這個(gè)操作就會(huì)占用 CPU。其次，如果線程一直處于死循環(huán)狀態(tài)，CPU 調(diào)用會(huì)進(jìn)行線程切換么？

死循環(huán)不會(huì)讓出 CPU，除非操作系統(tǒng)時(shí)間片到期，但死循環(huán)會(huì)不斷向系統(tǒng)申請(qǐng)時(shí)間片，直到系統(tǒng)沒有空閑時(shí)間做別的事情。

這個(gè)問題在 stackoverflow 也有人提問：why does an infinite loop of the unintended kind increase the CPU use?

地址：https://stackoverflow.com/questions/2846165/why-does-an-infinite-loop-of-the-unintended-kind-increase-the-cpu-use

5、頻繁 Young GC 會(huì)不會(huì)引起 CPU 使用率飚升？

會(huì)的。

Young GC 本身是 JVM 進(jìn)行垃圾回收的操作，會(huì)計(jì)算內(nèi)存和調(diào)用寄存器，頻繁 Young GC 一定是會(huì)占用 CPU。

之前有個(gè)一個(gè)案例，for 循環(huán)從數(shù)據(jù)庫(kù)查詢數(shù)據(jù)集合，二次封裝新的數(shù)據(jù)集合，這時(shí)如果量比較大時(shí)，內(nèi)存沒有足夠的空間存儲(chǔ)，那么 JVM 就會(huì) GC 回收那些不再使用的數(shù)據(jù)，因此量大的時(shí)候，就會(huì)收到 CPU 使用率報(bào)警。

6、線程數(shù)很高的應(yīng)用，CPU 使用率一定高么？

不會(huì)。

通過 jstack 查看系統(tǒng)線程狀態(tài)，查看整個(gè)線程數(shù)很多，但 Runable 和 Running 狀態(tài)的線程不多，這時(shí) CPU 使用率不一定會(huì)高。

之前有過一個(gè)案例，查看系統(tǒng)線程數(shù) 1000+，jstack 分析 900多個(gè)線程是 BLOCKED 和 WAITING 狀態(tài)的，這種線程是不會(huì)占用 CPU 的。

如果線程數(shù)很高，其實(shí)大多數(shù)原因是死鎖，大量線程處于 BLOCKED 和 WAITING 狀態(tài)。

7、CPU 使用率高的應(yīng)用，線程數(shù)一定高么？

不會(huì)。

同上，CPU 使用率高的關(guān)鍵因素還是計(jì)算密集型操作，一個(gè)線程如果有大量計(jì)算，也會(huì)造成 CPU 使用率高，也是現(xiàn)在為什么一個(gè)大數(shù)據(jù)腳本任務(wù)，要大規(guī)模集群共同運(yùn)算才能運(yùn)行的原因。

8、BLOCKED 狀態(tài)的線程會(huì)不會(huì)引起 CPU 使用率飚升？

不一定。

CPU使用率的飆升，更多是因?yàn)樯舷挛牡那袚Q或者runnable狀態(tài)線程過多導(dǎo)致。Blocked狀態(tài)，未必會(huì)引起CPU上升。

9、分時(shí)操作系統(tǒng) CPU us高或者sy高是什么意思？

通過top命令，可以觀察到CPU的us，sy值，示例如下：

• us 用戶空間占用CPU百分比，簡(jiǎn)單來(lái)說，us高是因?yàn)槌绦驅(qū)е碌?，通過分析線程堆棧，可以很容易的定位到問題線程。

  
  

• sy 內(nèi)核空間占用CPU百分比，sy高的時(shí)候，如果是程序問題導(dǎo)致，基本是因?yàn)榫€程上下文切換造成的。

CPU飆升線程定位示例：

public class cpuTest {
    public static void main(String args[]){
        for(int i=0;i<10;i++){
            new Thread(){
                public void run(){
                    try{
                        Thread.sleep(100000);
                    }catch(Exception e){}
                }
            }.start();
        }
        Thread t=new Thread(){
            public void run(){
                int i=0;
                while(true){
                    i=(i++)/100;
                }
            }
        };
        t.setName("Busiest Thread");
        t.start();
    }
}

步驟1: 執(zhí)行top -c ，顯示進(jìn)程運(yùn)行信息列表，鍵入P (大寫p)，進(jìn)程按照CPU使用率排序，最耗CPU的進(jìn)程PID為18207

步驟2:首先我們可以通過top -Hp <pid>來(lái)看這個(gè)進(jìn)程里所有線程的cpu消耗情況

$ top -Hp 18207top - 19:11:43 up 573 days,  2:43,  2 users,  load average: 3.03, 3.03, 3.02Tasks:  44 total,   1 running,  43 sleeping,   0 stopped,   0 zombieCpu(s): 18.8%us,  0.0%sy,  0.0%ni, 81.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stMem:  99191752k total, 98683576k used,   508176k free,   128248k buffersSwap:  1999864k total,   191064k used,  1808800k free, 17413760k cached PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND18250 admin     20   0 26.1g  28m  10m R 99.9  0.0   0:19.50 java Test18207 admin     20   0 26.1g  28m  10m S  0.0  0.0   0:00.00 java Test18208 admin     20   0 26.1g  28m  10m S  0.0  0.0   0:00.09 java Test18209 admin     20   0 26.1g  28m  10m S  0.0  0.0   0:00.00 java Test18210 admin     20   0 26.1g  28m  10m S  0.0  0.0   0:00.00 java Test18211 admin     20   0 26.1g  28m  10m S  0.0  0.0   0:00.00 java

cpu最高的線程是pid為18250的線程，占了99.9%

步驟3：printf “%x\n” 18250將線程PID轉(zhuǎn)化為16進(jìn)制

$ printf “%x\n” 18250

0X47A

...

步驟4:jstack 18207|grep'0X47A'-C5 --color找出進(jìn)程中消耗CPU最多的線程棧

$ jstack 18207|grep'0X47A'-C5 --colorFull thread dump OpenJDK 64-Bit Server VM (25.66-b60 mixed mode):"Attach Listener" #30 daemon prio=9 os_prio=0 tid=0x00007fb90be13000 nid=0x47d7 waiting on condition [0x0000000000000000]   java.lang.Thread.State: RUNNABLE"DestroyJavaVM" #29 prio=5 os_prio=0 tid=0x00007fb96245b800 nid=0x4720 waiting on condition [0x0000000000000000]   java.lang.Thread.State: RUNNABLE"Busiest Thread" #28 prio=5 os_prio=0 tid=0x00007fb91498d000 nid=0x474a runnable [0x00007fb9065fe000]   java.lang.Thread.State: RUNNABLE    at Test$2.run(Test.java:18)"Thread-9" #27 prio=5 os_prio=0 tid=0x00007fb91498c800 nid=0x4749 waiting on condition [0x00007fb906bfe000]   java.lang.Thread.State: TIMED_WAITING (sleeping)    at java.lang.Thread.sleep(Native Method)    at Test$1.run(Test.java:9)...

因此，最耗cpu的線程是Busiest Thread

日常程序中常見的耗CPU的操作：

1、頻繁GC，訪問量高時(shí)，有可能造成頻繁的GC、甚至FGC。當(dāng)調(diào)用量大時(shí)，內(nèi)存分配過快，就會(huì)造成GC線程不停的執(zhí)行，導(dǎo)致CPU飆高

2、序列化與反序列化，后文中舉了一個(gè)真實(shí)的案例，程序執(zhí)行xml解析的時(shí)，調(diào)用量增大的情況下，導(dǎo)致了CPU被打滿

3、加密解密

4、正則表達(dá)式校驗(yàn)，曾經(jīng)線上發(fā)生一次血案，正則校驗(yàn)將CPU打滿。大概原因是：Java 正則表達(dá)式使用的引擎實(shí)現(xiàn)是 NFA 自動(dòng)機(jī)，這種引擎在進(jìn)行字符匹配會(huì)發(fā)生回溯（backtracking）

5、線程上下文切換、當(dāng)啟動(dòng)了很多線程，而這些線程都處于不斷的阻塞狀態(tài)（鎖等待、IO等待等）和執(zhí)行狀態(tài)的變化過程中。當(dāng)鎖競(jìng)爭(zhēng)激烈時(shí)，很容易出現(xiàn)這種情況

6、某些線程在做無(wú)阻塞的運(yùn)算，簡(jiǎn)單的例子while(true)中不停的做運(yùn)算，沒有任何阻塞。寫程序時(shí)，如果需要做很久的計(jì)算，可以適當(dāng)將程序sleep下

7、Excel 導(dǎo)出事件

頻繁GC案例

案例背景：網(wǎng)關(guān)服務(wù)進(jìn)行控制單個(gè)url訪問次數(shù)限流，CPU過若干天后飆升到80%，重啟服務(wù)過若干天后又再次飆升到80%

分析過程：通過上述方法進(jìn)行線程棧定位，并進(jìn)行內(nèi)存堆分析，發(fā)現(xiàn)pathRaterLimiterConcurrentHashMap對(duì)象占用大量堆空間，找到程序中對(duì)應(yīng)的filter過濾器代碼如下

public HttpRequestMessage apply(HttpRequestMessage request) {
    String requestPath = request.getPath();
    if (pathRaterLimiterConcurrentHashMap.containsKey(requestPath)) {
        if (!pathRaterLimiterConcurrentHashMap.get(requestPath).tryAcquire()) {
            log.warn("too many request:"+requestPath+",time:"+System.currentTimeMillis());
            SessionContext context = request.getContext();
            if(requestPath!=null && requestPath.equals("/voting/selection")){
                context.setEndpoint(VoteTimeOutEndpoint.class.getCanonicalName());
            }
            //context.setEndpoint(ManyRequestsEndpoint.class.getCanonicalName());
            request.setPath("/404.html");
            context.setRouteVIP("limit-api");
        }
    } else {
        pathRaterLimiterConcurrentHashMap.put(requestPath, RateLimiter.create(limit));
        pathRaterLimiterConcurrentHashMap.get(requestPath).tryAcquire();
    }
    return request;
}

分析發(fā)現(xiàn)當(dāng)url不斷增加時(shí)，map的k-v會(huì)不斷增加，以至于最后頻繁觸發(fā)fullgc，導(dǎo)致cpu飆升。

解決方案：跑一個(gè)定時(shí)任務(wù)線程定期清理map中的對(duì)象，后采用LRU算法重寫一個(gè)maputil，定時(shí)清理過期的key值。

正則表達(dá)式案例

案例背景：前幾天線上一個(gè)項(xiàng)目監(jiān)控信息突然報(bào)告異常，上到機(jī)器上后查看相關(guān)資源的使用情況，發(fā)現(xiàn) CPU 利用率將近 100%。

分析過程：

通過 Java 自帶的線程 Dump 工具，我們導(dǎo)出了出問題的堆棧信息。我們可以看到所有的堆棧都指向了一個(gè)名為 validateUrl 的方法，這樣的報(bào)錯(cuò)信息在堆棧中一共超過 100 處。通過排查代碼，我們知道這個(gè)方法的主要功能是校驗(yàn) URL 是否合法。

很奇怪，一個(gè)正則表達(dá)式怎么會(huì)導(dǎo)致 CPU 利用率居高不下。為了弄清楚復(fù)現(xiàn)問題，我們將其中的關(guān)鍵代碼摘抄出來(lái)，做了個(gè)簡(jiǎn)單的單元測(cè)試。

public static void main(String[] args) {
   String badRegex = "^([hH][tT]{2}[pP]://|[hH][tT]{2}[pP][sS]://)" +
           "(([A-Za-z0-9-~]+).)+([A-Za-z0-9-~\\\\/])+$";
   String bugUrl = "http://www.fapiao.com/dddp-web/pdf/download?" +
           "request=6e7JGxxxxx4ILd-kExxxxxxxqJ4-CHLmqVnenXC692m7" +
           "4H38sdfdsazxcUmfcOH2fAfY1Vw__%5EDadIfJgiEf";
   if (bugUrl.matches(badRegex)) {
     System.out.println("match!!");
   } else {
     System.out.println("no match!!");
   }
}

正則表達(dá)式分為三部分：

第一部分匹配 http 和 https 協(xié)議，第二部分匹配 www. 字符，第三部分匹配許多字符。我看著這個(gè)表達(dá)式發(fā)呆了許久，也沒發(fā)現(xiàn)沒有什么大的問題。

其實(shí)這里導(dǎo)致 CPU 使用率高的關(guān)鍵原因就是：Java 正則表達(dá)式使用的引擎實(shí)現(xiàn)是 NFA 自動(dòng)機(jī)，這種正則表達(dá)式引擎在進(jìn)行字符匹配時(shí)會(huì)發(fā)生回溯（backtracking）。而一旦發(fā)生回溯，那其消耗的時(shí)間就會(huì)變得很長(zhǎng)，有可能是幾分鐘，也有可能是幾個(gè)小時(shí)，時(shí)間長(zhǎng)短取決于回溯的次數(shù)和復(fù)雜度。

正則表達(dá)式是一個(gè)很方便的匹配符號(hào)，但要實(shí)現(xiàn)這么復(fù)雜，功能如此強(qiáng)大的匹配語(yǔ)法，就必須要有一套算法來(lái)實(shí)現(xiàn)，而實(shí)現(xiàn)這套算法的東西就叫做正則表達(dá)式引擎。簡(jiǎn)單地說，實(shí)現(xiàn)正則表達(dá)式引擎的有兩種方式：DFA 自動(dòng)機(jī)（Deterministic Final Automata 確定型有窮自動(dòng)機(jī)）和 NFA 自動(dòng)機(jī)（Non deterministic Finite Automaton 不確定型有窮自動(dòng)機(jī)）。

對(duì)于這兩種自動(dòng)機(jī)，他們有各自的區(qū)別，這里并不打算深入將它們的原理。簡(jiǎn)單地說，DFA 自動(dòng)機(jī)的時(shí)間復(fù)雜度是線性的，更加穩(wěn)定，但是功能有限。而 NFA 的時(shí)間復(fù)雜度比較不穩(wěn)定，有時(shí)候很好，有時(shí)候不怎么好，好不好取決于你寫的正則表達(dá)式。

解決方案：

其實(shí)在正則表達(dá)式中有這么三種模式：貪婪模式、懶惰模式、獨(dú)占模式。在關(guān)于數(shù)量的匹配中，有 + ? * {min,max} 四種，如果只是單獨(dú)使用，那么它們就是貪婪模式。

如果在他們之后加多一個(gè) ? 符號(hào)，那么原先的貪婪模式就會(huì)變成懶惰模式，即盡可能少地匹配。但是懶惰模式還是會(huì)發(fā)生回溯現(xiàn)象的。

如果在他們之后加多一個(gè) + 符號(hào)，那么原先的貪婪模式就會(huì)變成獨(dú)占模式，即盡可能多地匹配，但是不回溯。

String goodRegex = "^([hH][tT]{2}[pP]://|[hH][tT]{2}[pP][sS]://)" +
        "(([A-Za-z0-9-~]+).)++([A-Za-z0-9-~\\\\/])+$";

Excel導(dǎo)出案例

案例背景：京東某系統(tǒng)使用了poi-ooxml-3.5-final做excel導(dǎo)出功能。起初使用該版本的poi的HSSF配合多線程生成excel，沒有任何問題，后來(lái)改成了XSSF生成后上線，導(dǎo)出3w條數(shù)據(jù)時(shí)，cpu使用率達(dá)到了100%，內(nèi)存達(dá)到了100%

由于cpu使用率打爆，內(nèi)存打爆，整個(gè)服務(wù)器處于拒絕服務(wù)狀態(tài)，而呈現(xiàn)到前端則是應(yīng)用系統(tǒng)大部分卡死。于是業(yè)務(wù)方不斷反復(fù)點(diǎn)擊導(dǎo)出按鈕，狀況不斷擴(kuò)大到集群內(nèi)其他機(jī)器上，導(dǎo)致集群出現(xiàn)雪崩現(xiàn)象。

分析過程

由于服務(wù)器已經(jīng)被打死，內(nèi)存那么高，根本無(wú)法dump線上堆內(nèi)存，甚至連jstack查看線程棧都無(wú)法使用。因此嘗試在測(cè)試機(jī)復(fù)盤

可見eden空間的s0和s1已經(jīng)無(wú)法交換了，eden空間已經(jīng)完全打滿，old空間也一樣打滿，yong gc和full gc都非常頻繁，cpu自然使用率高了，不過不足以打滿整個(gè)cpu！現(xiàn)在目前定位到了fullgc沒有回收垃圾，那么需要找到內(nèi)存打滿和為啥沒回收的原因。要想找到內(nèi)存打滿的原因肯定需要分析heap空間對(duì)象。

由于問題出現(xiàn)在導(dǎo)出報(bào)表，并且已知升級(jí)了版本并且改成了單線程導(dǎo)出就解決了，同時(shí)之前使用HSSF的時(shí)候并沒有出現(xiàn)問題，也證明了業(yè)務(wù)代碼沒有問題，問題出現(xiàn)在XSSF的版本和多線程上。所以本地可以模擬poi-ooxml-3.5-FINAL的XSSF進(jìn)行大量數(shù)據(jù)的導(dǎo)出實(shí)驗(yàn)，同時(shí)需要進(jìn)行多線程導(dǎo)出。

在本地mock數(shù)據(jù)可以使用簡(jiǎn)單的大量對(duì)象構(gòu)成的結(jié)構(gòu)進(jìn)行導(dǎo)出，線上30個(gè)列導(dǎo)出，本地測(cè)試5個(gè)列，線上是本地的6倍，線上的每一行的數(shù)據(jù)量必然要比本地的數(shù)據(jù)量大很多。同時(shí)懷疑是poi-ooxml-3.5-FINAL內(nèi)存泄露或內(nèi)存管理出現(xiàn)的問題，那么其實(shí)不需要4g內(nèi)存，在2g的內(nèi)存下壓榨到死看看heap中大量的對(duì)象是不是poi相關(guān)的就可以了。然后再升級(jí)下版本，繼續(xù)壓榨一下看看會(huì)不會(huì)壓死即可。

public static void main(String[] args) {
    int size = 500000;
    List<User> users = new ArrayList<>(size);
    User user;
    for (int i = 0; i < size; i++) {
        user = new User();
        user.setId(Integer.toUnsignedLong(i));
        user.setAge(i + 10);
        user.setName("user" + i);
        user.setRemark(System.currentTimeMillis() + "");
        user.setSex("男");
        users.add(user);
    }

    new Thread(() -{
            String[] columnName = {"用戶id", "姓名", "年齡", "性別", "備注"};
    Object[][] data = new Object[size][5];
    int index = 0;
    for (User u : users) {
        data[index][0] = u.getId();
        data[index][1] = u.getName();
        data[index][2] = u.getAge();
        data[index][3] = u.getSex();
        data[index][4] = u.getRemark();
        index++;
    }
    XSSFWorkbook xssfWorkbook = generateExcel("test", "test", columnName, data);
    }).start();
    try {
        Thread.currentThread().join();//等待子線程結(jié)束
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
}

模擬現(xiàn)象與線上情況類似，大量cpu占用在XSSFCell.setCellValue中，生成excel generateExcel就占據(jù)了所有的cpu，堆信息全是POI對(duì)象

這里還需要注意的是，需要驗(yàn)證poi-ooxml-3.5-FINAL在多線程情況下是否會(huì)出現(xiàn)這個(gè)問題，驗(yàn)證很簡(jiǎn)單，把new Thread去掉，直接在主線程導(dǎo)出。這里直接說明實(shí)驗(yàn)結(jié)果，new Thread去了依然內(nèi)存爆滿！

解決方案

查看poi官網(wǎng)的change log http://poi.apache.org/changes.html ，既然3.5-FINAL的XSSF有問題，向上查找3.5-FINAL之后的XSSF相關(guān)字樣的信息，會(huì)發(fā)現(xiàn)在3.6中memory usage optimization in xssf - avoid creating parentless xml beans，xxsf進(jìn)行中做了內(nèi)存優(yōu)化 - 避免了創(chuàng)建無(wú)父類的xml bean對(duì)象

所以得出結(jié)論，升級(jí)poi-oxxml版本到3.6或者更高版本！

   

    

     

      

       

        

         
           

            來(lái)源：技術(shù)讓夢(mèng)想更偉大