線上故障主要會包括cpu、磁盤渔工、內存以及網絡問題锌钮，而大多數(shù)故障可能會包含不止一個層面的問題，所以進行排查時候盡量四個方面依次排查一遍涨缚。同時例如jstack轧粟、jmap等工具也是不囿于一個方面的問題的，基本上出問題就是df脓魏、free兰吟、top 三連，然后依次jstack茂翔、jmap伺候混蔼，具體問題具體分析即可。
CPU
一般來講我們首先會排查cpu方面的問題珊燎。cpu異常往往還是比較好定位的惭嚣。原因包括業(yè)務邏輯問題(死循環(huán))、頻繁gc以及上下文切換過多悔政。而最常見的往往是業(yè)務邏輯(或者框架邏輯)導致的晚吞，可以使用jstack來分析對應的堆棧情況。
使用jstack分析cpu問題
我們先用ps命令找到對應進程的pid(如果你有好幾個目標進程谋国，可以先用top看一下哪個占用比較高)槽地。
接著用top -H -p pid來找到cpu使用率比較高的一些線程
然后將占用最高的pid轉換為16進制
printf '%x\n' pid得到nid
接著直接在jstack中找到相應的堆棧信息
jstack pid |grep 'nid' -C5 –color
可以看到我們已經找到了nid為0x42的堆棧信息，接著只要仔細分析一番即可芦瘾。
當然更常見的是我們對整個jstack文件進行分析捌蚊，通常我們會比較關注WAITING和TIMED_WAITING的部分，BLOCKED就不用說了近弟。我們可以使用命令cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c來對jstack的狀態(tài)有一個整體的把握缅糟，如果WAITING之類的特別多，那么多半是有問題啦祷愉。
頻繁gc
當然我們還是會使用jstack來分析問題窗宦，但有時候我們可以先確定下gc是不是太頻繁，使用jstat -gc pid 1000命令來對gc分代變化情況進行觀察谣辞，1000表示采樣間隔(ms)迫摔，S0C/S1C、S0U/S1U泥从、EC/EU句占、OC/OU、MC/MU分別代表兩個Survivor區(qū)躯嫉、Eden區(qū)纱烘、老年代、元數(shù)據(jù)區(qū)的容量和使用量祈餐。YGC/YGT擂啥、FGC/FGCT、GCT則代表YoungGc帆阳、FullGc的耗時和次數(shù)以及總耗時哺壶。如果看到gc比較頻繁，再針對gc方面做進一步分析，具體可以參考一下gc章節(jié)的描述山宾。
上下文切換
針對頻繁上下文問題至扰，我們可以使用vmstat命令來進行查看
cs(context switch)一列則代表了上下文切換的次數(shù)。
如果我們希望對特定的pid進行監(jiān)控那么可以使用
pidstat -w pid命令资锰，cswch和nvcswch表示自愿及非自愿切換敢课。
磁盤
磁盤問題和cpu一樣是屬于比較基礎的。首先是磁盤空間方面绷杜，我們直接使用df -hl來查看文件系統(tǒng)狀態(tài)
更多時候直秆，磁盤問題還是性能上的問題。我們可以通過iostatiostat -d -k -x來進行分析
最后一列
%util可以看到每塊磁盤寫入的程度鞭盟，而rrqpm/s以及wrqm/s分別表示讀寫速度圾结，一般就能幫助定位到具體哪塊磁盤出現(xiàn)問題了。
另外我們還需要知道是哪個進程在進行讀寫齿诉，一般來說開發(fā)自己心里有數(shù)疫稿，或者用iotop命令來進行定位文件讀寫的來源。
不過這邊拿到的是tid鹃两，我們要轉換成pid遗座，可以通過readlink來找到pid
readlink -f /proc/*/task/tid/../..。
找到pid之后就可以看這個進程具體的讀寫情況
cat /proc/pid/io
我們還可以通過lsof命令來確定具體的文件讀寫情況
lsof -p pid
內存
內存問題排查起來相對比CPU麻煩一些俊扳，場景也比較多途蒋。主要包括OOM、GC問題和堆外內存馋记。一般來講号坡，我們會先用free命令先來檢查一發(fā)內存的各種情況。
堆內內存
內存問題大多還都是堆內內存問題梯醒。表象上主要分為OOM和StackOverflow宽堆。
OOM
JMV中的內存不足，OOM大致可以分為以下幾種：
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
這個意思是沒有足夠的內存空間給線程分配java棧茸习，基本上還是線程池代碼寫的有問題畜隶，比如說忘記shutdown，所以說應該首先從代碼層面來尋找問題号胚，使用jstack或者jmap籽慢。如果一切都正常，JVM方面可以通過指定Xss來減少單個thread stack的大小猫胁。另外也可以在系統(tǒng)層面箱亿，可以通過修改/etc/security/limits.confnofile和nproc來增大os對線程的限制
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
這個意思是堆的內存占用已經達到-Xmx設置的最大值，應該是最常見的OOM錯誤了弃秆。解決思路仍然是先應該在代碼中找届惋，懷疑存在內存泄漏髓帽，通過jstack和jmap去定位問題。如果說一切都正常脑豹，才需要通過調整Xmx的值來擴大內存氢卡。
Caused by: java.lang.OutOfMemoryError: Meta space
這個意思是元數(shù)據(jù)區(qū)的內存占用已經達到XX:MaxMetaspaceSize設置的最大值，排查思路和上面的一致晨缴，參數(shù)方面可以通過XX:MaxPermSize來進行調整(這里就不說1.8以前的永久代了)。
Stack Overflow
棧內存溢出峡捡，這個大家見到也比較多击碗。
Exception in thread "main" java.lang.StackOverflowError
表示線程棧需要的內存大于Xss值，同樣也是先進行排查们拙，參數(shù)方面通過Xss來調整稍途，但調整的太大可能又會引起OOM。
使用JMAP定位代碼內存泄漏
上述關于OOM和StackOverflow的代碼排查方面砚婆，我們一般使用JMAPjmap -dump:format=b,file=filename pid來導出dump文件
通過mat(Eclipse Memory Analysis Tools)導入dump文件進行分析械拍，內存泄漏問題一般我們直接選Leak Suspects即可，mat給出了內存泄漏的建議装盯。另外也可以選擇Top Consumers來查看最大對象報告坷虑。和線程相關的問題可以選擇thread overview進行分析。除此之外就是選擇Histogram類概覽來自己慢慢分析埂奈，大家可以搜搜mat的相關教程迄损。
日常開發(fā)中，代碼產生內存泄漏是比較常見的事账磺，并且比較隱蔽芹敌，需要開發(fā)者更加關注細節(jié)。比如說每次請求都new對象垮抗，導致大量重復創(chuàng)建對象氏捞；進行文件流操作但未正確關閉；手動不當觸發(fā)gc冒版；ByteBuffer緩存分配不合理等都會造成代碼OOM液茎。
另一方面，我們可以在啟動參數(shù)中指定-XX:+HeapDumpOnOutOfMemoryError來保存OOM時的dump文件辞嗡。
gc問題和線程
gc問題除了影響cpu也會影響內存豁护，排查思路也是一致的。一般先使用jstat來查看分代變化情況欲间，比如youngGC或者fullGC次數(shù)是不是太多呀楚里；EU、OU等指標增長是不是異常呀等猎贴。
線程的話太多而且不被及時gc也會引發(fā)oom班缎，大部分就是之前說的unable to create new native thread蝴光。除了jstack細細分析dump文件外，我們一般先會看下總體線程达址，通過pstreee -p pid |wc -l蔑祟。
或者直接通過查看
/proc/pid/task的數(shù)量即為線程數(shù)量。
堆外內存
如果碰到堆外內存溢出沉唠，那可真是太不幸了疆虚。首先堆外內存溢出表現(xiàn)就是物理常駐內存增長快，報錯的話視使用方式都不確定满葛，如果由于使用Netty導致的径簿，那錯誤日志里可能會出現(xiàn)OutOfDirectMemoryError錯誤，如果直接是DirectByteBuffer嘀韧，那會報OutOfMemoryError: Direct buffer memory篇亭。
堆外內存溢出往往是和NIO的使用相關，一般我們先通過pmap來查看下進程占用的內存情況pmap -x pid | sort -rn -k3 | head -30锄贷，這段意思是查看對應pid倒序前30大的內存段译蒂。這邊可以再一段時間后再跑一次命令看看內存增長情況，或者和正常機器比較可疑的內存段在哪里谊却。
我們如果確定有可疑的內存端柔昼，需要通過gdb來分析
gdb --batch --pid {pid} -ex "dump memory filename.dump {內存起始地址} {內存起始地址+內存塊大小}"
獲取dump文件后可用heaxdump進行查看
hexdump -C filename | less，不過大多數(shù)看到的都是二進制亂碼炎辨。
NMT是Java7U40引入的HotSpot新特性岳锁，配合jcmd命令我們就可以看到具體內存組成了。需要在啟動參數(shù)中加入 -XX:NativeMemoryTracking=summary 或者 -XX:NativeMemoryTracking=detail蹦魔，會有略微性能損耗激率。
一般對于堆外內存緩慢增長直到爆炸的情況來說，可以先設一個基線jcmd pid VM.native_memory baseline勿决。
然后等放一段時間后再去看看內存增長的情況乒躺，通過
jcmd pid VM.native_memory detail.diff(summary.diff)做一下summary或者detail級別的diff。
可以看到jcmd分析出來的內存十分詳細低缩，包括堆內嘉冒、線程以及gc(所以上述其他內存異常其實都可以用nmt來分析)，這邊堆外內存我們重點關注Internal的內存增長咆繁，如果增長十分明顯的話那就是有問題了讳推。
detail級別的話還會有具體內存段的增長情況，如下圖玩般。
此外在系統(tǒng)層面银觅，我們還可以使用strace命令來監(jiān)控內存分配 strace -f -e "brk,mmap,munmap" -p pid
這邊內存分配信息主要包括了pid和內存地址。
不過其實上面那些操作也很難定位到具體的問題點坏为，關鍵還是要看錯誤日志棧究驴，找到可疑的對象镊绪，搞清楚它的回收機制，然后去分析對應的對象洒忧。比如DirectByteBuffer分配內存的話蝴韭，是需要full GC或者手動system.gc來進行回收的(所以最好不要使用-XX:+DisableExplicitGC)。那么其實我們可以跟蹤一下DirectByteBuffer對象的內存情況熙侍，通過jmap -histo:live pid手動觸發(fā)fullGC來看看堆外內存有沒有被回收榄鉴。如果被回收了，那么大概率是堆外內存本身分配的太小了蛉抓，通過-XX:MaxDirectMemorySize進行調整庆尘。如果沒有什么變化，那就要使用jmap去分析那些不能被gc的對象芝雪，以及和DirectByteBuffer之間的引用關系了。
GC問題
堆內內存泄漏總是和GC異常相伴综苔。不過GC問題不只是和內存問題相關惩系，還有可能引起CPU負載、網絡問題等系列并發(fā)癥如筛，只是相對來說和內存聯(lián)系緊密些堡牡，所以我們在此單獨總結一下GC相關問題。
我們在cpu章介紹了使用jstat來獲取當前GC分代變化信息杨刨。而更多時候晤柄，我們是通過GC日志來排查問題的，在啟動參數(shù)中加上-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps來開啟GC日志妖胀。
常見的Young GC芥颈、Full GC日志含義在此就不做贅述了。
針對gc日志赚抡，我們就能大致推斷出youngGC與fullGC是否過于頻繁或者耗時過長爬坑，從而對癥下藥。我們下面將對G1垃圾收集器來做分析涂臣，這邊也建議大家使用G1-XX:+UseG1GC盾计。
youngGC過頻繁
youngGC頻繁一般是短周期小對象較多，先考慮是不是Eden區(qū)/新生代設置的太小了赁遗，看能否通過調整-Xmn署辉、-XX:SurvivorRatio等參數(shù)設置來解決問題。如果參數(shù)正常岩四，但是young gc頻率還是太高哭尝，就需要使用Jmap和MAT對dump文件進行進一步排查了。
youngGC耗時過長
耗時過長問題就要看GC日志里耗時耗在哪一塊了剖煌。以G1日志為例刚夺，可以關注Root Scanning献丑、Object Copy、Ref Proc等階段侠姑。Ref Proc耗時長创橄，就要注意引用相關的對象。Root Scanning耗時長莽红，就要注意線程數(shù)妥畏、跨代引用。Object Copy則需要關注對象生存周期安吁。而且耗時分析它需要橫向比較醉蚁，就是和其他項目或者正常時間段的耗時比較。比如說圖中的Root Scanning和正常時間段比增長較多鬼店，那就是起的線程太多了网棍。
觸發(fā)fullGC
G1中更多的還是mixedGC，但mixedGC可以和youngGC思路一樣去排查妇智。觸發(fā)fullGC了一般都會有問題滥玷，G1會退化使用Serial收集器來完成垃圾的清理工作，暫停時長達到秒級別巍棱，可以說是半跪了惑畴。
fullGC的原因可能包括以下這些，以及參數(shù)調整方面的一些思路：
- 并發(fā)階段失敽结恪：在并發(fā)標記階段如贷，MixGC之前老年代就被填滿了，那么這時候G1就會放棄標記周期到踏。這種情況杠袱，可能就需要增加堆大小，或者調整并發(fā)標記線程數(shù)
-XX:ConcGCThreads窝稿。 - 晉升失斚疾簟：在GC的時候沒有足夠的內存供存活/晉升對象使用，所以觸發(fā)了Full GC讹躯。這時候可以通過
-XX:G1ReservePercent來增加預留內存百分比菩彬，減少-XX:InitiatingHeapOccupancyPercent來提前啟動標記，-XX:ConcGCThreads來增加標記線程數(shù)也是可以的潮梯。 - 大對象分配失斀竺：大對象找不到合適的region空間進行分配锣尉，就會進行fullGC撕贞，這種情況下可以增大內存或者增大
-XX:G1HeapRegionSize唆涝。 - 程序主動執(zhí)行System.gc()：不要隨便寫就對了。
另外萝究，我們可以在啟動參數(shù)中配置-XX:HeapDumpPath=/xxx/dump.hprof來dump fullGC相關的文件免都，并通過jinfo來進行gc前后的dump
jinfo -flag +HeapDumpBeforeFullGC pid
jinfo -flag +HeapDumpAfterFullGC pid
這樣得到2份dump文件锉罐，對比后主要關注被gc掉的問題對象來定位問題。
網絡
涉及到網絡層面的問題一般都比較復雜绕娘，場景多脓规，定位難，成為了大多數(shù)開發(fā)的噩夢险领，應該是最復雜的了侨舆。這里會舉一些例子，并從tcp層绢陌、應用層以及工具的使用等方面進行闡述挨下。
超時
超時錯誤大部分處在應用層面，所以這塊著重理解概念脐湾。超時大體可以分為連接超時和讀寫超時臭笆，某些使用連接池的客戶端框架還會存在獲取連接超時和空閑連接清理超時。
讀寫超時秤掌。readTimeout/writeTimeout愁铺，有些框架叫做so_timeout或者socketTimeout，均指的是數(shù)據(jù)讀寫超時机杜。注意這邊的超時大部分是指邏輯上的超時帜讲。soa的超時指的也是讀超時衅谷。讀寫超時一般都只針對客戶端設置椒拗。
連接超時。connectionTimeout获黔，客戶端通常指與服務端建立連接的最大時間蚀苛。服務端這邊connectionTimeout就有些五花八門了，jetty中表示空閑連接清理時間玷氏，tomcat則表示連接維持的最大時間堵未。
其他。包括連接獲取超時connectionAcquireTimeout和空閑連接清理超時idleConnectionTimeout盏触。多用于使用連接池或隊列的客戶端或服務端框架渗蟹。
我們在設置各種超時時間中，需要確認的是盡量保持客戶端的超時小于服務端的超時赞辩，以保證連接正常結束雌芽。
在實際開發(fā)中，我們關心最多的應該是接口的讀寫超時了辨嗽。
如何設置合理的接口超時是一個問題世落。如果接口超時設置的過長，那么有可能會過多地占用服務端的tcp連接糟需。而如果接口設置的過短屉佳，那么接口超時就會非常頻繁谷朝。
服務端接口明明rt降低，但客戶端仍然一直超時又是另一個問題武花。這個問題其實很簡單圆凰，客戶端到服務端的鏈路包括網絡傳輸、排隊以及服務處理等髓堪，每一個環(huán)節(jié)都可能是耗時的原因送朱。
TCP隊列溢出
tcp隊列溢出是個相對底層的錯誤，它可能會造成超時干旁、rst等更表層的錯誤驶沼。因此錯誤也更隱蔽，所以我們單獨說一說争群。
如上圖所示回怜，這里有兩個隊列：syns queue(半連接隊列）、accept queue（全連接隊列）换薄。三次握手玉雾，在server收到client的syn后，把消息放到syns queue轻要，回復syn+ack給client复旬，server收到client的ack，如果這時accept queue沒滿冲泥，那就從syns queue拿出暫存的信息放入accept queue中驹碍，否則按tcp_abort_on_overflow指示的執(zhí)行。
tcp_abort_on_overflow 0表示如果三次握手第三步的時候accept queue滿了那么server扔掉client發(fā)過來的ack凡恍。tcp_abort_on_overflow 1則表示第三步的時候如果全連接隊列滿了志秃，server發(fā)送一個rst包給client，表示廢掉這個握手過程和這個連接嚼酝，意味著日志里可能會有很多connection reset / connection reset by peer浮还。
那么在實際開發(fā)中，我們怎么能快速定位到tcp隊列溢出呢闽巩？
netstat命令钧舌，執(zhí)行netstat -s | egrep "listen|LISTEN"
如上圖所示，overflowed表示全連接隊列溢出的次數(shù)涎跨，sockets dropped表示半連接隊列溢出的次數(shù)洼冻。
ss命令，執(zhí)行ss -lnt
上面看到Send-Q 表示第三列的listen端口上的全連接隊列最大為5六敬，第一列Recv-Q為全連接隊列當前使用了多少碘赖。
接著我們看看怎么設置全連接、半連接隊列大小吧：
全連接隊列的大小取決于min(backlog, somaxconn)。backlog是在socket創(chuàng)建的時候傳入的普泡，somaxconn是一個os級別的系統(tǒng)參數(shù)播掷。而半連接隊列的大小取決于max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)。
在日常開發(fā)中撼班，我們往往使用servlet容器作為服務端歧匈，所以我們有時候也需要關注容器的連接隊列大小。在tomcat中backlog叫做acceptCount砰嘁，在jetty里面則是acceptQueueSize件炉。
RST異常
RST包表示連接重置，用于關閉一些無用的連接矮湘，通常表示異常關閉斟冕，區(qū)別于四次揮手。
在實際開發(fā)中缅阳，我們往往會看到connection reset / connection reset by peer錯誤磕蛇，這種情況就是RST包導致的。
端口不存在
如果像不存在的端口發(fā)出建立連接SYN請求十办，那么服務端發(fā)現(xiàn)自己并沒有這個端口則會直接返回一個RST報文秀撇，用于中斷連接。
主動代替FIN終止連接
一般來說向族，正常的連接關閉都是需要通過FIN報文實現(xiàn)呵燕，然而我們也可以用RST報文來代替FIN，表示直接終止連接件相。實際開發(fā)中再扭，可設置SO_LINGER數(shù)值來控制，這種往往是故意的适肠，來跳過TIMED_WAIT霍衫，提供交互效率候引，不閑就慎用侯养。
客戶端或服務端有一邊發(fā)生了異常，該方向對端發(fā)送RST以告知關閉連接
我們上面講的tcp隊列溢出發(fā)送RST包其實也是屬于這一種澄干。這種往往是由于某些原因逛揩，一方無法再能正常處理請求連接了(比如程序崩了，隊列滿了)麸俘，從而告知另一方關閉連接辩稽。
接收到的TCP報文不在已知的TCP連接內
比如，一方機器由于網絡實在太差TCP報文失蹤了从媚，另一方關閉了該連接逞泄，然后過了許久收到了之前失蹤的TCP報文，但由于對應的TCP連接已不存在，那么會直接發(fā)一個RST包以便開啟新的連接喷众。
一方長期未收到另一方的確認報文各谚，在一定時間或重傳次數(shù)后發(fā)出RST報文
這種大多也和網絡環(huán)境相關了，網絡環(huán)境差可能會導致更多的RST報文到千。
之前說過RST報文多會導致程序報錯昌渤，在一個已關閉的連接上讀操作會報connection reset，而在一個已關閉的連接上寫操作則會報connection reset by peer憔四。通常我們可能還會看到broken pipe錯誤膀息，這是管道層面的錯誤，表示對已關閉的管道進行讀寫了赵，往往是在收到RST潜支，報出connection reset錯后繼續(xù)讀寫數(shù)據(jù)報的錯，這個在glibc源碼注釋中也有介紹柿汛。
我們在排查故障時候怎么確定有RST包的存在呢毁腿？當然是使用tcpdump命令進行抓包，并使用wireshark進行簡單分析了苛茂。tcpdump -i en0 tcp -w xxx.cap已烤，en0表示監(jiān)聽的網卡。
接下來我們通過wireshark打開抓到的包妓羊，可能就能看到如下圖所示胯究，紅色的就表示RST包了。
TIME_WAIT和CLOSE_WAIT
TIME_WAIT和CLOSE_WAIT是啥意思相信大家都知道躁绸。
在線上時裕循，我們可以直接用命令netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'來查看time-wait和close_wait的數(shù)量
用ss命令會更快ss -ant | awk '{++S[$1]} END {for(a in S) print a, S[a]}'
TIME_WAIT
time_wait的存在一是為了丟失的數(shù)據(jù)包被后面連接復用，二是為了在2MSL的時間范圍內正常關閉連接净刮。它的存在其實會大大減少RST包的出現(xiàn)剥哑。
過多的time_wait在短連接頻繁的場景比較容易出現(xiàn)。這種情況可以在服務端做一些內核參數(shù)調優(yōu):
#表示開啟重用淹父。允許將TIME-WAIT sockets重新用于新的TCP連接株婴，默認為0，表示關閉
net.ipv4.tcp_tw_reuse = 1
#表示開啟TCP連接中TIME-WAIT sockets的快速回收暑认，默認為0困介，表示關閉
net.ipv4.tcp_tw_recycle = 1
當然我們不要忘記在NAT環(huán)境下因為時間戳錯亂導致數(shù)據(jù)包被拒絕的坑了，另外的辦法就是改小tcp_max_tw_buckets蘸际，超過這個數(shù)的time_wait都會被干掉座哩，不過這也會導致報time wait bucket table overflow的錯。
CLOSE_WAIT
close_wait往往都是因為應用程序寫的有問題粮彤，沒有在ACK后再次發(fā)起FIN報文根穷。close_wait出現(xiàn)的概率甚至比time_wait要更高姜骡，后果也更嚴重。往往是由于某個地方阻塞住了屿良，沒有正常關閉連接溶浴，從而漸漸地消耗完所有的線程。
想要定位這類問題管引，最好是通過jstack來分析線程堆棧來排查問題士败，具體可參考上述章節(jié)。這里僅舉一個例子褥伴。
開發(fā)同學說應用上線后CLOSE_WAIT就一直增多谅将，直到掛掉為止，jstack后找到比較可疑的堆棧是大部分線程都卡在了countdownlatch.await方法重慢，找開發(fā)同學了解后得知使用了多線程但是確沒有catch異常饥臂，修改后發(fā)現(xiàn)異常僅僅是最簡單的升級sdk后常出現(xiàn)的class not found。
