CPU/堆/類/線程
根據(jù)服務(wù)部署和項(xiàng)目架構(gòu)，從如下幾個(gè)方面排查：
（1）運(yùn)用服務(wù)器：排查內(nèi)存，cpu,請(qǐng)求數(shù)等；
（2）文件圖片服務(wù)器：排查內(nèi)存，cpu,請(qǐng)求數(shù)等；
（3）計(jì)時(shí)器服務(wù)器：排查內(nèi)存，cpu,請(qǐng)求數(shù)等；
（4）redis服務(wù)器：排查內(nèi)存，cpu,連接數(shù)等；
（5）db服務(wù)器：排查內(nèi)存，cpu,連接數(shù)等；
在秒殺后30分鐘內(nèi)，
1.運(yùn)用程序服務(wù)器cpu暴增，內(nèi)存暴增，造成cpu和內(nèi)存暴增的根本原因是請(qǐng)求數(shù)過高，單臺(tái)運(yùn)用服務(wù)器達(dá)到3000多；
2.redis請(qǐng)求超時(shí)
3.jdbc連接超時(shí)
4.通過gc查看，發(fā)現(xiàn)24小時(shí)內(nèi)，F(xiàn)ullGC發(fā)生了152次
5.再看看堆棧，發(fā)現(xiàn)有一些線程阻塞和死鎖
jstat -l pid，也可以通過VisualVM分析
6.發(fā)現(xiàn)有2000多個(gè)線程請(qǐng)求無效資源
原因：
(1)在秒殺時(shí)，請(qǐng)求量過高，導(dǎo)致運(yùn)用服務(wù)器負(fù)載過高；
(2)redis連接池滿，獲取不到連接，connot get a connection from thread pool
(3)jdbc連接池滿，獲取不到連接和超時(shí)
(4)存在大對(duì)象代碼，如向list集合中不停添加對(duì)象，不能及時(shí)回收對(duì)象導(dǎo)致內(nèi)存增加，頻繁發(fā)生Full GC
(5)tomcat并發(fā)參數(shù)，jvm優(yōu)化參數(shù)，jedis配置參數(shù)，jdbc配置參數(shù)不合理
(6)未對(duì)請(qǐng)求量進(jìn)行削峰和限流
(7)資源連接未及時(shí)釋放，如redis連接，jdbc連接未及時(shí)釋放
解決方案：
1.增加運(yùn)用服務(wù)，做流量削峰和分流
由于該項(xiàng)目未增加MQ，因此只能采用硬負(fù)載，增加服務(wù)器水平擴(kuò)展方式來實(shí)現(xiàn)流量削峰和流量分流
2.優(yōu)化jvm參數(shù)，如下為本次優(yōu)化后的參數(shù)
JAVA_OPTS="-server -Xmx9g -Xms9g -Xmn3g -Xss500k -XX:+DisableExplicitGC -XX:MetaspaceSize=2048m -XX:MaxMetaspaceSize=2048m -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -Dfile.encoding=UTF8 -Duser.timezone=GMT+08"
3.優(yōu)化tomcat并發(fā)相關(guān)參數(shù)
主要是兩方面：
(1)修改bio協(xié)議為nio2 (2)根據(jù)服務(wù)器配置，業(yè)務(wù)場(chǎng)景，業(yè)務(wù)流量等合理設(shè)置相關(guān)參數(shù)，盡量達(dá)到最優(yōu)
4.redis 和jdbc參數(shù)優(yōu)化
5.代碼優(yōu)化
(1)優(yōu)化掉大對(duì)象
(2)優(yōu)化未及時(shí)釋放的對(duì)象和連接資源
6.解決000多個(gè)線程請(qǐng)求無效資源問題
<!--在conf/context.xml增大緩存-->
<Resource
cachingAllowed = "true"
cacheMaxSize = "102400"
/>
============================================================
CPU
原因包括業(yè)務(wù)邏輯問題(死循環(huán))、頻繁gc以及上下文切換過多。而最常見的往往是業(yè)務(wù)邏輯(或者框架邏輯)導(dǎo)致的，可以使用jstack來分析對(duì)應(yīng)的堆棧情況。
使用jstack分析cpu問題
jstack主要用來查看某個(gè)Java進(jìn)程內(nèi)的線程堆棧信息
命令行參數(shù)說明：
-l long listings，會(huì)打印出額外的鎖信息，在發(fā)生死鎖時(shí)可以用jstack -l pid來觀察鎖持有情況-m mixed mode，不僅會(huì)輸出Java堆棧信息，還會(huì)輸出C/C++堆棧信息（比如Native方法）
jstack可以定位到線程堆棧，根據(jù)堆棧信息我們可以定位到具體代碼，所以它在JVM性能調(diào)優(yōu)中使用得非常多。
來一個(gè)實(shí)例找出某個(gè)Java進(jìn)程中最耗費(fèi)CPU的Java線程并定位堆棧信息，用到的命令有ps、top、printf、jstack、grep
①找出java進(jìn)程ID，部署在服務(wù)器的Java應(yīng)用名稱為mrf-center
得到進(jìn)程ID為21711，第二步找出該進(jìn)程內(nèi)最耗費(fèi)CPU的線程，可以使用ps -Lfp pid或者ps -mp pid -o THREAD, tid, time或者top -Hp pid，我這里用第三個(gè)，輸出如下：
服務(wù)器請(qǐng)求數(shù)
數(shù)據(jù)庫請(qǐng)求
TIME列就是各個(gè)Java線程耗費(fèi)的CPU時(shí)間，CPU時(shí)間最長的是線程ID為21742的線程，用
②輪到j(luò)stack上場(chǎng)了，它用來輸出進(jìn)程21711的堆棧信息，然后根據(jù)線程ID的十六進(jìn)制值grep，如下：
可以看到CPU消耗在PollIntervalRetrySchedulerThread這個(gè)類的Object.wait()，我找了下我的代碼，定位到下面的代碼：
案例二：
用top -H -p pid來找到cpu使用率比較高的一些線程
然后將占用最高的pid轉(zhuǎn)換為16進(jìn)制printf ‘%x\n’ pid得到nid
接著直接在jstack中找到相應(yīng)的堆棧信息jstack pid |grep ‘nid’ -C5 –color
可以看到我們已經(jīng)找到了nid為0x42的堆棧信息，接著只要仔細(xì)分析一番即可。
當(dāng)然更常見的是我們對(duì)整個(gè)jstack文件進(jìn)行分析，通常我們會(huì)比較關(guān)注WAITING和TIMED_WAITING的部分，BLOCKED就不用說了。我們可以使用命令cat jstack.log | grep “java.lang.Thread.State” | sort -nr | uniq -c來對(duì)jstack的狀態(tài)有一個(gè)整體的把握，如果WAITING之類的特別多，那么多半是有問題啦。
頻繁GC
使用jstat -gc pid 1000命令來對(duì)gc分代變化情況進(jìn)行觀察。
1000表示采樣間隔(ms)，S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU分別代表兩個(gè)Survivor區(qū)、Eden區(qū)、老年代、元數(shù)據(jù)區(qū)的容量和使用量。YGC/YGT、FGC/FGCT、GCT則代表YoungGc、FullGc的耗時(shí)和次數(shù)以及總耗時(shí)。如果看到gc比較頻繁，再針對(duì)gc方面做進(jìn)一步分析。
jstat（JVM統(tǒng)計(jì)監(jiān)測(cè)工具）:各個(gè)區(qū)內(nèi)存和GC的情況
先看JVM堆內(nèi)存布局：
上下文切換：
使用vmstat命令來進(jìn)行查看頻繁上下文問題
磁盤
首先是磁盤空間方面，我們直接使用df -hl來查看文件系統(tǒng)狀態(tài)。
磁盤問題還是性能上的問題。我們可以通過iostatiostat -d -k -x來進(jìn)行分析
最后一列%util可以看到每塊磁盤寫入的程度，而rrqpm/s以及wrqm/s分別表示讀寫速度，一般就能幫助定位到具體哪塊磁盤出現(xiàn)問題了。
另外我們還需要知道是哪個(gè)進(jìn)程在進(jìn)行讀寫，一般來說開發(fā)自己心里有數(shù)，或者用iotop命令來進(jìn)行定位文件讀寫的來源。
不過這邊拿到的是tid，我們要轉(zhuǎn)換成pid，可以通過readlink來找到pidreadlink -f /proc/*/task/tid/…/…。
找到pid之后就可以看這個(gè)進(jìn)程具體的讀寫情況cat /proc/pid/io
我們還可以通過lsof命令來確定具體的文件讀寫情況lsof -p pid
內(nèi)存
內(nèi)存問題排查起來相對(duì)比CPU麻煩一些，場(chǎng)景也比較多。主要包括OOM、GC問題和堆外內(nèi)存。一般來講，我們會(huì)先用free命令先來檢查一發(fā)內(nèi)存的各種情況。
對(duì)內(nèi)內(nèi)存
內(nèi)存問題大多還都是堆內(nèi)內(nèi)存問題。表象上主要分為OOM和StackOverflow。
OOM
JMV中的內(nèi)存不足，OOM大致可以分為以下幾種：
Exception in thread “main” java.lang.OutOfMemoryError: unable to create new native thread
這個(gè)意思是沒有足夠的內(nèi)存空間給線程分配java棧，基本上還是線程池代碼寫的有問題，比如說忘記shutdown，所以說應(yīng)該首先從代碼層面來尋找問題，使用jstack或者jmap。如果一切都正常，JVM方面可以通過指定Xss來減少單個(gè)thread stack的大小。
另外也可以在系統(tǒng)層面，可以通過修改/etc/security/limits.confnofile和nproc來增大os對(duì)線程的限制
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
這個(gè)意思是堆的內(nèi)存占用已經(jīng)達(dá)到-Xmx設(shè)置的最大值，應(yīng)該是最常見的OOM錯(cuò)誤了。解決思路仍然是先應(yīng)該在代碼中找，懷疑存在內(nèi)存泄漏，通過jstack和jmap去定位問題。如果說一切都正常，才需要通過調(diào)整Xmx的值來擴(kuò)大內(nèi)存。
Caused by: java.lang.OutOfMemoryError: Meta space
這個(gè)意思是元數(shù)據(jù)區(qū)的內(nèi)存占用已經(jīng)達(dá)到XX:MaxMetaspaceSize設(shè)置的最大值，排查思路和上面的一致，參數(shù)方面可以通過XX:MaxPermSize來進(jìn)行調(diào)整(這里就不說1.8以前的永久代了)。
Stack Overflow
棧內(nèi)存溢出，這個(gè)大家見到也比較多。
Exception in thread “main” java.lang.StackOverflowError
表示線程棧需要的內(nèi)存大于Xss值，同樣也是先進(jìn)行排查，參數(shù)方面通過Xss來調(diào)整，但調(diào)整的太大可能又會(huì)引起OOM。
使用JMAP定位代碼內(nèi)存泄漏
上述關(guān)于OOM和StackOverflow的代碼排查方面，我們一般使用JMAPjmap -dump:format=b,file=filename pid來導(dǎo)出dump文件。
通過mat(Eclipse Memory Analysis Tools)導(dǎo)入dump文件進(jìn)行分析，內(nèi)存泄漏問題一般我們直接選Leak Suspects即可，mat給出了內(nèi)存泄漏的建議。另外也可以選擇Top Consumers來查看最大對(duì)象報(bào)告。和線程相關(guān)的問題可以選擇thread overview進(jìn)行分析。除此之外就是選擇Histogram類概覽來自己慢慢分析
jmap（Memory Map）和 jhat（Java Heap Analysis Tool）：
jmap導(dǎo)出堆內(nèi)存，然后使用jhat來進(jìn)行分析
jmap語法格式如下：
打印進(jìn)程的類加載器和類加載器加載的持久代對(duì)象信息，輸出：類加載器名稱、對(duì)象是否存活（不可靠）、對(duì)象地址、父類加載器、已加載的類大小等信息，如下圖：
使用jmap -heap pid查看進(jìn)程堆內(nèi)存使用情況，包括使用的GC算法、堆配置參數(shù)和各代中堆內(nèi)存使用情況。比如下面的例子：
root@ubuntu:/# jmap -heap 21711
Attaching to process ID 21711, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.10-b01
using thread-local object allocation.
Parallel GC with 4 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 2067791872 (1972.0MB)
NewSize = 1310720 (1.25MB)
MaxNewSize = 17592186044415 MB
OldSize = 5439488 (5.1875MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 21757952 (20.75MB)
MaxPermSize = 85983232 (82.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 6422528 (6.125MB)
used = 5445552 (5.1932830810546875MB)
free = 976976 (0.9317169189453125MB)
84.78829520089286% used
From Space:
capacity = 131072 (0.125MB)
used = 98304 (0.09375MB)
free = 32768 (0.03125MB)
75.0% used
To Space:
capacity = 131072 (0.125MB)
used = 0 (0.0MB)
free = 131072 (0.125MB)
0.0% used
PS Old Generation
capacity = 35258368 (33.625MB)
used = 4119544 (3.9287033081054688MB)
free = 31138824 (29.69629669189453MB)
11.683876009235595% used
PS Perm Generation
capacity = 52428800 (50.0MB)
used = 26075168 (24.867218017578125MB)
free = 26353632 (25.132781982421875MB)
49.73443603515625% used
....
使用jmap -histo[:live] pid查看堆內(nèi)存中的對(duì)象數(shù)目、大小統(tǒng)計(jì)直方圖，如果帶上live則只統(tǒng)計(jì)活對(duì)象，如下：
root@ubuntu:/# jmap -histo:live 21711 | more
num #instances #bytes class name----------------------------------------------
1: 38445 5597736 <constMethodKlass>
2: 38445 5237288 <methodKlass>
3: 3500 3749504 <constantPoolKlass>
4: 60858 3242600 <symbolKlass>
5: 3500 2715264 <instanceKlassKlass>
6: 2796 2131424 <constantPoolCacheKlass>
7: 5543 1317400 [I
8: 13714 1010768 [C
9: 4752 1003344 [B
10: 1225 639656 <methodDataKlass>
11: 14194 454208 java.lang.String
12: 3809 396136 java.lang.Class
13: 4979 311952 [S
14: 5598 287064 [[I
15: 3028 266464 java.lang.reflect.Method
16: 280 163520 <objArrayKlassKlass>
17: 4355 139360 java.util.HashMap$Entry
18: 1869 138568 [Ljava.util.HashMap$Entry;
19: 2443 97720 java.util.LinkedHashMap$Entry
20: 2072 82880 java.lang.ref.SoftReference
21: 1807 71528 [Ljava.lang.Object;
22: 2206 70592 java.lang.ref.WeakReference
23: 934 52304 java.util.LinkedHashMap
24: 871 48776 java.beans.MethodDescriptor
25: 1442 46144 java.util.concurrent.ConcurrentHashMap$HashEntry
26: 804 38592 java.util.HashMap
27: 948 37920 java.util.concurrent.ConcurrentHashMap$Segment
28: 1621 35696 [Ljava.lang.Class;
29: 1313 34880 [Ljava.lang.String;
30: 1396 33504 java.util.LinkedList$Entry
31: 462 33264 java.lang.reflect.Field
32: 1024 32768 java.util.Hashtable$Entry
33: 948 31440 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
class name是對(duì)象類型，說明如下：
還有一個(gè)很常用的情況是：用jmap把進(jìn)程內(nèi)存使用情況dump到文件中，再用jhat分析查看。jmap進(jìn)行dump命令格式如下：
dump出來的文件可以用MAT、VisualVM等工具查看，這里用jhat查看：
注意如果Dump文件太大，可能需要加上-J-Xmx512m這種參數(shù)指定最大堆內(nèi)存，即jhat -J-Xmx512m -port 9998 /tmp/dump.dat。然后就可以在瀏覽器中輸入主機(jī)地址:9998查看了：
上面紅線框出來的部分，最后一項(xiàng)支持OQL（對(duì)象查詢語言）。
日常開發(fā)中，代碼產(chǎn)生內(nèi)存泄漏是比較常見的事，并且比較隱蔽，需要開發(fā)者更加關(guān)注細(xì)節(jié)。比如說每次請(qǐng)求都new對(duì)象，導(dǎo)致大量重復(fù)創(chuàng)建對(duì)象；進(jìn)行文件流操作但未正確關(guān)閉；手動(dòng)不當(dāng)觸發(fā)gc；ByteBuffer緩存分配不合理等都會(huì)造成代碼OOM。
另一方面，我們可以在啟動(dòng)參數(shù)中指定-XX:+HeapDumpOnOutOfMemoryError來保存OOM時(shí)的dump文件。
gc問題和線程
gc問題除了影響cpu也會(huì)影響內(nèi)存，排查思路也是一致的。一般先使用jstat來查看分代變化情況，比如youngGC或者fullGC次數(shù)是不是太多呀；EU、OU等指標(biāo)增長是不是異常呀等。
搜索公眾號(hào)程序員小樂回復(fù)關(guān)鍵字“Java”獲取Java面試題和答案。
線程的話太多而且不被及時(shí)gc也會(huì)引發(fā)oom，大部分就是之前說的unable to create new native thread。除了jstack細(xì)細(xì)分析dump文件外，我們一般先會(huì)看下總體線程，通過pstreee -p pid |wc -l。
或者直接通過查看/proc/pid/task的數(shù)量即為線程數(shù)量。
堆外內(nèi)存
首先堆外內(nèi)存溢出表現(xiàn)就是物理常駐內(nèi)存增長快，報(bào)錯(cuò)的話視使用方式都不確定，如果由于使用Netty導(dǎo)致的，那錯(cuò)誤日志里可能會(huì)出現(xiàn)OutOfDirectMemoryError錯(cuò)誤，如果直接是DirectByteBuffer，那會(huì)報(bào)OutOfMemoryError: Direct buffer memory。
堆外內(nèi)存溢出往往是和NIO的使用相關(guān)，一般我們先通過pmap來查看下進(jìn)程占用的內(nèi)存情況pmap -x pid | sort -rn -k3 | head -30，這段意思是查看對(duì)應(yīng)pid倒序前30大的內(nèi)存段。這邊可以再一段時(shí)間后再跑一次命令看看內(nèi)存增長情況，或者和正常機(jī)器比較可疑的內(nèi)存段在哪里。
我們?nèi)绻_定有可疑的內(nèi)存端，需要通過gdb來分析gdb --batch --pid {pid} -ex “dump memory filename.dump {內(nèi)存起始地址} {內(nèi)存起始地址+內(nèi)存塊大小}”
獲取dump文件后可用heaxdump進(jìn)行查看hexdump -C filename | less，不過大多數(shù)看到的都是二進(jìn)制亂碼。
NMT是Java7U40引入的HotSpot新特性，配合jcmd命令我們就可以看到具體內(nèi)存組成了。需要在啟動(dòng)參數(shù)中加入 -XX:NativeMemoryTracking=summary 或者 -XX:NativeMemoryTracking=detail，會(huì)有略微性能損耗。
一般對(duì)于堆外內(nèi)存緩慢增長直到爆炸的情況來說，可以先設(shè)一個(gè)基線jcmd pid VM.native_memory baseline。
然后等放一段時(shí)間后再去看看內(nèi)存增長的情況，通過jcmd pid VM.native_memory detail.diff(summary.diff)做一下summary或者detail級(jí)別的diff。
可以看到j(luò)cmd分析出來的內(nèi)存十分詳細(xì)，包括堆內(nèi)、線程以及gc(所以上述其他內(nèi)存異常其實(shí)都可以用nmt來分析)，這邊堆外內(nèi)存我們重點(diǎn)關(guān)注Internal的內(nèi)存增長，如果增長十分明顯的話那就是有問題了。
detail級(jí)別的話還會(huì)有具體內(nèi)存段的增長情況，如下圖。
此外在系統(tǒng)層面，我們還可以使用strace命令來監(jiān)控內(nèi)存分配 strace -f -e “brk,mmap,munmap” -p pid
這邊內(nèi)存分配信息主要包括了pid和內(nèi)存地址。
不過其實(shí)上面那些操作也很難定位到具體的問題點(diǎn)，關(guān)鍵還是要看錯(cuò)誤日志棧，找到可疑的對(duì)象，搞清楚它的回收機(jī)制，然后去分析對(duì)應(yīng)的對(duì)象。比如DirectByteBuffer分配內(nèi)存的話，是需要full GC或者手動(dòng)system.gc來進(jìn)行回收的(所以最好不要使用-XX:+DisableExplicitGC)。
那么其實(shí)我們可以跟蹤一下DirectByteBuffer對(duì)象的內(nèi)存情況，通過jmap -histo:live pid手動(dòng)觸發(fā)fullGC來看看堆外內(nèi)存有沒有被回收。如果被回收了，那么大概率是堆外內(nèi)存本身分配的太小了，通過-XX:MaxDirectMemorySize進(jìn)行調(diào)整。如果沒有什么變化，那就要使用jmap去分析那些不能被gc的對(duì)象，以及和DirectByteBuffer之間的引用關(guān)系了。
網(wǎng)絡(luò)
涉及到網(wǎng)絡(luò)層面的問題一般都比較復(fù)雜，場(chǎng)景多，定位難，成為了大多數(shù)開發(fā)的噩夢(mèng)，應(yīng)該是最復(fù)雜的了。這里會(huì)舉一些例子，并從tcp層、應(yīng)用層以及工具的使用等方面進(jìn)行闡述。
超時(shí)錯(cuò)誤，大部分處在應(yīng)用層面，所以這塊著重理解概念。超時(shí)大體可以分為連接超時(shí)和讀寫超時(shí)，某些使用連接池的客戶端框架還會(huì)存在獲取連接超時(shí)和空閑連接清理超時(shí)。
我們?cè)谠O(shè)置各種超時(shí)時(shí)間中，需要確認(rèn)的是盡量保持客戶端的超時(shí)小于服務(wù)端的超時(shí)，以保證連接正常結(jié)束。
在實(shí)際開發(fā)中，我們關(guān)心最多的應(yīng)該是接口的讀寫超時(shí)了。
如何設(shè)置合理的接口超時(shí)是一個(gè)問題。如果接口超時(shí)設(shè)置的過長，那么有可能會(huì)過多地占用服務(wù)端的tcp連接。而如果接口設(shè)置的過短，那么接口超時(shí)就會(huì)非常頻繁。
服務(wù)端接口明明rt降低，但客戶端仍然一直超時(shí)又是另一個(gè)問題。這個(gè)問題其實(shí)很簡單，客戶端到服務(wù)端的鏈路包括網(wǎng)絡(luò)傳輸、排隊(duì)以及服務(wù)處理等，每一個(gè)環(huán)節(jié)都可能是耗時(shí)的原因。
TCP隊(duì)列溢出
tcp隊(duì)列溢出是個(gè)相對(duì)底層的錯(cuò)誤，它可能會(huì)造成超時(shí)、rst等更表層的錯(cuò)誤。因此錯(cuò)誤也更隱蔽，所以我們單獨(dú)說一說。
如上圖所示，這里有兩個(gè)隊(duì)列：syns queue(半連接隊(duì)列）、accept queue（全連接隊(duì)列）。三次握手，在server收到client的syn后，把消息放到syns queue，回復(fù)syn+ack給client，server收到client的ack，如果這時(shí)accept queue沒滿，那就從syns queue拿出暫存的信息放入accept queue中，否則按tcp_abort_on_overflow指示的執(zhí)行。
tcp_abort_on_overflow 0表示如果三次握手第三步的時(shí)候accept queue滿了那么server扔掉client發(fā)過來的ack。tcp_abort_on_overflow 1則表示第三步的時(shí)候如果全連接隊(duì)列滿了，server發(fā)送一個(gè)rst包給client，表示廢掉這個(gè)握手過程和這個(gè)連接，意味著日志里可能會(huì)有很多connection reset / connection reset by peer。
那么在實(shí)際開發(fā)中，我們?cè)趺茨芸焖俣ㄎ坏絫cp隊(duì)列溢出呢？
主動(dòng)代替FIN終止連接
一般來說，正常的連接關(guān)閉都是需要通過FIN報(bào)文實(shí)現(xiàn)，然而我們也可以用RST報(bào)文來代替FIN，表示直接終止連接。實(shí)際開發(fā)中，可設(shè)置SO_LINGER數(shù)值來控制，這種往往是故意的，來跳過TIMED_WAIT，提供交互效率，不閑就慎用。
客戶端或服務(wù)端有一邊發(fā)生了異常，該方向?qū)Χ税l(fā)送RST以告知關(guān)閉連接
我們上面講的tcp隊(duì)列溢出發(fā)送RST包其實(shí)也是屬于這一種。這種往往是由于某些原因，一方無法再能正常處理請(qǐng)求連接了(比如程序崩了，隊(duì)列滿了)，從而告知另一方關(guān)閉連接。
接收到的TCP報(bào)文不在已知的TCP連接內(nèi)
比如，一方機(jī)器由于網(wǎng)絡(luò)實(shí)在太差TCP報(bào)文失蹤了，另一方關(guān)閉了該連接，然后過了許久收到了之前失蹤的TCP報(bào)文，但由于對(duì)應(yīng)的TCP連接已不存在，那么會(huì)直接發(fā)一個(gè)RST包以便開啟新的連接。
一方長期未收到另一方的確認(rèn)報(bào)文，在一定時(shí)間或重傳次數(shù)后發(fā)出RST報(bào)文
這種大多也和網(wǎng)絡(luò)環(huán)境相關(guān)了，網(wǎng)絡(luò)環(huán)境差可能會(huì)導(dǎo)致更多的RST報(bào)文。
之前說過RST報(bào)文多會(huì)導(dǎo)致程序報(bào)錯(cuò)，在一個(gè)已關(guān)閉的連接上讀操作會(huì)報(bào)connection reset，而在一個(gè)已關(guān)閉的連接上寫操作則會(huì)報(bào)connection reset by peer。通常我們可能還會(huì)看到broken pipe錯(cuò)誤，這是管道層面的錯(cuò)誤，表示對(duì)已關(guān)閉的管道進(jìn)行讀寫，往往是在收到RST，報(bào)出connection reset錯(cuò)后繼續(xù)讀寫數(shù)據(jù)報(bào)的錯(cuò)，這個(gè)在glibc源碼注釋中也有介紹。
我們?cè)谂挪楣收蠒r(shí)候怎么確定有RST包的存在呢？當(dāng)然是使用tcpdump命令進(jìn)行抓包，并使用wireshark進(jìn)行簡單分析了。tcpdump -i en0 tcp -w xxx.cap，en0表示監(jiān)聽的網(wǎng)卡。
接下來我們通過wireshark打開抓到的包，可能就能看到如下圖所示，紅色的就表示RST包了。
TIME_WAIT和CLOSE_WAIT
TIME_WAIT和CLOSE_WAIT是啥意思相信大家都知道。
在線上時(shí)，我們可以直接用命令netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'來查看time-wait和close_wait的數(shù)量
用ss命令會(huì)更快ss -ant | awk ‘{++S[$1]} END {for(a in S) print a, S[a]}’
TIME_WAIT
time_wait的存在一是為了丟失的數(shù)據(jù)包被后面連接復(fù)用，二是為了在2MSL的時(shí)間范圍內(nèi)正常關(guān)閉連接。它的存在其實(shí)會(huì)大大減少RST包的出現(xiàn)。
過多的time_wait在短連接頻繁的場(chǎng)景比較容易出現(xiàn)。這種情況可以在服務(wù)端做一些內(nèi)核參數(shù)調(diào)優(yōu):
CLOSE_WAIT
close_wait往往都是因?yàn)閼?yīng)用程序?qū)懙挠袉栴}，沒有在ACK后再次發(fā)起FIN報(bào)文。close_wait出現(xiàn)的概率甚至比time_wait要更高，后果也更嚴(yán)重。往往是由于某個(gè)地方阻塞住了，沒有正常關(guān)閉連接，從而漸漸地消耗完所有的線程。
想要定位這類問題，最好是通過jstack來分析線程堆棧來排查問題，具體可參考上述章節(jié)。這里僅舉一個(gè)例子。
開發(fā)同學(xué)說應(yīng)用上線后CLOSE_WAIT就一直增多，直到掛掉為止，jstack后找到比較可疑的堆棧是大部分線程都卡在了countdownlatch.await方法，找開發(fā)同學(xué)了解后得知使用了多線程但是確沒有catch異常，修改后發(fā)現(xiàn)異常僅僅是最簡單的升級(jí)sdk后常出現(xiàn)的class not found。
GC
堆內(nèi)內(nèi)存泄漏總是和GC異常相伴。不過GC問題不只是和內(nèi)存問題相關(guān)，還有可能引起CPU負(fù)載、網(wǎng)絡(luò)問題等系列并發(fā)癥，只是相對(duì)來說和內(nèi)存聯(lián)系緊密些，所以我們?cè)诖藛为?dú)總結(jié)一下GC相關(guān)問題。
我們?cè)赾pu章介紹了使用jstat來獲取當(dāng)前GC分代變化信息。而更多時(shí)候，我們是通過GC日志來排查問題的，在啟動(dòng)參數(shù)中加上-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps來開啟GC日志。
常見的Young GC、Full GC日志含義在此就不做贅述了。
針對(duì)gc日志，我們就能大致推斷出youngGC與fullGC是否過于頻繁或者耗時(shí)過長，從而對(duì)癥下藥。我們下面將對(duì)G1垃圾收集器來做分析，這邊也建議大家使用G1-XX:+UseG1GC。
youngGC過頻繁
youngGC頻繁一般是短周期小對(duì)象較多，先考慮是不是Eden區(qū)/新生代設(shè)置的太小了，看能否通過調(diào)整-Xmn、-XX:SurvivorRatio等參數(shù)設(shè)置來解決問題。如果參數(shù)正常，但是young gc頻率還是太高，就需要使用Jmap和MAT對(duì)dump文件進(jìn)行進(jìn)一步排查了。
youngGC耗時(shí)過長
耗時(shí)過長問題就要看GC日志里耗時(shí)耗在哪一塊了。以G1日志為例，可以關(guān)注Root Scanning、Object Copy、Ref Proc等階段。Ref Proc耗時(shí)長，就要注意引用相關(guān)的對(duì)象。
搜索公眾號(hào)程序員小樂回復(fù)關(guān)鍵字“offer”獲取算法面試題和答案。
Root Scanning耗時(shí)長，就要注意線程數(shù)、跨代引用。Object Copy則需要關(guān)注對(duì)象生存周期。而且耗時(shí)分析它需要橫向比較，就是和其他項(xiàng)目或者正常時(shí)間段的耗時(shí)比較。比如說圖中的Root Scanning和正常時(shí)間段比增長較多，那就是起的線程太多了。
觸發(fā)fullGC
G1中更多的還是mixedGC，但mixedGC可以和youngGC思路一樣去排查。觸發(fā)fullGC了一般都會(huì)有問題，G1會(huì)退化使用Serial收集器來完成垃圾的清理工作，暫停時(shí)長達(dá)到秒級(jí)別，可以說是半跪了。
fullGC的原因可能包括以下這些，以及參數(shù)調(diào)整方面的一些思路：
并發(fā)階段失?。涸诓l(fā)標(biāo)記階段，MixGC之前老年代就被填滿了，那么這時(shí)候G1就會(huì)放棄標(biāo)記周期。這種情況，可能就需要增加堆大小，或者調(diào)整并發(fā)標(biāo)記線程數(shù)-XX:ConcGCThreads。
晉升失?。涸贕C的時(shí)候沒有足夠的內(nèi)存供存活/晉升對(duì)象使用，所以觸發(fā)了Full GC。這時(shí)候可以通過-XX:G1ReservePercent來增加預(yù)留內(nèi)存百分比，減少-XX:InitiatingHeapOccupancyPercent來提前啟動(dòng)標(biāo)記，-XX:ConcGCThreads來增加標(biāo)記線程數(shù)也是可以的。
大對(duì)象分配失敗：大對(duì)象找不到合適的region空間進(jìn)行分配，就會(huì)進(jìn)行fullGC，這種情況下可以增大內(nèi)存或者增大-XX:G1HeapRegionSize。
程序主動(dòng)執(zhí)行System.gc()：不要隨便寫就對(duì)了。
另外，我們可以在啟動(dòng)參數(shù)中配置-XX:HeapDumpPath=/xxx/dump.hprof來dump fullGC相關(guān)的文件，并通過jinfo來進(jìn)行g(shù)c前后的dump
最終優(yōu)化結(jié)果
1.基本監(jiān)控
2.GC
3.抽樣器cpu和內(nèi)存
==============================================================
Java性能調(diào)優(yōu)工具
上面的CPU/內(nèi)存等已經(jīng)了解了jstack和jmap
這介紹下其他工具
jps(Java Virtual Machine Process Status Tool)
jps主要用來輸出JVM中運(yùn)行的進(jìn)程狀態(tài)信息。語法格式如下：
hprof（Heap/CPU Profiling Tool）：
hprof能夠展現(xiàn)CPU使用率，統(tǒng)計(jì)堆內(nèi)存使用情況。
官方例子：
====================================================
JVM常用命令和參數(shù)
java啟動(dòng)參數(shù)共分為三類
其一是標(biāo)準(zhǔn)參數(shù)（ -），所有的JVM實(shí)現(xiàn)都必須實(shí)現(xiàn)這些參數(shù)的功能，而且向后兼容
其二是非標(biāo)準(zhǔn)參數(shù)（ -X），默認(rèn)jvm實(shí)現(xiàn)這些參數(shù)的功能，但是并不保證所有jvm實(shí)現(xiàn)都滿足，且不保證向后兼容
其三是非Stable參數(shù)（ -XX），此類參數(shù)各個(gè)jvm實(shí)現(xiàn)會(huì)有所不同，將來可能會(huì)隨時(shí)取消，需要慎重使用
打印啟動(dòng)參數(shù)
打印GC日志
不要用 XX:+UseGCLogFileRotation，這個(gè)會(huì)丟失舊的日志文件，而且重啟會(huì)覆蓋當(dāng)前日志文件：
-XX:+PrintGCDetails-XX:+PrintGCDateStamps-Xloggc:/home/GCEASY/gc.log -XX:+UseGCLogFileRotation-XX:NumberOfGCLogFiles=5-XX:GCLogFileSize=20M
應(yīng)該用
-XX:+PrintGCDetails-XX:+PrintGCDateStamps-Xloggc:/home/GCEASY/gc-%t.log
打印ClassLoader日志
8也是默認(rèn)的比例，不過這個(gè)比例在Parallel Scavenge（新生代并行回收器，JDK5以后的默認(rèn)新生代回收器）回收器下是動(dòng)態(tài)的，運(yùn)行時(shí)會(huì)出現(xiàn)Eden/Survivor比例和配置的不同。
設(shè)置永久代(PermGen/MetaSpace)大小
#設(shè)置分配給永久生成的空間，如果超出該空間，則會(huì)觸發(fā)垃圾回收。此選項(xiàng)在JDK 8中已棄用，并由-XX：MetaspaceSize選項(xiàng)取代。
-XX:PermSize=size
#設(shè)置最大永久生成空間大小（以字節(jié)為單位）。此選項(xiàng)在JDK 8中已棄用，并由-XX：MaxMetaspaceSize選項(xiàng)取代。
-XX:MaxPermSize=size
#設(shè)置分配的Metaspace的大小，Metaspace將在首次超過垃圾收集時(shí)觸發(fā)垃圾收集。垃圾收集的閾值取決于使用的元數(shù)據(jù)量而增加或減少。默認(rèn)大小取決于平臺(tái)。
-XX:MetaspaceSize=size
#設(shè)置可以分配給Metaspace的最大本機(jī)內(nèi)存。默認(rèn)情況下，大小不受限制。應(yīng)用程序的Metaspace量取決于應(yīng)用程序本身，其他正在運(yùn)行的應(yīng)用程序以及系統(tǒng)上可用的內(nèi)存量
-XX:MaxMetaspaceSize=size
初始大小和最大值的區(qū)別
初始值（比如 -Xms）為JVM啟動(dòng)是向操作系統(tǒng)申請(qǐng)的內(nèi)存大小( malloc)，最大值（比如 -Xmx）表示，當(dāng)使用的內(nèi)存超過初始值后擴(kuò)容的最大值
PS: JVM配置了多少內(nèi)存并不是說啟動(dòng)后就會(huì)占用多少物理內(nèi)存，因?yàn)椴僮飨到y(tǒng)的內(nèi)存分配是惰性的。對(duì)于已申請(qǐng)的內(nèi)存雖然會(huì)分配地址空間，但并不會(huì)直接占用物理內(nèi)存，真正使用的時(shí)候才會(huì)映射到實(shí)際的物理內(nèi)存。
GC類
這里說一下PermGen/Metaspace的GC，沒有查到官方資料說永久代的固定垃圾回收器，但是在stackoverflow上有人回答到：
所有垃圾回收器都會(huì)回收永久代，包括PS/CMS，但并不是每個(gè)GC周期都會(huì)清理永久代。
這個(gè)不用糾結(jié)，看GC日志里清理的信息即可。
JDK7
JAVA_MEM_OPTS=
" -server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 "
JAVA_DEBUG_OPTS=
" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/home/GCEASY/gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof -XX:OnOutOfMemoryError=/scripts/restart-myapp.sh "
JDK8
JAVA_MEM_OPTS=
" -server -Xmx2g -Xms2g -Xmn256m -XX:MetaspaceSize=256m -Xss1024m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 "
JAVA_DEBUG_OPTS=
" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/home/GCEASY/gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof -XX:OnOutOfMemoryError=/scripts/restart-myapp.sh "
關(guān)于G1，雖然說JDK8中已經(jīng)支持G1了，但是并不是說一定需要。
G1的重要特點(diǎn)是為用戶的應(yīng)用程序的提供一個(gè)低GC延時(shí)和大內(nèi)存GC的解決方案，適用于大內(nèi)存場(chǎng)景（官方推薦堆6G以上）
如果程序正在使用CMS或ParallelOld垃圾回收器，并且具有一個(gè)或多個(gè)以下特征，那么則可以考慮升級(jí)為G1：文章來源：http://www.zghlxwxcb.cn/news/detail-732657.html
- Full GC持續(xù)時(shí)間太長或太頻繁
- 對(duì)象分配率或年輕代升級(jí)老年代很頻繁
- 垃圾收集時(shí)間或壓縮暫停（超過0.5至1秒）時(shí)間過長
如果正在使用CMS或ParallelOld收集器，并且程序沒有遇到長時(shí)間的垃圾收集暫停，那么就不需要升級(jí)到G1文章來源地址http://www.zghlxwxcb.cn/news/detail-732657.html
到了這里，關(guān)于Java線上故障排查（CPU、磁盤、內(nèi)存、網(wǎng)絡(luò)、GC）+JVM性能調(diào)優(yōu)監(jiān)控工具+JVM常用參數(shù)和命令的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
