服務器
來源：http://t.cn/ei9jdbu
處理過線上問題的同學基本上都會遇到系統突然運行緩慢，cpu 100%%uff0c以及full gc次數過多的問題。當然，這些問題的最終導致的直觀現象就是系統運行緩慢，并且有大量的報警。本文主要針對系統運行緩慢這一問題，提供該問題的排查思路，從而定位出問題的代碼點，進而提供解決該問題的思路。
對于線上系統突然產生的運行緩慢問題，如果該問題導致線上系統不可用，那么首先需要做的就是，導出jstack和內存信息，然后重啟系統，盡快保證系統的可用性。這種情況可能的原因主要有兩種：
代碼中某個位置讀取數據量較大，導致系統內存耗盡，從而導致full gc次數過多，系統緩慢；
代碼中有比較耗cpu的操作，導致cpu過高，系統運行緩慢；
相對來說，這是出現頻率最高的兩種線上問題，而且它們會直接導致系統不可用。另外有幾種情況也會導致某個功能運行緩慢，但是不至于導致系統不可用：
代碼某個位置有阻塞性的操作，導致該功能調用整體比較耗時，但出現是比較隨機的；
某個線程由于某種原因而進入waiting狀態，此時該功能整體不可用，但是無法復現；
由于鎖使用不當，導致多個線程進入死鎖狀態，從而導致系統整體比較緩慢。
對于這三種情況，通過查看cpu和系統內存情況是無法查看出具體問題的，因為它們相對來說都是具有一定阻塞性操作，cpu和系統內存使用情況都不高，但是功能卻很慢。下面我們就通過查看系統日志來一步一步甄別上述幾種問題。
1. full gc次數過多
相對來說，這種情況是最容易出現的，尤其是新功能上線時。對于full gc較多的情況，其主要有如下兩個特征：
線上多個線程的cpu都超過了100%%uff0c通過jstack命令可以看到這些線程主要是垃圾回收線程
通過jstat命令監控gc情況，可以看到full gc次數非常多，并且次數在不斷增加。
首先我們可以使用 top命令查看系統cpu的占用情況，如下是系統cpu較高的一個示例：
top - 08:31:10 up 30 min, 0 users, load average: 0.73, 0.58, 0.34
kib mem: 2046460 total, 1923864 used, 122596 free, 14388 buffers
kib swap: 1048572 total, 0 used, 1048572 free. 1192352 cached mem
pid user pr ni virt res shr s %cpu %mem time command
9 root 20 0 2557160 288976 15812 s 98.0 14.1 0:42.60 java
可以看到，有一個java程序此時cpu占用量達到了98.8%%uff0c此時我們可以復制該進程id 9，并且使用如下命令查看呢該進程的各個線程運行情況：
top-hp9該進程下的各個線程運行情況如下：
top - 08:31:16 up 30 min, 0 users, load average: 0.75, 0.59, 0.35
threads: 11 total, 1 running, 10 sleeping, 0 stopped, 0 zombie
%cpu(s): 3.5 us, 0.6 sy, 0.0 ni, 95.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
kib mem: 2046460 total, 1924856 used, 121604 free, 14396 buffers
kib swap: 1048572 total, 0 used, 1048572 free. 1192532 cached mem
pid user pr ni virt res shr s %cpu %mem time command
10 root 20 0 2557160 289824 15872 r 79.3 14.2 0:41.49 java
11 root 20 0 2557160 289824 15872 s 13.2 14.2 0:06.78 java
可以看到，在進程為 9的java程序中各個線程的cpu占用情況，接下來我們可以通過jstack命令查看線程id為 10的線程為什么耗費cpu最高。需要注意的是，在jsatck命令展示的結果中，線程id都轉換成了十六進制形式。可以用如下命令查看轉換結果，也可以找一個科學計算器進行轉換：
root@a39de7e7934b:/#printf"%x\\\\n"10a這里打印結果說明該線程在jstack中的展現形式為 0xa，通過jstack命令我們可以看到如下信息：
"main" #1 prio=5 os_prio=0 tid=0x00007f8718009800 nid=0xb runnable [0x00007f871fe41000]
java.lang.thread.state: runnable
at com.aibaobei.chapter2.eg2.userdemo.main(userdemo.java:9)
"vm thread" os_prio=0 tid=0x00007f871806e000 nid=0xa runnable
這里的vm thread一行的最后顯示 nid=0xa，這里nid的意思就是操作系統線程id的意思。而vm thread指的就是垃圾回收的線程。這里我們基本上可以確定，當前系統緩慢的原因主要是垃圾回收過于頻繁，導致gc停頓時間較長。我們通過如下命令可以查看gc的情況：
root@8d36124607a0:/#jstat-gcutil9100010s0s1eomccsygcygctfgcfgctgct0.000.000.0075.0759.0959.6032590.91965177.7158.6350.000.000.000.0859.0959.6033060.93066117.8228.7520.000.000.000.0859.0959.6033510.94367017.9248.8670.000.000.000.0859.0959.6033970.95567938.0298.984可以看到，這里fgc指的是full gc數量，這里高達6793，而且還在不斷增長。從而進一步證實了是由于內存溢出導致的系統緩慢。那么這里確認了內存溢出，但是如何查看你是哪些對象導致的內存溢出呢，這個可以dump出內存日志，然后通過eclipse的mat工具進行查看，如下是其展示的一個對象樹結構：
經過mat工具分析之后，我們基本上就能確定內存中主要是哪個對象比較消耗內存，然后找到該對象的創建位置，進行處理即可。這里的主要是printstream最多，但是我們也可以看到，其內存消耗量只有12.2%%u3002也就是說，其還不足以導致大量的full gc，此時我們需要考慮另外一種情況，就是代碼或者第三方依賴的包中有顯示的 system.gc()調用。這種情況我們查看dump內存得到的文件即可判斷，因為其會打印gc原因：
[fullgc(system.gc())[tenured:262546k->262546k(349568k),0.0014879secs]262546k->262546k(506816k),[metaspace:3109k->3109k(1056768k)],0.0015151secs][times:user=0.00sys=0.00,real=0.01secs][gc(allocationfailure)[defnew:2795k->0k(157248k),0.0001504secs][tenured:262546k->402k(349568k),0.0012949secs]265342k->402k(506816k),[metaspace:3109k->3109k(1056768k)],0.0014699secs][times:user=0.00比如這里第一次gc是由于 system.gc()的顯示調用導致的，而第二次gc則是jvm主動發起的。總結來說，對于full gc次數過多，主要有以下兩種原因：
代碼中一次獲取了大量的對象，導致內存溢出，此時可以通過eclipse的mat工具查看內存中有哪些對象比較多；
內存占用不高，但是full gc次數還是比較多，此時可能是顯示的system.gc()調用導致gc次數過多，這可以通過添加-xx: disableexplicitgc來禁用jvm對顯示gc的響應。
2. cpu過高
在前面第一點中，我們講到，cpu過高可能是系統頻繁的進行full gc，導致系統緩慢。而我們平常也肯能遇到比較耗時的計算，導致cpu過高的情況，此時查看方式其實與上面的非常類似。首先我們通過 top命令查看當前cpu消耗過高的進程是哪個，從而得到進程id；然后通過 top-hp<pid>

華為智慧屏能安裝云極光嗎 華為智慧屏怎么下載云極光
云服務器ip共享和獨立有什么區別
域名最短多少位
阿里云服務器什么時候優惠的
Linux操作系統的基礎知識
管家皮服務器如何掛接云數據庫
俄羅斯 云服務器哪個好
seo優化知識：seo排名的5大缺點