線上故障主要會(huì)包括cpu、磁盤以政、內(nèi)存以及網(wǎng)絡(luò)問(wèn)題鞭执，而大多數(shù)故障可能會(huì)包含不止一個(gè)層面的問(wèn)題司顿，所以進(jìn)行排查時(shí)候盡量四個(gè)方面依次排查一遍。同時(shí)例如jstack蚕冬、jmap等工具也是不囿于一個(gè)方面的問(wèn)題的免猾，基本上出問(wèn)題就是df是辕、free囤热、top 三連，然后依次jstack获三、jmap伺候旁蔼，具體問(wèn)題具體分析即可。

CPU

一般來(lái)講我們首先會(huì)排查cpu方面的問(wèn)題疙教。cpu異常往往還是比較好定位的棺聊。原因包括業(yè)務(wù)邏輯問(wèn)題(死循環(huán))、頻繁gc以及上下文切換過(guò)多贞谓。而最常見的往往是業(yè)務(wù)邏輯(或者框架邏輯)導(dǎo)致的限佩，可以使用jstack來(lái)分析對(duì)應(yīng)的堆棧情況。

使用jstack分析cpu問(wèn)題

我們先用ps命令找到對(duì)應(yīng)進(jìn)程的pid(如果你有好幾個(gè)目標(biāo)進(jìn)程，可以先用top看一下哪個(gè)占用比較高)祟同。

接著用top -H -p pid來(lái)找到cpu使用率比較高的一些線程

image

然后將占用最高的pid轉(zhuǎn)換為16進(jìn)制printf '%x\n' pid得到nid

image

接著直接在jstack中找到相應(yīng)的堆棧信息jstack pid |grep 'nid' -C5 –color

image

可以看到我們已經(jīng)找到了nid為0x42的堆棧信息作喘，接著只要仔細(xì)分析一番即可。

當(dāng)然更常見的是我們對(duì)整個(gè)jstack文件進(jìn)行分析晕城，通常我們會(huì)比較關(guān)注WAITING和TIMED_WAITING的部分泞坦，BLOCKED就不用說(shuō)了。我們可以使用命令cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c來(lái)對(duì)jstack的狀態(tài)有一個(gè)整體的把握砖顷，如果WAITING之類的特別多贰锁，那么多半是有問(wèn)題啦

image

頻繁gc

當(dāng)然我們還是會(huì)使用jstack來(lái)分析問(wèn)題，但有時(shí)候我們可以先確定下gc是不是太頻繁滤蝠，使用jstat -gc pid 1000命令來(lái)對(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)一步分析

image

上下文切換

針對(duì)頻繁上下文問(wèn)題际邻，我們可以使用vmstat命令來(lái)進(jìn)行查看

image

cs(context switch)一列則代表了上下文切換的次數(shù)。

如果我們希望對(duì)特定的pid進(jìn)行監(jiān)控那么可以使用 pidstat -w pid命令芍阎，cswch和nvcswch表示自愿及非自愿切換

image

磁盤

磁盤問(wèn)題和cpu一樣是屬于比較基礎(chǔ)的世曾。首先是磁盤空間方面，我們直接使用df -hl來(lái)查看文件系統(tǒng)狀態(tài)

image

更多時(shí)候谴咸，磁盤問(wèn)題還是性能上的問(wèn)題轮听。我們可以通過(guò)iostatiostat -d -k -x來(lái)進(jìn)行分析

image

最后一列%util可以看到每塊磁盤寫入的程度，而rrqpm/s以及wrqm/s分別表示讀寫速度岭佳，一般就能幫助定位到具體哪塊磁盤出現(xiàn)問(wèn)題了血巍。

另外我們還需要知道是哪個(gè)進(jìn)程在進(jìn)行讀寫，一般來(lái)說(shuō)開發(fā)自己心里有數(shù)珊随，或者用iotop命令來(lái)進(jìn)行定位文件讀寫的來(lái)源述寡。

image

不過(guò)這邊拿到的是tid柿隙，我們要轉(zhuǎn)換成pid，可以通過(guò)readlink來(lái)找到pidreadlink -f /proc/*/task/tid/../..鲫凶。

image

找到pid之后就可以看這個(gè)進(jìn)程具體的讀寫情況cat /proc/pid/io

image

我們還可以通過(guò)lsof命令來(lái)確定具體的文件讀寫情況lsof -p pid

image

內(nèi)存

內(nèi)存問(wèn)題排查起來(lái)相對(duì)比CPU麻煩一些优俘，場(chǎng)景也比較多。主要包括OOM掀序、GC問(wèn)題和堆外內(nèi)存帆焕。一般來(lái)講，我們會(huì)先用free命令先來(lái)檢查一發(fā)內(nèi)存的各種情況不恭。

image

堆內(nèi)內(nèi)存

內(nèi)存問(wèn)題大多還都是堆內(nèi)內(nèi)存問(wèn)題叶雹。表象上主要分為OOM和StackOverflow。

OOM

JMV中的內(nèi)存不足换吧，OOM大致可以分為以下幾種：

Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread

這個(gè)意思是沒有足夠的內(nèi)存空間給線程分配java棧折晦，基本上還是線程池代碼寫的有問(wèn)題，比如說(shuō)忘記shutdown沾瓦，所以說(shuō)應(yīng)該首先從代碼層面來(lái)尋找問(wèn)題满着，使用jstack或者jmap。如果一切都正常贯莺，JVM方面可以通過(guò)指定Xss來(lái)減少單個(gè)thread stack的大小风喇。另外也可以在系統(tǒng)層面，可以通過(guò)修改/etc/security/limits.confnofile和nproc來(lái)增大os對(duì)線程的限制

image

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)存泄漏爹耗，通過(guò)jstack和jmap去定位問(wèn)題耙考。如果說(shuō)一切都正常，才需要通過(guò)調(diào)整Xmx的值來(lái)擴(kuò)大內(nèi)存潭兽。

Caused by: java.lang.OutOfMemoryError: Meta space

這個(gè)意思是元數(shù)據(jù)區(qū)的內(nèi)存占用已經(jīng)達(dá)到XX:MaxMetaspaceSize設(shè)置的最大值倦始，排查思路和上面的一致，參數(shù)方面可以通過(guò)XX:MaxPermSize來(lái)進(jìn)行調(diào)整(這里就不說(shuō)1.8以前的永久代了)山卦。

Stack Overflow
棧內(nèi)存溢出鞋邑，這個(gè)大家見到也比較多。

Exception in thread "main" java.lang.StackOverflowError

表示線程棧需要的內(nèi)存大于Xss值怒坯，同樣也是先進(jìn)行排查炫狱，參數(shù)方面通過(guò)Xss來(lái)調(diào)整，但調(diào)整的太大可能又會(huì)引起OOM剔猿。

使用JMAP定位代碼內(nèi)存泄漏

上述關(guān)于OOM和StackOverflow的代碼排查方面，我們一般使用JMAPjmap -dump:format=b,file=filename pid來(lái)導(dǎo)出dump文件

image

通過(guò)mat(Eclipse Memory Analysis Tools)導(dǎo)入dump文件進(jìn)行分析嬉荆，內(nèi)存泄漏問(wèn)題一般我們直接選Leak Suspects即可归敬，mat給出了內(nèi)存泄漏的建議。另外也可以選擇Top Consumers來(lái)查看最大對(duì)象報(bào)告。和線程相關(guān)的問(wèn)題可以選擇thread overview進(jìn)行分析汪茧。除此之外就是選擇Histogram類概覽來(lái)自己慢慢分析椅亚，大家可以搜搜mat的相關(guān)教程。

image

日常開發(fā)中舱污，代碼產(chǎn)生內(nèi)存泄漏是比較常見的事呀舔，并且比較隱蔽，需要開發(fā)者更加關(guān)注細(xì)節(jié)扩灯。比如說(shuō)每次請(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來(lái)保存OOM時(shí)的dump文件磨隘。

gc問(wèn)題和線程

gc問(wèn)題除了影響cpu也會(huì)影響內(nèi)存，排查思路也是一致的顾患。一般先使用jstat來(lái)查看分代變化情況番捂，比如youngGC或者fullGC次數(shù)是不是太多呀；EU江解、OU等指標(biāo)增長(zhǎng)是不是異常呀等白嘁。

線程的話太多而且不被及時(shí)gc也會(huì)引發(fā)oom，大部分就是之前說(shuō)的unable to create new native thread膘流。除了jstack細(xì)細(xì)分析dump文件外絮缅，我們一般先會(huì)看下總體線程，通過(guò)pstreee -p pid |wc -l

image

或者直接通過(guò)查看/proc/pid/task的數(shù)量即為線程數(shù)量呼股。

image

堆外內(nèi)存

如果碰到堆外內(nèi)存溢出耕魄，那可真是太不幸了。首先堆外內(nèi)存溢出表現(xiàn)就是物理常駐內(nèi)存增長(zhǎng)快彭谁，報(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)狭园，一般我們先通過(guò)pmap來(lái)查看下進(jìn)程占用的內(nèi)存情況pmap -x pid | sort -rn -k3 | head -30读处，這段意思是查看對(duì)應(yīng)pid倒序前30大的內(nèi)存段。這邊可以再一段時(shí)間后再跑一次命令看看內(nèi)存增長(zhǎng)情況唱矛，或者和正常機(jī)器比較可疑的內(nèi)存段在哪里罚舱。

image

我們?nèi)绻_定有可疑的內(nèi)存端井辜，需要通過(guò)gdb來(lái)分析gdb --batch --pid {pid} -ex "dump memory filename.dump {內(nèi)存起始地址} {內(nèi)存起始地址+內(nèi)存塊大小}"

JAVA線上故障排查全套路
獲取dump文件后可用heaxdump進(jìn)行查看hexdump -C filename | less，不過(guò)大多數(shù)看到的都是二進(jìn)制亂碼管闷。

NMT是Java7U40引入的HotSpot新特性粥脚，配合jcmd命令我們就可以看到具體內(nèi)存組成了。需要在啟動(dòng)參數(shù)中加入 -XX:NativeMemoryTracking=summary或者-XX:NativeMemoryTracking=detail包个，會(huì)有略微性能損耗刷允。

一般對(duì)于堆外內(nèi)存緩慢增長(zhǎng)直到爆炸的情況來(lái)說(shuō)，可以先設(shè)一個(gè)基線jcmd pid VM.native_memory baseline碧囊。

image

然后等放一段時(shí)間后再去看看內(nèi)存增長(zhǎng)的情況树灶，通過(guò)jcmd pid VM.native_memory detail.diff(summary.diff)做一下summary或者detail級(jí)別的diff。

image

image

可以看到j(luò)cmd分析出來(lái)的內(nèi)存十分詳細(xì)呕臂，包括堆內(nèi)破托、線程以及gc(所以上述其他內(nèi)存異常其實(shí)都可以用nmt來(lái)分析)，這邊堆外內(nèi)存我們重點(diǎn)關(guān)注Internal的內(nèi)存增長(zhǎng)歧蒋，如果增長(zhǎng)十分明顯的話那就是有問(wèn)題了土砂。

detail級(jí)別的話還會(huì)有具體內(nèi)存段的增長(zhǎng)情況，如下圖

image

此外在系統(tǒng)層面谜洽，我們還可以使用strace命令來(lái)監(jiān)控內(nèi)存分配 strace -f -e "brk,mmap,munmap" -p pid

這邊內(nèi)存分配信息主要包括了pid和內(nèi)存地址
!](https://upload-images.jianshu.io/upload_images/24195226-fad2079075a282c3?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
不過(guò)其實(shí)上面那些操作也很難定位到具體的問(wèn)題點(diǎn)萝映，關(guān)鍵還是要看錯(cuò)誤日志棧，找到可疑的對(duì)象阐虚，搞清楚它的回收機(jī)制序臂，然后去分析對(duì)應(yīng)的對(duì)象。比如DirectByteBuffer分配內(nèi)存的話实束，是需要full GC或者手動(dòng)system.gc來(lái)進(jìn)行回收的(所以最好不要使用-XX:+DisableExplicitGC)奥秆。那么其實(shí)我們可以跟蹤一下DirectByteBuffer對(duì)象的內(nèi)存情況，通過(guò)jmap -histo:live pid手動(dòng)觸發(fā)fullGC來(lái)看看堆外內(nèi)存有沒有被回收咸灿。如果被回收了构订，那么大概率是堆外內(nèi)存本身分配的太小了，通過(guò)-XX:MaxDirectMemorySize進(jìn)行調(diào)整避矢。如果沒有什么變化悼瘾，那就要使用jmap去分析那些不能被gc的對(duì)象，以及和DirectByteBuffer之間的引用關(guān)系了审胸。

GC問(wèn)題

堆內(nèi)內(nèi)存泄漏總是和GC異常相伴亥宿。不過(guò)GC問(wèn)題不只是和內(nèi)存問(wèn)題相關(guān)，還有可能引起CPU負(fù)載砂沛、網(wǎng)絡(luò)問(wèn)題等系列并發(fā)癥烫扼，只是相對(duì)來(lái)說(shuō)和內(nèi)存聯(lián)系緊密些，所以我們?cè)诖藛为?dú)總結(jié)一下GC相關(guān)問(wèn)題尺上。

我們?cè)赾pu章介紹了使用jstat來(lái)獲取當(dāng)前GC分代變化信息材蛛。而更多時(shí)候圆到，我們是通過(guò)GC日志來(lái)排查問(wèn)題的怎抛，在啟動(dòng)參數(shù)中加上-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps來(lái)開啟GC日志卑吭。

常見的Young GC、Full GC日志含義在此就不做贅述了马绝。

針對(duì)gc日志豆赏，我們就能大致推斷出youngGC與fullGC是否過(guò)于頻繁或者耗時(shí)過(guò)長(zhǎng)，從而對(duì)癥下藥富稻。我們下面將對(duì)G1垃圾收集器來(lái)做分析掷邦，這邊也建議大家使用G1-XX:+UseG1GC。

youngGC過(guò)頻繁

youngGC頻繁一般是短周期小對(duì)象較多椭赋，先考慮是不是Eden區(qū)/新生代設(shè)置的太小了抚岗，看能否通過(guò)調(diào)整-Xmn、-XX:SurvivorRatio等參數(shù)設(shè)置來(lái)解決問(wèn)題哪怔。如果參數(shù)正常宣蔚，但是young gc頻率還是太高，就需要使用Jmap和MAT對(duì)dump文件進(jìn)行進(jìn)一步排查了认境。

youngGC耗時(shí)過(guò)長(zhǎng)

耗時(shí)過(guò)長(zhǎng)問(wèn)題就要看GC日志里耗時(shí)耗在哪一塊了胚委。以G1日志為例，可以關(guān)注Root Scanning叉信、Object Copy亩冬、Ref Proc等階段。Ref Proc耗時(shí)長(zhǎng)硼身，就要注意引用相關(guān)的對(duì)象硅急。Root Scanning耗時(shí)長(zhǎng)，就要注意線程數(shù)佳遂、跨代引用营袜。Object Copy則需要關(guān)注對(duì)象生存周期。而且耗時(shí)分析它需要橫向比較讶迁，就是和其他項(xiàng)目或者正常時(shí)間段的耗時(shí)比較连茧。比如說(shuō)圖中的Root Scanning和正常時(shí)間段比增長(zhǎng)較多，那就是起的線程太多了巍糯。

image

觸發(fā)fullGC

G1中更多的還是mixedGC啸驯，但mixedGC可以和youngGC思路一樣去排查。觸發(fā)fullGC了一般都會(huì)有問(wèn)題祟峦，G1會(huì)退化使用Serial收集器來(lái)完成垃圾的清理工作罚斗，暫停時(shí)長(zhǎng)達(dá)到秒級(jí)別，可以說(shuō)是半跪了宅楞。

fullGC的原因可能包括以下這些针姿，以及參數(shù)調(diào)整方面的一些思路：

• 并發(fā)階段失敻み骸：在并發(fā)標(biāo)記階段，MixGC之前老年代就被填滿了距淫，那么這時(shí)候G1就會(huì)放棄標(biāo)記周期绞绒。這種情況，可能就需要增加堆大小榕暇，或者調(diào)整并發(fā)標(biāo)記線程數(shù)-XX:ConcGCThreads蓬衡。
• 晉升失敗：在GC的時(shí)候沒有足夠的內(nèi)存供存活/晉升對(duì)象使用彤枢，所以觸發(fā)了Full
  GC狰晚。這時(shí)候可以通過(guò)-XX:G1ReservePercent來(lái)增加預(yù)留內(nèi)存百分比，減少
  -XX:InitiatingHeapOccupancyPercent來(lái)提前啟動(dòng)標(biāo)記缴啡，-XX:ConcGCThreads來(lái)增加標(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來(lái)dump fullGC相關(guān)的文件反镇，并通過(guò)jinfo來(lái)進(jìn)行g(shù)c前后的dump

jinfo -flag +HeapDumpBeforeFullGC pid jinfo -flag
+HeapDumpAfterFullGC pid

這樣得到2份dump文件，對(duì)比后主要關(guān)注被gc掉的問(wèn)題對(duì)象來(lái)定位問(wèn)題娘汞。

網(wǎng)絡(luò)

涉及到網(wǎng)絡(luò)層面的問(wèn)題一般都比較復(fù)雜歹茶，場(chǎng)景多，定位難你弦，成為了大多數(shù)開發(fā)的噩夢(mèng)惊豺，應(yīng)該是最復(fù)雜的了。這里會(huì)舉一些例子禽作，并從tcp層尸昧、應(yīng)用層以及工具的使用等方面進(jìn)行闡述。

超時(shí)

超時(shí)錯(cuò)誤大部分處在應(yīng)用層面旷偿，所以這塊著重理解概念烹俗。超時(shí)大體可以分為連接超時(shí)和讀寫超時(shí)，某些使用連接池的客戶端框架還會(huì)存在獲取連接超時(shí)和空閑連接清理超時(shí)萍程。

• 讀寫超時(shí)幢妄。readTimeout/writeTimeout，有些框架叫做so_timeout或者socketTimeout茫负，均指的是數(shù)據(jù)讀寫超時(shí)蕉鸳。注意這邊的超時(shí)大部分是指邏輯上的超時(shí)。soa的超時(shí)指的也是讀超時(shí)。讀寫超時(shí)一般都只針對(duì)客戶端設(shè)置潮尝。
• 連接超時(shí)榕吼。connectionTimeout，客戶端通常指與服務(wù)端建立連接的最大時(shí)間勉失。服務(wù)端這邊connectionTimeout就有些五花八門了羹蚣，jetty中表示空閑連接清理時(shí)間，tomcat則表示連接維持的最大時(shí)間戴质。
• 其他度宦。包括連接獲取超時(shí)connectionAcquireTimeout和空閑連接清理超時(shí)idleConnectionTimeout踢匣。多用于使用連接池或隊(duì)列的客戶端或服務(wù)端框架告匠。

我們?cè)谠O(shè)置各種超時(shí)時(shí)間中，需要確認(rèn)的是盡量保持客戶端的超時(shí)小于服務(wù)端的超時(shí)离唬，以保證連接正常結(jié)束后专。

在實(shí)際開發(fā)中，我們關(guān)心最多的應(yīng)該是接口的讀寫超時(shí)了输莺。

如何設(shè)置合理的接口超時(shí)是一個(gè)問(wèn)題戚哎。如果接口超時(shí)設(shè)置的過(guò)長(zhǎng)，那么有可能會(huì)過(guò)多地占用服務(wù)端的tcp連接嫂用。而如果接口設(shè)置的過(guò)短型凳，那么接口超時(shí)就會(huì)非常頻繁。

服務(wù)端接口明明rt降低嘱函，但客戶端仍然一直超時(shí)又是另一個(gè)問(wèn)題甘畅。這個(gè)問(wèn)題其實(shí)很簡(jiǎn)單，客戶端到服務(wù)端的鏈路包括網(wǎng)絡(luò)傳輸往弓、排隊(duì)以及服務(wù)處理等疏唾，每一個(gè)環(huán)節(jié)都可能是耗時(shí)的原因。

TCP隊(duì)列溢出

tcp隊(duì)列溢出是個(gè)相對(duì)底層的錯(cuò)誤函似，它可能會(huì)造成超時(shí)槐脏、rst等更表層的錯(cuò)誤。因此錯(cuò)誤也更隱蔽撇寞，所以我們單獨(dú)說(shuō)一說(shuō)顿天。

image

如上圖所示，這里有兩個(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ā)過(guò)來(lái)的ack莫绣。tcp_abort_on_overflow 1則表示第三步的時(shí)候如果全連接隊(duì)列滿了畴蒲，server發(fā)送一個(gè)rst包給client，表示廢掉這個(gè)握手過(guò)程和這個(gè)連接对室，意味著日志里可能會(huì)有很多connection reset / connection reset by peer模燥。

那么在實(shí)際開發(fā)中，我們?cè)趺茨芸焖俣ㄎ坏絫cp隊(duì)列溢出呢掩宜？

netstat命令蔫骂，執(zhí)行netstat -s | egrep "listen|LISTEN"

image

如上圖所示，overflowed表示全連接隊(duì)列溢出的次數(shù)牺汤，sockets dropped表示半連接隊(duì)列溢出的次數(shù)辽旋。

ss命令，執(zhí)行ss -lnt

image

上面看到Send-Q 表示第三列的listen端口上的全連接隊(duì)列最大為5檐迟，第一列Recv-Q為全連接隊(duì)列當(dāng)前使用了多少补胚。

接著我們看看怎么設(shè)置全連接、半連接隊(duì)列大小吧：

全連接隊(duì)列的大小取決于min(backlog, somaxconn)追迟。backlog是在socket創(chuàng)建的時(shí)候傳入的溶其，somaxconn是一個(gè)os級(jí)別的系統(tǒng)參數(shù)。而半連接隊(duì)列的大小取決于max(64,
/proc/sys/net/ipv4/tcp_max_syn_backlog)敦间。

在日常開發(fā)中瓶逃，我們往往使用servlet容器作為服務(wù)端，所以我們有時(shí)候也需要關(guān)注容器的連接隊(duì)列大小每瞒。在tomcat中backlog叫做acceptCount金闽，在jetty里面則是acceptQueueSize。

RST異常

RST包表示連接重置剿骨，用于關(guān)閉一些無(wú)用的連接代芜，通常表示異常關(guān)閉，區(qū)別于四次揮手浓利。

在實(shí)際開發(fā)中挤庇，我們往往會(huì)看到connection reset / connection reset by peer錯(cuò)誤，這種情況就是RST包導(dǎo)致的贷掖。
端口不存在

如果像不存在的端口發(fā)出建立連接SYN請(qǐng)求嫡秕，那么服務(wù)端發(fā)現(xiàn)自己并沒有這個(gè)端口則會(huì)直接返回一個(gè)

RST報(bào)文，用于中斷連接苹威。

主動(dòng)代替FIN終止連接

一般來(lái)說(shuō)昆咽，正常的連接關(guān)閉都是需要通過(guò)FIN報(bào)文實(shí)現(xiàn)，然而我們也可以用RST報(bào)文來(lái)代替FIN，表示直接終止連接掷酗。實(shí)際開發(fā)中调违，可設(shè)置SO_LINGER數(shù)值來(lái)控制，這種往往是故意的泻轰，來(lái)跳過(guò)TIMED_WAIT技肩，提供交互效率，不閑就慎用浮声。

客戶端或服務(wù)端有一邊發(fā)生了異常虚婿，該方向?qū)Χ税l(fā)送RST以告知關(guān)閉連接

我們上面講的tcp隊(duì)列溢出發(fā)送RST包其實(shí)也是屬于這一種。這種往往是由于某些原因泳挥，一方無(wú)法再能正常處理請(qǐng)求連接了(比如程序崩了然痊，隊(duì)列滿了)，從而告知另一方關(guān)閉連接羡洁。

接收到的TCP報(bào)文不在已知的TCP連接內(nèi)

比如玷过，一方機(jī)器由于網(wǎng)絡(luò)實(shí)在太差TCP報(bào)文失蹤了，另一方關(guān)閉了該連接筑煮，然后過(guò)了許久收到了之前失蹤的TCP報(bào)文，但由于對(duì)應(yīng)的TCP連接已不存在粤蝎，那么會(huì)直接發(fā)一個(gè)RST包以便開啟新的連接真仲。

一方長(zhǎng)期未收到另一方的確認(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)文秸应。

之前說(shuō)過(guò)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)行簡(jiǎn)單分析了整以。tcpdump -i en0 tcp -w xxx.cap，en0表示監(jiān)聽的網(wǎng)卡峻仇。

image

接下來(lái)我們通過(guò)wireshark打開抓到的包公黑，可能就能看到如下圖所示，紅色的就表示RST包了

image

TIME_WAIT和CLOSE_WAIT

TIME_WAIT和CLOSE_WAIT是啥意思相信大家都知道。

在線上時(shí)凡蚜，我們可以直接用命令netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'來(lái)查看time-wait和close_wait的數(shù)量

用ss命令會(huì)更快ss -ant | awk '{++S[$1]} END {for(a in S) print a, S[a]}'

image

TIME_WAIT

time_wait的存在一是為了丟失的數(shù)據(jù)包被后面連接復(fù)用奠骄，二是為了在2MSL的時(shí)間范圍內(nèi)正常關(guān)閉連接。它的存在其實(shí)會(huì)大大減少RST包的出現(xiàn)番刊。

過(guò)多的time_wait在短連接頻繁的場(chǎng)景比較容易出現(xiàn)含鳞。這種情況可以在服務(wù)端做一些內(nèi)核參數(shù)調(diào)優(yōu):

表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接芹务，默認(rèn)為0蝉绷，表示關(guān)閉

net.ipv4.tcp_tw_reuse = 1#表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認(rèn)為0枣抱，表示關(guān)閉net.ipv4.tcp_tw_recycle = 1

當(dāng)然我們不要忘記在NAT環(huán)境下因?yàn)闀r(shí)間戳錯(cuò)亂導(dǎo)致數(shù)據(jù)包被拒絕的坑了熔吗，另外的辦法就是改小tcp_max_tw_buckets，超過(guò)這個(gè)數(shù)的time_wait都會(huì)被干掉佳晶，不過(guò)這也會(huì)導(dǎo)致報(bào)time wait bucket table overflow的錯(cuò)桅狠。

CLOSE_WAIT

close_wait往往都是因?yàn)閼?yīng)用程序?qū)懙挠袉?wèn)題，沒有在ACK后再次發(fā)起FIN報(bào)文轿秧。close_wait出現(xiàn)的概率甚至比time_wait要更高中跌，后果也更嚴(yán)重。往往是由于某個(gè)地方阻塞住了菇篡，沒有正常關(guān)閉連接漩符，從而漸漸地消耗完所有的線程。

想要定位這類問(wèn)題驱还，最好是通過(guò)jstack來(lái)分析線程堆棧來(lái)排查問(wèn)題嗜暴，具體可參考上述章節(jié)。這里僅舉一個(gè)例子议蟆。

開發(fā)同學(xué)說(shuō)應(yīng)用上線后CLOSE_WAIT就一直增多闷沥，直到掛掉為止，jstack后找到比較可疑的堆棧是大部分線程都卡在了countdownlatch.await方法咐容，找開發(fā)同學(xué)了解后得知使用了多線程但是確沒有catch異常舆逃，修改后發(fā)現(xiàn)異常僅僅是最簡(jiǎn)單的升級(jí)sdk后常出現(xiàn)的class not found。

之前疟丙，給大家發(fā)過(guò)三份Java面試寶典颖侄，這次新增了一份，目前總共是四份面試寶典享郊，相信在跳槽前一個(gè)月按照面試寶典準(zhǔn)備準(zhǔn)備览祖，基本沒大問(wèn)題。

《java面試寶典5.0》(初中級(jí))

《350道Java面試題：整理自100+公司》（中高級(jí)）

《資深java面試寶典-視頻版》（資深）

《Java[BAT]面試必備》（資深）

分別適用于初中級(jí)炊琉，中高級(jí)展蒂，資深級(jí)工程師的面試復(fù)習(xí)又活。

內(nèi)容包含java基礎(chǔ)、javaweb锰悼、mysql性能優(yōu)化柳骄、JVM、鎖箕般、百萬(wàn)并發(fā)耐薯、消息隊(duì)列，高性能緩存丝里、反射曲初、Spring全家桶原理、微服務(wù)杯聚、Zookeeper臼婆、數(shù)據(jù)結(jié)構(gòu)、限流熔斷降級(jí)等等幌绍。