一、GC的原理介紹
JAVA堆分爲新生代（Young Generation）和老年代（Old Generation）（ 也就是圖中對應的New Generation 和 tenured Generation）用於存儲對象實例。
而新生代有分爲三個區一個Eden（伊甸）和兩個Survivor（倖存者）：From Survivor區（簡稱S0），To Survivor區（簡稱S1區），三者的默認比例爲8:1:1。另外，新生代和老年代的默認比例爲1:2。一般情況下，當new 出一個對象時，生成的對象實例即放入Eden中，回收的時候先將Eden中的沒有被回收的對象移入其中一個Survivor，假設是Survivor0，
然後清空Eden,那麼現在的Eden爲空，Survivor0存在還在使用的對象實例，Survivor0爲空。當下次再回收時，照樣將Eden中還在使用的對象實例放入Survivor0，並把Survivor0需要回收的對象實例標記-清除，最後再把整塊Survivor0複製到Survivor1，再清除Survivor0。
當回收很多次後，發現有些對象一直被用，不能回收，那麼就認爲這個對象實例可能以後還是不會被收回，就放到老年代吧，這樣以後在標記-清除-複製新生代是就不會操作它了，節約了很多時間。因爲平時新生代經常執行回收操作，而老年代要達到一定條件後才執行回收。
年輕代（Young Generation）
- 所有新生成的對象首先都是放在年輕代的。年輕代的目標就是儘可能快速的收集掉那些生命週期短的對象。
- 新生代內存按照8:1:1的比例分爲一個eden區和兩個survivor(survivor0,survivor1)區。一個Eden區，兩個 Survivor區(一般而言)。大部分對象在Eden區中生成。回收時先將eden區存活對象複製到一個survivor0區，然後清空eden區，當這個survivor0區也存放滿了時，則將eden區和survivor0區存活對象複製到另一個survivor1區，然後清空eden和這個survivor0區，此時survivor0區是空的，然後將survivor0區和survivor1區交換，即保持survivor1區爲空， 如此往復。
- 當survivor1區不足以存放 eden和survivor0的存活對象時，就將存活對象直接存放到老年代。若是老年代也滿了就會觸發一次Full GC，也就是新生代、老年代都進行回收
- 新生代發生的GC也叫做Minor GC，MinorGC發生頻率比較高(不一定等Eden區滿了才觸發)
年老代（Old Generation）
- YGC時，To Survivor區不足以存放存活的對象，對象會直接進入到老年代。
- 經過多次YGC後，如果存活對象的年齡達到了設定閾值（默認15），則會晉升到老年代中。
- 動態年齡判定規則，To Survivor區中相同年齡的對象，如果其大小之和佔到了 To Survivor區一半以上的空間，那麼大於此年齡的對象會直接進入老年代，而不需要達到默認的分代年齡。
- 大對象：由-XX:PretenureSizeThreshold啓動參數控制，若對象大小大於此值，就會繞過新生代, 直接在老年代中分配。
持久代（Permanent Generation）
用於存放靜態文件，如Java類、方法等。持久代對垃圾回收沒有顯著影響，但是有些應用可能動態生成或者調用一些class，例如Hibernate 等，在這種時候需要設置一個比較大的持久代空間來存放這些運行過程中新增的類。
YGC是什麼時候觸發的？
大多數情況下，對象直接在年輕代中的Eden區進行分配，如果Eden區域沒有足夠的空間，那麼就會觸發YGC（Minor GC），YGC處理的區域只有新生代。因爲大部分對象在短時間內都是可收回掉的，因此YGC後只有極少數的對象能存活下來，而被移動到S0區（採用的是複製算法）。
當觸發下一次YGC時，會將Eden區和S0區的存活對象移動到S1區，同時清空Eden區和S0區。當再次觸發YGC時，這時候處理的區域就變成了Eden區和S1區（即S0和S1進行角色交換）。每經過一次YGC，存活對象的年齡就會加1。
FGC是什麼時候觸發的？
- 當晉升到老年代的對象大於老年代的剩餘空間時，就會觸發FGC（Major GC），FGC處理的區域同時包括新生代和老年代。
- 老年代的內存使用率達到了一定閾值（可通過參數調整），直接觸發FGC。
- 空間分配擔保：在YGC之前，會先檢查老年代最大可用的連續空間是否大於新生代所有對象的總空間。如果小於，說明YGC是不安全的，則會查看參數 HandlePromotionFailure 是否被設置成了允許擔保失敗，如果不允許則直接觸發Full GC；如果允許，那麼會進一步檢查老年代最大可用的連續空間是否大於歷次晉升到老年代對象的平均大小，如果小於也會觸發 Full GC。
- Metaspace（元空間）在空間不足時會進行擴容，當擴容到了-XX:MetaspaceSize 參數的指定值時，也會觸發FGC。
- System.gc() 或者Runtime.gc() 被顯式調用時，觸發FGC。
在什麼情況下，GC會對程序產生影響？
不管YGC還是FGC，都會造成一定程度的程序卡頓（即Stop The World問題：GC線程開始工作，其他工作線程被掛起），即使採用ParNew、CMS或者G1這些更先進的垃圾回收算法，也只是在減少卡頓時間，而並不能完全消除卡頓。
那到底什麼情況下，GC會對程序產生影響呢？根據嚴重程度從高到底，我認爲包括以下4種情況：
-
FGC過於頻繁：FGC通常是比較慢的，少則幾百毫秒，多則幾秒，正常情況FGC每隔幾個小時甚至幾天才執行一次，對系統的影響還能接受。但是，一旦出現FGC頻繁（比如幾十分鐘就會執行一次），這種肯定是存在問題的，它會導致工作線程頻繁被停止，讓系統看起來一直有卡頓現象，也會使得程序的整體性能變差。
-
YGC耗時過長：一般來說，YGC的總耗時在幾十或者上百毫秒是比較正常的，雖然會引起系統卡頓幾毫秒或者幾十毫秒，這種情況幾乎對用戶無感知，對程序的影響可以忽略不計。但是如果YGC耗時達到了1秒甚至幾秒（都快趕上FGC的耗時了），那卡頓時間就會增大，加上YGC本身比較頻繁，就會導致比較多的服務超時問題。
-
FGC耗時過長：FGC耗時增加，卡頓時間也會隨之增加，尤其對於高併發服務，可能導致FGC期間比較多的超時問題，可用性降低，這種也需要關注。
-
YGC過於頻繁：即使YGC不會引起服務超時，但是YGC過於頻繁也會降低服務的整體性能，對於高併發服務也是需要關注的。
Java有了GC同樣會出現內存泄露問題
1.靜態集合類像HashMap、Vector等的使用最容易出現內存泄露
2.各種連接，數據庫連接，網絡連接，IO連接等沒有顯示調用close關閉，不被GC回收導致內存泄露。
3.監聽器的使用，在釋放對象的同時沒有相應刪除監聽器的時候也可能導致內存泄露。
內存泄漏和內存溢出的區別
1. 內存泄漏（memory leak ）
申請了內存用完了不釋放，比如一共有 1024M 的內存，分配了 521M 的內存一直不回收，那麼可以用的內存只有 521M 了，彷彿泄露掉了一部分；通俗一點講的話，內存泄漏就是【佔着茅坑不拉shi】。
2. 內存溢出（out of memory）
申請內存時，沒有足夠的內存可以使用；
通俗一點兒講，一個廁所就三個坑，有兩個站着茅坑不走的（內存泄漏），剩下最後一個坑，廁所表示接待壓力很大，這時候一下子來了兩個人，坑位（內存）就不夠了，內存泄漏變成內存溢出了。
對象 X 引用對象 Y，X 的生命週期比 Y 的生命週期長；那麼當Y生命週期結束的時候，X依然引用着Y，這時候，垃圾回收期是不會回收對象Y的；如果對象X還引用着生命週期比較短的A、B、C，對象A又引用着對象 a、b、c，這樣就可能造成大量無用的對象不能被回收，進而佔據了內存資源，造成內存泄漏，直到內存溢出。
可見，內存泄漏和內存溢出的關係：內存泄露的增多，最終會導致內存溢出。
注意：匿名內部類會持有外部類的引用，可能會導致內存泄漏，靜態內部類則不會（https://mp.weixin.qq.com/s/ZX-BvkQ4B7ql62Mi8v_rLw）
檢查JVM配置、設置Java堆大小
通過以下命令查看JVM的啓動參數：
ps aux | grep "applicationName=adsearch"
可以看到堆內存爲4G，新生代爲2G，老年代也爲2G，新生代採用ParNew收集器，老年代採用併發標記清除的CMS收集器，當老年代的內存佔用率達到80%時會進行FGC。
-Xms4g -Xmx4g -Xmn2g -Xss1024K
-XX:ParallelGCThreads=5
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSInitiatingOccupancyFraction=80
Java整個堆大小設置，Xmx 和 Xms設置爲老年代存活對象的3-4倍，即FullGC之後的老年代內存佔用的3-4倍
永久代 PermSize和MaxPermSize設置爲老年代存活對象的1.2-1.5倍。
年輕代Xmn的設置爲老年代存活對象的1-1.5倍。
老年代的內存大小設置爲老年代存活對象的2-3倍。
Xms=xmx=(3-4)( full gc後oc大小)
Xmn=(1-1.5)( full gc後oc大小)
JVM參數中添加GC日誌
-XX:+PrintGC -XX:+PrintGCDetils
或
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps
GC日誌中會記錄每次FullGC之後各代的內存大小，觀察老年代GC之後的空間大小。可觀察一段時間內（比如2天）的FullGC之後的內存情況，根據多次的FullGC之後的老年代的空間大小數據來預估FullGC之後老年代的存活對象大小（可根據多次FullGC之後的內存大小取平均值）
[GC (Allocation Failure) [PSYoungGen: 228290K->3505K(244224K)] 264814K->43652K(506368K), 0.0368352 secs] [Times: user=0.14 sys=0.00, real=0.04 secs]
針對gc日誌，我們就能大致推斷出youngGC與fullGC是否過於頻繁或者耗時過長，從而對症下藥。我們下面將對G1垃圾收集器來做分析，這邊也建議大家使用G1-XX:+UseG1GC。
youngGC過頻繁
youngGC頻繁一般是短週期小對象較多，先考慮是不是Eden區/新生代設置的太小了，看能否通過調整-Xmn、-XX:SurvivorRatio等參數設置來解決問題。如果參數正常，但是young gc頻率還是太高，就需要使用Jmap和MAT對dump文件進行進一步排查了。
youngGC耗時過長
耗時過長問題就要看GC日誌裏耗時耗在哪一塊了。以G1日誌爲例，可以關注Root Scanning、Object Copy、Ref Proc等階段。Ref Proc耗時長，就要注意引用相關的對象。Root Scanning耗時長，就要注意線程數、跨代引用。Object Copy則需要關注對象生存週期。而且耗時分析它需要橫向比較，就是和其他項目或者正常時間段的耗時比較。比如說圖中的Root Scanning和正常時間段比增長較多，那就是起的線程太多了。
觸發fullGC
G1中更多的還是mixedGC，但mixedGC可以和youngGC思路一樣去排查。觸發fullGC了一般都會有問題，G1會退化使用Serial收集器來完成垃圾的清理工作，暫停時長達到秒級別，可以說是半跪了。
fullGC的原因可能包括以下這些，以及參數調整方面的一些思路：
- 併發階段失敗：在併發標記階段，MixGC之前老年代就被填滿了，那麼這時候G1就會放棄標記週期。這種情況，可能就需要增加堆大小，或者調整併發標記線程數
-XX:ConcGCThreads。 - 晉升失敗：在GC的時候沒有足夠的內存供存活/晉升對象使用，所以觸發了Full GC。這時候可以通過
-XX:G1ReservePercent來增加預留內存百分比，減少-XX:InitiatingHeapOccupancyPercent來提前啓動標記，-XX:ConcGCThreads來增加標記線程數也是可以的。 - 大對象分配失敗：大對象找不到合適的region空間進行分配，就會進行fullGC，這種情況下可以增大內存或者增大
-XX:G1HeapRegionSize。 - 程序主動執行System.gc()：不要隨便寫就對了。
另外，我們可以在啓動參數中配置-XX:HeapDumpPath=/xxx/dump.hprof來dump fullGC相關的文件，並通過jinfo來進行gc前後的dump
jinfo -flag +HeapDumpBeforeFullGC pid
jinfo -flag +HeapDumpAfterFullGC pid
這樣得到2份dump文件，對比後主要關注被gc掉的問題對象來定位問題。
二、對於FGC問題的排查步驟
1. 清楚從程序角度，有哪些原因導致FGC？
-
大對象：系統一次性加載了過多數據到內存中（比如SQL查詢未做分頁），導致大對象進入了老年代。
-
內存泄漏：頻繁創建了大量對象，但是無法被回收（比如IO對象使用完後未調用close方法釋放資源），先引發FGC，最後導致OOM.
-
程序頻繁生成一些長生命週期的對象，當這些對象的存活年齡超過分代年齡時便會進入老年代，最後引發FGC. （即本文中的案例）
-
程序BUG導致動態生成了很多新類，使得 Metaspace 不斷被佔用，先引發FGC，最後導致OOM.
-
代碼中顯式調用了gc方法，包括自己的代碼甚至框架中的代碼。
-
JVM參數設置問題：包括總內存大小、新生代和老年代的大小、Eden區和S區的大小、元空間大小、垃圾回收算法等等。
2. 清楚排查問題時能使用哪些工具
-
公司的監控系統：大部分公司都會有，可全方位監控JVM的各項指標。
-
JDK的自帶工具，包括jmap、jstat等常用命令：
# 查看堆內存各區域的使用率以及GC情況
jstat -gcutil -h20 pid 1000
# 查看堆內存中的存活對象，並按空間排序
jmap -histo pid | head -n20
# dump堆內存文件
jmap -dump:format=b,file=heap pid
-
可視化的堆內存分析工具：JVisualVM、MAT等
3.查看gc情況命令
1、查看某個進程的對象佔用對象最大情況
pid是進程號，20表示排名前二十，instances表示實例數量，bytes表示佔用內存大小（1M=1024KB,1KB=1024Bytes）
jmap -histo pid | head -n 20
2、監控jvm內存，查看full gc頻率
監控jvm，每5秒打印一次，循環100次
jstat -gc pid 5000 100
jstat -gcutil pid 5000 100
- S0C：第一個倖存區的大小
- S1C：第二個倖存區的大小
- S0U：第一個倖存區的使用大小
- S1U：第二個倖存區的使用大小
- EC：伊甸園區的大小
- EU：伊甸園區的使用大小
- OC：老年代大小
- OU：老年代使用大小
- MC：方法區大小
- MU：方法區使用大小
- CCSC:壓縮類空間大小
- CCSU:壓縮類空間使用大小
- YGC：年輕代垃圾回收次數
- YGCT：年輕代垃圾回收消耗時間
- FGC：老年代垃圾回收次數
- FGCT：老年代垃圾回收消耗時間
- GCT：垃圾回收消耗總時間
查看進程運行時間，頻率=持續時間 /FGC
# ps -eo pid,tty,user,comm,lstart,etime | grep 24019
24019 ? admin java Thu Dec 13 11:17:14 2018 01:29:43
進程id 進程名 開始時間 持續時間
4. 排查指南
-
查看監控，以瞭解出現問題的時間點以及當前FGC的頻率（可對比正常情況看頻率是否正常）
-
瞭解該時間點之前有沒有程序上線、基礎組件升級等情況。
-
瞭解JVM的參數設置，包括：堆空間各個區域的大小設置，新生代和老年代分別採用了哪些垃圾收集器，然後分析JVM參數設置是否合理。
-
再對步驟1中列出的可能原因做排除法，其中元空間被打滿、內存泄漏、代碼顯式調用gc方法比較容易排查。
-
針對大對象或者長生命週期對象導致的FGC，可通過 jmap -histo 命令並結合dump堆內存文件作進一步分析，需要先定位到可疑對象。
-
通過可疑對象定位到具體代碼再次分析，這時候要結合GC原理和JVM參數設置，弄清楚可疑對象是否滿足了進入到老年代的條件才能下結論。
5. 內存溢出的定位與分析
內存溢出在實際的生產環境中經常會遇到，比如，不斷的將數據寫入到一個集合中，出現了死循環，讀取超大的文件等等，都可能會造成內存溢出。
如果出現了內存溢出，首先我們需要定位到發生內存溢出的環節，並且進行分析，是正常還是非正常情況，如果是正常的需求，就應該考慮加大內存的設置，如果是非正常需求，那麼就要對代碼進行修改，修復這個bug。
首先，我們得先學會如何定位問題，然後再進行分析。如何定位問題呢，我們需要藉助於jmap與MAT工具進行定位分析。
1、模擬內存溢出
編寫代碼，向List集合中添加100萬個字符串，每個字符串由1000個UUID組成。如果程序能夠正常執行，最後打印ok
package com.zn;
import java.util.ArrayList;
import java.util.List;
import java.util.UUID;
public class TestJvmOutOfMemory {
public static void main(String[] args) {
List<Object> list = new ArrayList<>();
for (int i = 0; i < 10000000; i++) {
String str = "";
for (int j = 0; j < 1000; j++) {
str += UUID.randomUUID().toString();
}
list.add(str);
}
System.out.println("ok");
}
}
2、設置VM options參數
-Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError
3、運行測試
4、當發生內存溢出時，會dump文件到java_pid65828.hprof
5、導入到MAT工具中進行分析
可以看到，有87.99%的內存由Object[]數組佔有，所以比較可疑。
分析：這個可疑是正確的，因爲已經有超過90%的內存都被它佔有，這是非常有可能出現內存溢出的。
6、查看詳情
可以看到集合中存儲了大量的uuid字符串
三、線上故障排查
Linux 系統運行緩慢，CPU 100%，以及Full GC次數過多問題的排查思路
這種情況可能的原因主要有兩種：
- 代碼中某個位置讀取數據量較大，導致系統內存耗盡，從而導致Full GC次數過多，系統緩慢；
- 代碼中有比較耗CPU的操作，導致CPU過高，系統運行緩慢；
相對來說，這是出現頻率最高的兩種線上問題，而且它們會直接導致系統不可用。另外有幾種情況也會導致某個功能運行緩慢，但是不至於導致系統不可用：
- 代碼某個位置有阻塞性的操作，導致該功能調用整體比較耗時，但出現是比較隨機的；
- 某個線程由於某種原因而進入WAITING狀態，此時該功能整體不可用，但是無法復現；
- 由於鎖使用不當，導致多個線程進入死鎖狀態，從而導致系統整體比較緩慢。
對於這三種情況，通過查看CPU和系統內存情況是無法查看出具體問題的，因爲它們相對來說都是具有一定阻塞性操作，CPU和系統內存使用情況都不高，但是功能卻很慢。
CPU
一般來講我們首先會排查cpu方面的問題。cpu異常往往還是比較好定位的。原因包括業務邏輯問題(代碼中有比較耗時的計算)、頻繁gc以及上下文切換過多。而最常見的往往是業務邏輯(或者框架邏輯)導致的，可以使用jstack來分析對應的堆棧情況。
使用jstack分析cpu問題
top -H -p pid 查看某一進程下的各個線程運行情況
可以看到該進程下的各個線程運行情況
轉換線程ID
在jsatck命令展示的結果中，線程id都轉換成了十六進制形式。可以用如下命令查看轉換結果，也可以找一個科學計算器進行轉換：
# printf "%x\n" pid
printf "%x\n" 17880
45d8
jstack定位cpu佔用線程
30代表查看30行日誌
jstack 進程ID | grep 線程ID -A 30
查看堆棧信息jstack pid |grep 'nid' -C5 –color
可以看到我們已經找到了nid爲0x42的堆棧信息，接着只要仔細分析一番即可。通常我們會比較關注WAITING和TIMED_WAITING的部分，BLOCKED就不用說了。我們可以使用命令cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c來對jstack的狀態有一個整體的把握，如果WAITING之類的特別多，那麼多半是有問題啦。
jstack查看Gc情況
可以先確定下gc是不是太頻繁，使用jstat -gc pid 1000命令來對gc分代變化情況進行觀察，1000表示採樣間隔(ms)，S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU分別代表兩個Survivor區、Eden區、老年代、元數據區的容量和使用量。YGC/YGT、FGC/FGCT、GCT則代表YoungGc、FullGc的耗時和次數以及總耗時。如果看到gc比較頻繁，再針對gc方面做進一步分析
vmstat查看上下文切換
針對頻繁上下文問題，我們可以使用vmstat命令來進行查看
cs(context switch)一列則代表了上下文切換的次數。
如果我們希望對特定的pid進行監控那麼可以使用 pidstat -w pid命令，cswch和nvcswch表示自願及非自願切換。
內存
內存問題排查起來相對比CPU麻煩一些，場景也比較多。主要包括OOM、GC問題和堆外內存。一般來講，我們會先用free命令先來檢查一發內存的各種情況。
堆內內存
內存問題大多還都是堆內內存問題。表象上主要分爲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的大小。另外也可以在系統層面，可以通過修改/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
這個意思是元數據區的內存佔用已經達到XX:MaxMetaspaceSize設置的最大值，排查思路和上面的一致，參數方面可以通過XX:MaxPermSize來進行調整(這裏就不說1.8以前的永久代了)。
Stack Overflow
棧內存溢出，這個大家見到也比較多。
Exception in thread "main" java.lang.StackOverflowError
表示線程棧需要的內存大於Xss值，同樣也是先進行排查，參數方面通過Xss來調整，但調整的太大可能又會引起OOM。
使用JMAP定位代碼內存泄漏
上述關於OOM和StackOverflow的代碼排查方面，我們一般使用JMAPjmap -dump:format=b,file=filename pid來導出dump文件
另一方面，我們可以在啓動參數中指定-XX:+HeapDumpOnOutOfMemoryError來保存OOM時的dump文件。
參考《jmap的使用以及內存溢出分析》：https://blog.csdn.net/weixin_38004638/article/details/106135505
gc問題和線程
堆內內存泄漏總是和GC異常相伴。不過GC問題不只是和內存問題相關，還有可能引起CPU負載、網絡問題等系列併發症，只是相對來說和內存聯繫緊密些，所以我們在此單獨總結一下GC相關問題。
線程的話太多而且不被及時gc也會引發oom，大部分就是之前說的unable to create new native thread。除了jstack細細分析dump文件外，我們一般先會看下總體線程，通過pstreee -p pid |wc -l。
或者直接通過查看/proc/pid/task的數量即爲線程數量。
堆外內存
如果碰到堆外內存溢出，那可真是太不幸了。首先堆外內存溢出表現就是物理常駐內存增長快，報錯的話視使用方式都不確定。堆外內存溢出往往是和NIO的使用相關，一般我們先通過pmap來查看下進程佔用的內存情況pmap -x pid | sort -rn -k3 | head -30，這段意思是查看對應pid倒序前30大的內存段。這邊可以再一段時間後再跑一次命令看看內存增長情況，或者和正常機器比較可疑的內存段在哪裏。
一般對於堆外內存緩慢增長直到爆炸的情況來說，可以先設一個基線jcmd pid VM.native_memory baseline。
然後等放一段時間後再去看看內存增長的情況，通過jcmd pid VM.native_memory detail.diff(summary.diff)做一下summary或者detail級別的diff。
可以看到jcmd分析出來的內存十分詳細，包括堆內、線程以及gc(所以上述其他內存異常其實都可以用nmt來分析)，這邊堆外內存我們重點關注Internal的內存增長，如果增長十分明顯的話那就是有問題了。
磁盤
磁盤問題和cpu一樣是屬於比較基礎的。首先是磁盤空間方面，我們直接使用df -hl來查看文件系統狀態
更多時候，磁盤問題還是性能上的問題。我們可以通過iostatiostat -d -k -x來進行分析
最後一列%util可以看到每塊磁盤寫入的程度，而rrqpm/s以及wrqm/s分別表示讀寫速度，一般就能幫助定位到具體哪塊磁盤出現問題了。
另外我們還需要知道是哪個進程在進行讀寫，一般來說開發自己心裏有數，或者用iotop命令來進行定位文件讀寫的來源。
不過這邊拿到的是tid，我們要轉換成pid，可以通過readlink來找到pidreadlink -f /proc/*/task/tid/../..。
找到pid之後就可以看這個進程具體的讀寫情況cat /proc/pid/io
我們還可以通過lsof命令來確定具體的文件讀寫情況lsof -p pid
網絡
涉及到網絡層面的問題一般都比較複雜，場景多，定位難，成爲了大多數開發的噩夢，應該是最複雜的了。這裏會舉一些例子，並從tcp層、應用層以及工具的使用等方面進行闡述。
超時
超時錯誤大部分處在應用層面，所以這塊着重理解概念。超時大體可以分爲連接超時和讀寫超時，某些使用連接池的客戶端框架還會存在獲取連接超時和空閒連接清理超時。
-
讀寫超時。readTimeout/writeTimeout，有些框架叫做so_timeout或者socketTimeout，均指的是數據讀寫超時。注意這邊的超時大部分是指邏輯上的超時。soa的超時指的也是讀超時。讀寫超時一般都只針對客戶端設置。
-
連接超時。connectionTimeout，客戶端通常指與服務端建立連接的最大時間。服務端這邊connectionTimeout就有些五花八門了，jetty中表示空閒連接清理時間，tomcat則表示連接維持的最大時間。
-
其他。包括連接獲取超時connectionAcquireTimeout和空閒連接清理超時idleConnectionTimeout。多用於使用連接池或隊列的客戶端或服務端框架。
我們在設置各種超時時間中，需要確認的是儘量保持客戶端的超時小於服務端的超時，以保證連接正常結束。
在實際開發中，我們關心最多的應該是接口的讀寫超時了。
如何設置合理的接口超時是一個問題。如果接口超時設置的過長，那麼有可能會過多地佔用服務端的tcp連接。而如果接口設置的過短，那麼接口超時就會非常頻繁。
服務端接口明明rt降低，但客戶端仍然一直超時又是另一個問題。這個問題其實很簡單，客戶端到服務端的鏈路包括網絡傳輸、排隊以及服務處理等，每一個環節都可能是耗時的原因。
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指示的執行。
tcp_abort_on_overflow 0表示如果三次握手第三步的時候accept queue滿了那麼server扔掉client發過來的ack。tcp_abort_on_overflow 1則表示第三步的時候如果全連接隊列滿了，server發送一個rst包給client，表示廢掉這個握手過程和這個連接，意味着日誌裏可能會有很多connection reset / connection reset by peer。
那麼在實際開發中，我們怎麼能快速定位到tcp隊列溢出呢？
netstat命令，執行netstat -s | egrep "listen|LISTEN"
如上圖所示，overflowed表示全連接隊列溢出的次數，sockets dropped表示半連接隊列溢出的次數。
ss命令，執行ss -lnt
上面看到Send-Q 表示第三列的listen端口上的全連接隊列最大爲5，第一列Recv-Q爲全連接隊列當前使用了多少。
接着我們看看怎麼設置全連接、半連接隊列大小吧：
全連接隊列的大小取決於min(backlog, somaxconn)。backlog是在socket創建的時候傳入的，somaxconn是一個os級別的系統參數。而半連接隊列的大小取決於max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)。
在日常開發中，我們往往使用servlet容器作爲服務端，所以我們有時候也需要關注容器的連接隊列大小。在tomcat中backlog叫做acceptCount，在jetty裏面則是acceptQueueSize。
RST異常
RST包表示連接重置，用於關閉一些無用的連接，通常表示異常關閉，區別於四次揮手。
在實際開發中，我們往往會看到connection reset / connection reset by peer錯誤，這種情況就是RST包導致的。
端口不存在
如果像不存在的端口發出建立連接SYN請求，那麼服務端發現自己並沒有這個端口則會直接返回一個RST報文，用於中斷連接。
主動代替FIN終止連接
一般來說，正常的連接關閉都是需要通過FIN報文實現，然而我們也可以用RST報文來代替FIN，表示直接終止連接。實際開發中，可設置SO_LINGER數值來控制，這種往往是故意的，來跳過TIMED_WAIT，提供交互效率，不閒就慎用。
客戶端或服務端有一邊發生了異常，該方向對端發送RST以告知關閉連接
我們上面講的tcp隊列溢出發送RST包其實也是屬於這一種。這種往往是由於某些原因，一方無法再能正常處理請求連接了(比如程序崩了，隊列滿了)，從而告知另一方關閉連接。
接收到的TCP報文不在已知的TCP連接內
比如，一方機器由於網絡實在太差TCP報文失蹤了，另一方關閉了該連接，然後過了許久收到了之前失蹤的TCP報文，但由於對應的TCP連接已不存在，那麼會直接發一個RST包以便開啓新的連接。
一方長期未收到另一方的確認報文，在一定時間或重傳次數後發出RST報文
這種大多也和網絡環境相關了，網絡環境差可能會導致更多的RST報文。
之前說過RST報文多會導致程序報錯，在一個已關閉的連接上讀操作會報connection reset，而在一個已關閉的連接上寫操作則會報connection reset by peer。通常我們可能還會看到broken pipe錯誤，這是管道層面的錯誤，表示對已關閉的管道進行讀寫，往往是在收到RST，報出connection reset錯後繼續讀寫數據報的錯，這個在glibc源碼註釋中也有介紹。
我們在排查故障時候怎麼確定有RST包的存在呢？當然是使用tcpdump命令進行抓包，並使用wireshark進行簡單分析了。tcpdump -i en0 tcp -w xxx.cap，en0表示監聽的網卡。
接下來我們通過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的數量
用ss命令會更快ss -ant | awk '{++S[$1]} END {for(a in S) print a, S[a]}'
TIME_WAIT
time_wait的存在一是爲了丟失的數據包被後面連接複用，二是爲了在2MSL的時間範圍內正常關閉連接。它的存在其實會大大減少RST包的出現。
過多的time_wait在短連接頻繁的場景比較容易出現。這種情況可以在服務端做一些內核參數調優:
#表示開啓重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認爲0，表示關閉
net.ipv4.tcp_tw_reuse = 1
#表示開啓TCP連接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉
net.ipv4.tcp_tw_recycle = 1
當然我們不要忘記在NAT環境下因爲時間戳錯亂導致數據包被拒絕的坑了，另外的辦法就是改小tcp_max_tw_buckets，超過這個數的time_wait都會被幹掉，不過這也會導致報time wait bucket table overflow的錯。
CLOSE_WAIT
close_wait往往都是因爲應用程序寫的有問題，沒有在ACK後再次發起FIN報文。close_wait出現的概率甚至比time_wait要更高，後果也更嚴重。往往是由於某個地方阻塞住了，沒有正常關閉連接，從而漸漸地消耗完所有的線程。
想要定位這類問題，最好是通過jstack來分析線程堆棧來排查問題，具體可參考上述章節。這裏僅舉一個例子。
開發同學說應用上線後CLOSE_WAIT就一直增多，直到掛掉爲止，jstack後找到比較可疑的堆棧是大部分線程都卡在了countdownlatch.await方法，找開發同學瞭解後得知使用了多線程但是確沒有catch異常，修改後發現異常僅僅是最簡單的升級sdk後常出現的class not found。
參考
JAVA線上故障排查全套路：https://fredal.xin/java-error-check
線上服務的FGC問題排查：https://mp.weixin.qq.com/s/56wZ4u74MnFik72dTgnwZg
Java 中的內存溢出和內存泄露：https://mp.weixin.qq.com/s/FtY6CSbU1AHlQhRpL4_IJg