記一次JAVA 線上故障排查完整套路

引用：https://juejin.im/post/6871925579482923021

JAVA線上故障排查全套路

線上故障主要會包括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使用率比較高的一些線程

[圖片上傳中...(image-42e9e3-1600939865389-32)]

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

[圖片上傳中...(image-3534b8-1600939865389-31)]

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

[圖片上傳中...(image-ca5ec0-1600939865388-30)]

可以看到我們已經找到了nid為0x42的堆棧信息，接著只要仔細分析一番即可怀各。

當然更常見的是我們對整個jstack文件進行分析倔韭，通常我們會比較關注WAITING和TIMED_WAITING的部分，BLOCKED就不用說了瓢对。我們可以使用命令cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c來對jstack的狀態(tài)有一個整體的把握狐肢，如果WAITING之類的特別多，那么多半是有問題啦沥曹。

[圖片上傳中...(image-d129ee-1600939865388-29)]

頻繁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é)的描述幌氮。

[圖片上傳中...(image-520fda-1600939865388-28)]

上下文切換

針對頻繁上下文問題缭受，我們可以使用vmstat命令來進行查看

[圖片上傳中...(image-e4d92c-1600939865388-27)]

cs(context switch)一列則代表了上下文切換的次數(shù)。
如果我們希望對特定的pid進行監(jiān)控那么可以使用 pidstat -w pid命令该互，cswch和nvcswch表示自愿及非自愿切換米者。

[圖片上傳中...(image-cbe0ce-1600939865388-26)]

磁盤

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

[圖片上傳中...(image-464d66-1600939865388-25)]

更多時候塘雳，磁盤問題還是性能上的問題。我們可以通過iostatiostat -d -k -x來進行分析

[圖片上傳中...(image-b7e558-1600939865388-24)]

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

另外我們還需要知道是哪個進程在進行讀寫太防，一般來說開發(fā)自己心里有數(shù)妻顶，或者用iotop命令來進行定位文件讀寫的來源。

[圖片上傳中...(image-a59eea-1600939865388-23)]

不過這邊拿到的是tid蜒车，我們要轉換成pid讳嘱，可以通過readlink來找到pidreadlink -f /proc/*/task/tid/../..。

[圖片上傳中...(image-2c99cb-1600939865388-22)]

找到pid之后就可以看這個進程具體的讀寫情況cat /proc/pid/io
[圖片上傳中...(image-9972d9-1600939865388-21)]

我們還可以通過lsof命令來確定具體的文件讀寫情況lsof -p pid
[圖片上傳中...(image-2a3817-1600939865388-20)]

內存

內存問題排查起來相對比CPU麻煩一些酿愧，場景也比較多沥潭。主要包括OOM、GC問題和堆外內存嬉挡。一般來講钝鸽，我們會先用free命令先來檢查一發(fā)內存的各種情況。
[圖片上傳中...(image-59b588-1600939865388-19)]

堆內內存

內存問題大多還都是堆內內存問題庞钢。表象上主要分為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對線程的限制

[圖片上傳中...(image-b0c0bb-1600939865388-18)]

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文件
[圖片上傳中...(image-9c4de0-1600939865388-17)]

通過mat(Eclipse Memory Analysis Tools)導入dump文件進行分析醉箕，內存泄漏問題一般我們直接選Leak Suspects即可，mat給出了內存泄漏的建議徙垫。另外也可以選擇Top Consumers來查看最大對象報告讥裤。和線程相關的問題可以選擇thread overview進行分析。除此之外就是選擇Histogram類概覽來自己慢慢分析姻报，大家可以搜搜mat的相關教程己英。
[圖片上傳中...(image-d25876-1600939865388-16)]

日常開發(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挎峦。
[圖片上傳中...(image-3a76a5-1600939865388-15)]

或者直接通過查看/proc/pid/task的數(shù)量即為線程數(shù)量。
[圖片上傳中...(image-cc7c3a-1600939865388-14)]

堆外內存

如果碰到堆外內存溢出合瓢，那可真是太不幸了坦胶。首先堆外內存溢出表現(xiàn)就是物理常駐內存增長快，報錯的話視使用方式都不確定晴楔，如果由于使用Netty導致的顿苇，那錯誤日志里可能會出現(xiàn)OutOfDirectMemoryError錯誤，如果直接是DirectByteBuffer税弃，那會報OutOfMemoryError: Direct buffer memory纪岁。

堆外內存溢出往往是和NIO的使用相關，一般我們先通過pmap來查看下進程占用的內存情況pmap -x pid | sort -rn -k3 | head -30则果，這段意思是查看對應pid倒序前30大的內存段蜂科。這邊可以再一段時間后再跑一次命令看看內存增長情況，或者和正常機器比較可疑的內存段在哪里短条。

[圖片上傳中...(image-586c3-1600939865388-13)]

我們如果確定有可疑的內存端导匣，需要通過gdb來分析gdb --batch --pid {pid} -ex "dump memory filename.dump {內存起始地址} {內存起始地址+內存塊大小}"

[圖片上傳中...(image-aa031a-1600939865388-12)]

獲取dump文件后可用heaxdump進行查看hexdump -C filename | less，不過大多數(shù)看到的都是二進制亂碼茸时。

NMT是Java7U40引入的HotSpot新特性贡定，配合jcmd命令我們就可以看到具體內存組成了。需要在啟動參數(shù)中加入 -XX:NativeMemoryTracking=summary 或者 -XX:NativeMemoryTracking=detail可都，會有略微性能損耗缓待。

一般對于堆外內存緩慢增長直到爆炸的情況來說，可以先設一個基線jcmd pid VM.native_memory baseline渠牲。

[圖片上傳中...(image-30cc92-1600939865388-11)]

然后等放一段時間后再去看看內存增長的情況旋炒，通過jcmd pid VM.native_memory detail.diff(summary.diff)做一下summary或者detail級別的diff。

[圖片上傳中...(image-e08d88-1600939865388-10)]

[圖片上傳中...(image-d6afa1-1600939865388-9)]

可以看到jcmd分析出來的內存十分詳細签杈，包括堆內瘫镇、線程以及gc(所以上述其他內存異常其實都可以用nmt來分析)，這邊堆外內存我們重點關注Internal的內存增長答姥，如果增長十分明顯的話那就是有問題了铣除。
detail級別的話還會有具體內存段的增長情況，如下圖鹦付。
[圖片上傳中...(image-7b5acb-1600939865388-8)]

此外在系統(tǒng)層面尚粘，我們還可以使用strace命令來監(jiān)控內存分配 strace -f -e "brk,mmap,munmap" -p pid
這邊內存分配信息主要包括了pid和內存地址。
[圖片上傳中...(image-380208-1600939865388-7)]

不過其實上面那些操作也很難定位到具體的問題點敲长，關鍵還是要看錯誤日志棧郎嫁，找到可疑的對象秉继，搞清楚它的回收機制，然后去分析對應的對象泽铛。比如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和正常時間段比增長較多奏司，那就是起的線程太多了乔询。
[圖片上傳中...(image-c53744-1600939865388-6)]

觸發(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等更表層的錯誤拖叙。因此錯誤也更隱蔽，所以我們單獨說一說赂乐。
[圖片上傳中...(image-c96f9c-1600939865387-5)]

如上圖所示薯鳍，這里有兩個隊列：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"
[圖片上傳中...(image-21e9eb-1600939865387-4)]

如上圖所示，overflowed表示全連接隊列溢出的次數(shù)狡汉，sockets dropped表示半連接隊列溢出的次數(shù)娄徊。

ss命令，執(zhí)行ss -lnt
[圖片上傳中...(image-bdd8fb-1600939865387-3)]

上面看到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)聽的網卡椰棘。
[圖片上傳中...(image-24ca40-1600939865387-2)]

接下來我們通過wireshark打開抓到的包，可能就能看到如下圖所示榄笙，紅色的就表示RST包了邪狞。
[圖片上傳中...(image-1c43de-1600939865387-1)]

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]}'

[圖片上傳中...(image-46989d-1600939865387-0)]

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射赛。

作者：非科班的科班
鏈接：https://juejin.im/post/6871925579482923021
來源：掘金
著作權歸作者所有。商業(yè)轉載請聯(lián)系作者獲得授權奶是，非商業(yè)轉載請注明出處楣责。

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市聂沙，隨后出現(xiàn)的幾起案子秆麸，更是在濱河造成了極大的恐慌，老刑警劉巖及汉，帶你破解...
    沈念sama閱讀 219,039評論 6贊 508
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件沮趣，死亡現(xiàn)場離奇詭異，居然都是意外死亡坷随，警方通過查閱死者的電腦和手機房铭，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,426評論 3贊 395
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來甸箱，“玉大人育叁，你說我怎么就攤上這事∩种常” “怎么了？”我有些...
    開封第一講書人閱讀 165,417評論 0贊 356
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵谴蔑，是天一觀的道長豌骏。 經常有香客問我，道長隐锭，這世上最難降的妖魔是什么窃躲？ 我笑而不...
    開封第一講書人閱讀 58,868評論 1贊 295
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮钦睡，結果婚禮上蒂窒，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好洒琢，可當我...
    茶點故事閱讀 67,892評論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布秧秉。 她就那樣靜靜地躺著，像睡著了一般衰抑。 火紅的嫁衣襯著肌膚如雪象迎。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 51,692評論 1贊 305
  • 城市分裂傳說
    那天呛踊，我揣著相機與錄音砾淌，去河邊找鬼。 笑死谭网，一個胖子當著我的面吹牛汪厨，可吹牛的內容都是我干的。 我是一名探鬼主播愉择，決...
    沈念sama閱讀 40,416評論 3贊 419
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼骄崩，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了薄辅？” 一聲冷哼從身側響起要拂，我...
    開封第一講書人閱讀 39,326評論 0贊 276
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎站楚，沒想到半個月后脱惰，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經...
    沈念sama閱讀 45,782評論 1贊 316
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡窿春，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,957評論 3贊 337
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年拉一，在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片旧乞。...
    茶點故事閱讀 40,102評論 1贊 350
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡蔚润，死狀恐怖，靈堂內的尸體忽然破棺而出尺栖，到底是詐尸還是另有隱情嫡纠，我是刑警寧澤，帶...
    沈念sama閱讀 35,790評論 5贊 346
  • ?日本核電站爆炸內幕
    正文 年R本政府宣布延赌，位于F島的核電站除盏，受9級特大地震影響，放射性物質發(fā)生泄漏挫以。R本人自食惡果不足惜者蠕，卻給世界環(huán)境...
    茶點故事閱讀 41,442評論 3贊 331
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望掐松。 院中可真熱鬧踱侣，春花似錦粪小、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,996評論 0贊 22
  • 一樁弒父案探膊，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至玉转，卻和暖如春突想，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背究抓。 一陣腳步聲響...
    開封第一講書人閱讀 33,113評論 1贊 272
  • 情欲美人皮
    我被黑心中介騙來泰國打工猾担， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人刺下。 一個月前我還...
    沈念sama閱讀 48,332評論 3贊 373
  • 代替公主和親
    正文 我出身青樓绑嘹，卻偏偏與公主長得像，于是被迫代替她去往敵國和親橘茉。 傳聞我的和親對象是個殘疾皇子工腋，可洞房花燭夜當晚...
    茶點故事閱讀 45,044評論 2贊 355