文章目錄第一章：CPU使用率100%排查??核心判斷（top看%Cpu）??工具鏈??標準排查步驟??實戰(zhàn)案例案例1：Nginx+PHP?FPM案例2：Java應用CPU 100%??關鍵注意點第二章: CPU高，但找不到高CPU進程?結論先行第一層：故障現象第二層：兩個根因第三層：排查步驟（面試口述版）第四層：兩個典型案例第五層：踩坑關鍵點第三章: D不可中斷進程 Z僵尸進程排查（增加代碼通俗注解版）一、進程狀態(tài)速覽二、故障根因D狀態(tài)（iowait高）Z僵尸進程三、排查命令步驟1）全局觀察2）排查D狀態(tài)/iowait高3）排查Z僵尸進程四、經典案例（D+Z同時出現，附代碼說明）五、高頻踩坑點第四章: 資深運維面試｜CPU性能優(yōu)化 4道深度面試題Q1：線上定位出CPU性能瓶頸之后，你完整的優(yōu)化閉環(huán)思路是什么？很多人找到瓶頸直接改代碼上線，會踩哪些坑？Q2：同樣CPU使用率100%，us用戶態(tài)高 和 sys內核態(tài)高，你的分析思路？分別對應哪些典型線上場景？Q3：CPU優(yōu)化手段有：代碼算法優(yōu)化、緩存、CPU親和性綁定、cgroup限制CPU。生產環(huán)境如何取舍？各自適用場景？哪些手段不能隨便亂用？Q4：怎么理解「過早優(yōu)化是萬惡之源」？結合運維實戰(zhàn)，什么情況該優(yōu)化，什么情況堅決不要做優(yōu)化？??終面綜合大題（可用于壓軸）第五章: Linux CPU性能Q1：線上CPU打滿，簡述完整故障排查閉環(huán)，你會重點規(guī)避哪些坑？Q2：us高與sys高，分別代表什么？列舉典型場景與排查手段Q3：線上負載很高，但CPU idle還有20?30%，us/sy/wa都正常，請分析原因，能不能直接做CPU綁定？Q4：CPU優(yōu)化有算法優(yōu)化、緩存、CPU親和性、cgroup限制CPU；生產如何取舍，哪些手段慎用？Q5：perf采樣遇到哪些常見坑？（容器、Java、閾值、swapper）第六章： Linux虛擬內存（終面）Q1：簡述Linux虛擬內存核心原理，為什么要設計虛擬內存？Q2：malloc底層brk、mmap分配機制，區(qū)別、優(yōu)缺點？Q3：free命令如何解讀？free、buff/cache、available有哪些線上坑？Q4：top VIRT / RES / SHR / %MEM含義，生產排查踩坑？Q5：內存壓力下Linux三種內存回收；OOM、oom_score、oom_adj原理？Q6：伙伴系統(tǒng)、slab分配器，slab是否用于用戶態(tài)malloc？??SRE高頻拓展面試題Q7?1：缺頁異常分為哪幾類？Q7?2：HugePage大頁適合什么業(yè)務？有哪些生產代價？Q7?3：容器內執(zhí)行free，顯示的是容器內存還是宿主機整機？Q7?4：什么是內部碎片、外部碎片？??面試口述收尾（資深運維必背）第七章： Buffer與Cache 資深運維面試Q1：請講清楚Linux Buffer、Page Cache（buff/cache）區(qū)別？free命令中buff/cache是什么？Q2：`free`里`available`、`free`有什么本質區(qū)別？很多運維看到free很小就緊張，對不對？Q3：`echo 3 /proc/sys/vm/drop_caches`作用？線上生產環(huán)境能不能隨便執(zhí)行？3代表什么？Q4：slab中SReclaimable與SUnreclaim區(qū)別，會體現在free輸出哪里？Q5：vmstat中bi、bo是什么指標？結合buffer/cache解釋寫文件流程。??SRE拓展深挖題Q6：怎么理解臟頁dirty page？臟頁過多會有什么線上問題？Q7：buff/cache持續(xù)占用很高，業(yè)務內存充足，需要手動drop_caches釋放嗎？Q8：free、vmstat數據來源于哪里？??面試一句話收尾第八章： 系統(tǒng)Page Cache緩存 資深SRE面試題Q1：怎么評估系統(tǒng)頁緩存(page cache)的好壞？cachestat/cachetop/pcstat各自作用？O_DIRECT直接IO為什么cachetop看不到大量緩存未命中？Q2：線上業(yè)務IO慢，cachetop顯示進程READ_HIT%=100%，但是業(yè)務讀延遲依舊很高，請分析原因與排查步驟？Q3：free看到buff/cache占用很高，free內存很小，運維要不要手動執(zhí)行`echo 3 /proc/sys/vm/drop_caches`清理緩存？線上有什么風險？什么場景才適合執(zhí)行？??面試一句話收尾??面試官備用深挖題第九章： 內存泄漏 資深SRE面試題Q1：什么是內存泄漏？堆、棧、數據段、文件映射段，哪些會發(fā)生內存泄漏？線上內存泄漏會帶來哪些連鎖危害？Q2：線上懷疑存在內存泄漏，請描述完整排查流程，memleak工具原理，容器環(huán)境會遇到什么坑？Q3：C語言業(yè)務進程RES持續(xù)上漲，怎么區(qū)分是真內存泄漏還是偽泄漏？列舉常見偽泄漏場景。??面試口述收尾??面試官備用深挖題第十章： Linux內存故障排查 資深SRE面試Q1：線上收到內存告警，請描述完整排查思路，核心看哪些指標，如何區(qū)分是進程、緩存、slab、Swap導致的壓力？Q2：什么是major主缺頁、minor次缺頁？線上指標升高分別是什么現象，對業(yè)務有什么影響？Q3：Linux內存調優(yōu)有哪些常用手段？哪些參數/命令生產環(huán)境嚴禁隨意操作，會帶來業(yè)務抖動？?面試速記小結（口述小結，背完直接收尾）第十一章： 磁盤IO性能 資深SRE面試題Q1：線上業(yè)務接口響應慢，top觀察iowait很高，請描述完整排查鏈路，關鍵工具與核心指標？Q2：strace -p 綁定進程PID，pidstat確認該進程大量寫IO，但是strace抓不到write調用，會是什么原因？Q3：iostat關鍵指標%util、await、aqu?sz，解釋含義；哪些誤區(qū)容易誤導排障？?面試速記小結第十二章： 數據庫慢查詢（系統(tǒng)層+MySQL層）資深SRE面試Q1：業(yè)務接口訪問MySQL，響應耗時十幾秒，top看到iowait很高，請描述完整排查流程Q2：strace拿到mysqld的線程fd，直接把線程號傳給lsof卻查不到文件，是什么坑？Q3：除了SQL缺少索引，還有哪些外部系統(tǒng)因素，會導致MySQL查詢突然變慢？?面試速記小結第十三章： Redis響應延遲 資深SRE面試Q1：業(yè)務調用Redis查詢接口，查詢操作但接口響應很慢，top看到iowait高，但iostat磁盤%util并不高，請描述完整排查鏈路Q2：容器內運行Redis，strace看到fdatasync耗時高，如何確認這個fd對應的socket還是磁盤文件？會遇到什么容器坑？Q3：iowait高，但iostat中磁盤%util不高，是什么原因？?面試速記小結第十四章： Linux IO瓶頸快速定位 資深SRE面試Q1：線上業(yè)務變慢，收到iowait告警，請描述你快速定位IO瓶頸的完整套路？Q2：磁盤IO四大核心指標是什么？考察時容易踩哪些誤區(qū)？Q3：文件系統(tǒng)層面有哪些容易忽略的IO性能指標？?面試速記結論第十五章： Linux網絡基礎與性能 資深SRE面試Q1：簡述Linux數據包收發(fā)完整流程Q2：衡量網絡性能核心指標有哪些，分別含義？Q3：線上網絡變慢排查，你的排查步驟？?面試速記小結第十六章：C10K / C1000K / C10M 速記?? 塔尖一句話一、三階段核心對比二、必背4個概念三、生產7大故障（按出題頻率排序）四、監(jiān)控必查命令（脫口而出）五、面試黃金收尾話術第十七章 tcpdump + Wireshark 面試一頁紙（3道面試題+總結）面試題1：ping 訪問域名，單條ICMP延遲很小，但整個ping命令執(zhí)行耗時很長，可能是什么原因？如何定位解決？面試題2：線上服務器如何使用tcpdump和Wireshark做網絡故障排查，講完整操作流程，重點參數？面試題3：抓包中看到TCP斷開連接出現3個包，不是傳統(tǒng)的四次揮手，請解釋原理？一頁紙核心總結第十八章 DDoS(SYN?Flood)??核心概念??三大指標?軟中斷 softirq??識別惡意流量（SYN洪水）??緩解手段iptablessysctl內核調優(yōu)（寫入/etc/sysctl.conf，sysctl -p生效）分層防御??完整故障鏈路??面試必背短句第一章：CPU使用率100%排查??核心判斷（top看%Cpu）指標高問題方向us/ni用戶業(yè)務代碼（死循環(huán)、大量計算、Java GC頻繁）sy內核、頻繁系統(tǒng)調用、內核線程wa磁盤IO瓶頸hi/si硬/軟中斷風暴top按數字1，查看每個CPU核使用率??工具鏈top：定位高CPU進程PID，默認3s采樣pidstat 1 5：進程細分 %usr / %system / %CPUperf（線上優(yōu)先，不中斷業(yè)務）# 實時看熱點函數、調用棧perftop-g-pPID# 離線保存，適合轉瞬即逝問題perf record-g-pPID# Ctrl+C結束perf report??容器場景perf出現16進制地址：宿主機生成perf.data，docker cp拷貝進容器內執(zhí)行report解析?GDB不適合線上：會暫停業(yè)務進程Java專屬工具# 打印所有線程堆棧，定位高CPUJava線程jstackPID# 統(tǒng)計JVM各個內存區(qū)域jstat-gcPID1000??標準排查步驟top觀察CPU分項，確認用戶態(tài)/內核態(tài)/IO問題獲取高CPU進程PID（top / pidstat）若是Java進程：top?H -p PID找到高消耗線程tid，轉16進制，配合jstack定位Java代碼；也可以使用perf采樣非Java進程：perf采樣定位熱點函數根據函數/堆棧定位業(yè)務源碼，確認根因（死循環(huán)、大量循環(huán)計算、頻繁FullGC等）修改代碼/配置，壓測驗證修復效果??實戰(zhàn)案例案例1：Nginx+PHP?FPM現象：php?fpm進程CPU打滿，us98%ab壓測：ab -c10 -n10000 http://ip:10000top確認php?fpm占用CPUperf top -g -p PID找到sqrt為熱點源碼：單次請求百萬次循環(huán)執(zhí)行sqrt，遺留測試代碼刪除循環(huán)，QPS從11提升至2237案例2：Java應用CPU 100%現象：Java進程CPU持續(xù)100%，us占比極高排查流程：top發(fā)現Java進程PID=2345，CPU占用接近100%top -H -p 2345，發(fā)現線程tid=2368CPU占比很高tid轉16進制：printf "%x\n" 2368→940jstack 2345 jstack.log，在日志搜索0x940堆棧定位業(yè)務代碼：for無限死循環(huán)，沒有sleep；或者集合大數據遍歷補充：如果jstat?gc觀察到頻繁FullGC，CPU高是內存泄漏導致，優(yōu)先排查內存問題??關鍵注意點CPU使用率是一段時間采樣差值計算的平均值，不同工具采樣間隔不一樣，對比要保持間隔統(tǒng)一/proc/stat原始數據是開機累計值，不能直接拿來算使用率偶發(fā)瞬時CPU沖高，登錄現場已消失：依靠監(jiān)控 + perf record離線采樣Java使用perf：需要安裝perf符號，否則只能看到jvm內部符號；jstack更適合定位Java業(yè)務代碼問題/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////第二章: CPU高，但找不到高CPU進程?結論先行系統(tǒng)CPU整體很高，但top/pidstat看不到高CPU進程，90%是短時進程，其次是進程反復崩潰重啟。第一層：故障現象top全局us/sy高，id低；但所有進程CPU占比都很低top看到大量R(Running)運行態(tài)進程，PID快速不停變化pidstat所有進程CPU加起來遠小于系統(tǒng)總CPU第二層：兩個根因短時進程（最常見）：業(yè)務代碼exec/system/ProcessBuilder調用外部命令，進程生命周期極短，小于工具采樣間隔，top/pidstat抓不到，海量頻繁創(chuàng)建銷毀累積消耗CPU。進程反復崩潰重啟：程序崩潰，被監(jiān)控/K8s反復拉起，初始化邏輯消耗CPU，進程存活時間很短。第三層：排查步驟（面試口述版）top：看全局CPU，重點觀察R狀態(tài)進程數量、PID是否漂移；有execsnoop優(yōu)先執(zhí)行，直接捕獲exec調用，拿到子進程和父PID；沒有execsnoop，用perf全系統(tǒng)采樣，必須加-a，不能指定PIDperf record-ag-gperf reportpstree追溯父進程，定位業(yè)務服務；審查源碼外部命令調用，查看dmesg/容器日志確認是否崩潰重啟。第四層：兩個典型案例PHP：http請求exec調用stress，權限報錯快速退出，大量短時進程吃滿CPU。Java：ProcessBuilder高頻調用shell腳本，腳本執(zhí)行完立刻退出，Java主進程CPU占用并不高。第五層：踩坑關鍵點perf排查短時進程不能帶?p指定PID，必須?a全系統(tǒng)采樣，swapper是空閑內核進程直接忽略；top/pidstat是采樣平均值工具，進程壽命短于采樣間隔就捕獲不到；容器perf符號缺失：perf.data復制進容器內做report解析。面試一句話總結：CPU高找不到進程，優(yōu)先懷疑短時進程，用perf -a全系統(tǒng)抓，不要指定進程PID。///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////第三章: D不可中斷進程 Z僵尸進程排查（增加代碼通俗注解版）面試/線上速查，現象：iowait高、負載上漲、大量D/Z進程一、進程狀態(tài)速覽狀態(tài)含義關鍵影響R運行/就緒CPU調度隊列D不可中斷睡眠，等待硬件IO拉高平均負載，kill?9無效Z僵尸，子進程已退出，父未回收資源耗盡PID，無法新建進程；kill僵尸本身無效S可中斷睡眠正常等待事件，可被信號喚醒I內核線程空閑態(tài)不會拉高負載T暫停/調試跟蹤gdb、SIGSTOP觸發(fā)重點：短時D屬于正常；大量持續(xù)D、持續(xù)增長Z屬于故障。二、故障根因D狀態(tài)（iowait高）業(yè)務O_DIRECT直接IO，繞過pagecache頁緩存，直接操作物理磁盤，磁盤慢導致進程阻塞D狀態(tài)；??通俗：不使用內存緩存，每一次讀都直接訪問硬盤，硬盤速度遠慢于內存，CPU大量時間等待磁盤返回。perf看到blkdev_direct_IO內核函數就是證據。本地磁盤故障、RAID異常；NFS存儲服務端卡死，客戶端進程阻塞IO。Z僵尸進程fork()創(chuàng)建子進程，父進程未調用wait/waitpid回收子進程退出狀態(tài)；未注冊SIGCHLD信號處理函數；子進程退出速度快于父進程處理。??通俗：子進程干完活退出，父進程代碼沒執(zhí)行“收尸”邏輯，子進程就變成僵尸。父進程退出，僵尸由init(1)自動收割。三、排查命令步驟1）全局觀察top# 看load、wa(iowait)，看S列D/Z；按1看各CPUdstat1# 同時對比CPU iowait與磁盤讀寫流量2）排查D狀態(tài)/iowait高pidstat -d 1全局看進程IO讀寫；進程轉瞬變?yōu)榻┦?，strace無法attach，用全系統(tǒng)perf采樣（不加?p）perf record-ag-gperf report忽略swapper內核空閑進程；看到blkdev_direct_IO代表開啟直接磁盤IO。D狀態(tài)進程kill?9殺不掉，需等待IO返回，硬件故障極端情況只能重啟。3）排查Z僵尸進程ps-e-ostat,ppid,pid,cmd|grepZ# 拿到僵尸PID、父PPIDpstree-aps僵尸PID# 向上追溯父進程臨時緩解：重啟父進程，init自動回收僵尸；根治：代碼增加wait/waitpid或SIGCHLD信號處理。四、經典案例（D+Z同時出現，附代碼說明）現象：iowait打滿，負載高，同時僵尸進程持續(xù)增多；dstat確認wa升高伴隨大量磁盤讀；pidstat?d看到app大量讀盤；進程D狀態(tài)后迅速變成Z，strace attach失??；perf全系統(tǒng)采樣發(fā)現blkdev_direct_IO；?問題代碼：open(disk, O_RDONLY|O_DIRECT|O_LARGEFILE, 0755);開啟O_DIRECT繞過內存緩存，大量直接磁盤IO，iowait飆升。?修復：刪除O_DIRECT參數，走操作系統(tǒng)頁緩存，iowait恢復。僵尸根因：wait()寫在死循環(huán)外面，代碼永遠執(zhí)行不到//錯誤：wait放在死循環(huán)外面，永遠跑不到for(;;){for(inti=0;i2;i++){fork();}sleep(5);}while(wait(status)0);//?修復：wait移入循環(huán)內部，每輪循環(huán)回收子進程for(;;){for(inti=0;i2;i++){fork();}while(wait(status)0);sleep(5);}wait挪入循環(huán)，子進程退出后立刻被回收，不再生成僵尸。五、高頻踩坑點iowait高≠磁盤瓶頸：少量IO也會拉高wa，必須結合實際磁盤讀寫量判斷；kill僵尸進程不起作用，僵尸已經死亡，必須處理父進程；perf報告swapper是內核空閑進程，直接忽略；父進程為1號init還殘留僵尸，業(yè)務無解，大概率內核bug，只能重啟機器。?面試一句話總結：D狀態(tài)優(yōu)先排查IO：直接IO(O_DIRECT)、本地磁盤、NFS，kill?9無效；僵尸不要殺僵尸本身，定位父進程，代碼做好子進程回收。////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////第四章: 資深運維面試｜CPU性能優(yōu)化 4道深度面試題考察：實戰(zhàn)閉環(huán)、權衡取舍、線上踩坑，金字塔答題，包含問題+完整參考答案+深挖追問+追問完整答案Q1：線上定位出CPU性能瓶頸之后，你完整的優(yōu)化閉環(huán)思路是什么？很多人找到瓶頸直接改代碼上線，會踩哪些坑？?完整參考答案（金字塔）結論先行：CPU優(yōu)化不是找到瓶頸就直接改，必須走「確認瓶頸→量化基線→方案選型→對比驗證→評估副作用」完整閉環(huán)；直接改代碼上線最大風險：誤判根因、優(yōu)化帶來副作用、無法證明優(yōu)化收益。確認真瓶頸，區(qū)分根因與衍生現象。很多指標高只是現象，不是根源。例如iowait升高只是現象，根源是O_DIRECT直接IO；軟中斷CPU高是現象，根源是大量網絡小包。不能針對現象做優(yōu)化，要解決背后的根因。建立雙維度基線。不能只看系統(tǒng)CPU使用率；同時采集**業(yè)務指標（QPS、延遲、錯誤率）**和系統(tǒng)指標（CPU、上下文切換）作為優(yōu)化前基準。壓測客戶端要與業(yè)務服務隔離部署，防止壓測工具本身消耗資源，污染測試數據。多方案選型，綜合權衡。不能只看性能提升幅度，綜合評估：改造成本、代碼復雜度、可維護性、優(yōu)化副作用；拒絕拿來主義，不追求一步到位解決全部問題?；叶闰炞C，對比優(yōu)化前后。不僅看系統(tǒng)資源指標，重點校驗業(yè)務指標，防止出現CPU降了，但接口延遲升高這類負優(yōu)化。風險防控，警惕過早優(yōu)化。沒有真實業(yè)務壓力，不要提前堆砌緩存、異步、CPU綁定這類復雜邏輯，徒增維護成本。實戰(zhàn)坑舉例：直接對進程做CPU綁定，業(yè)務流量波動大時，會破壞內核調度均衡，出現單核打滿其余核空閑，整體性能反而變差。??面試官深挖追問 + 參考答案追問：優(yōu)化后CPU使用率降下來，但業(yè)務接口延遲反而升高，可能有哪些原因？答：① 優(yōu)化手段帶來額外開銷：例如引入緩存，增加鎖、緩存淘汰邏輯；② CPU綁定導致調度失衡，任務集中在個別CPU核，隊列排隊；③ 算法優(yōu)化雖然降低CPU，但增加IO/鎖等待；④ 并發(fā)線程/進程數量被限制，請求排隊堆積；⑤ 內核參數調整，犧牲延遲換取CPU利用率。追問：怎么區(qū)分觀測到的指標是根因，還是衍生現象？舉一個線上實際例子。答：根因是源頭，衍生現象是根因引發(fā)的結果。解決根因，衍生現象會自動消失。例子：大量短時fork子進程，會導致sys CPU高，sys高是現象；真正根因是業(yè)務頻繁調用exec創(chuàng)建短時進程。修復業(yè)務不再頻繁創(chuàng)建進程，sys CPU自然下降，而不是去調內核參數壓制sys指標。追問：如果環(huán)境不允許做完整壓測，只能線上灰度，基線數據該怎么獲?。看穑孩?取優(yōu)化前一段時間監(jiān)控歷史作為基線，保證流量、時間段盡量對齊；② 采用灰度發(fā)布，一部分實例優(yōu)化，一部分實例保持原樣，做同環(huán)境對照；③ 對比兩組實例的業(yè)務、系統(tǒng)指標；④ 小流量逐步放量，一旦指標異常立刻回滾。Q2：同樣CPU使用率100%，us用戶態(tài)高 和 sys內核態(tài)高，你的分析思路？分別對應哪些典型線上場景？?完整參考答案（金字塔）結論先行：us高代表業(yè)務用戶態(tài)消耗CPU；sys高代表內核態(tài)開銷；二者排查方向完全不同，先分清指標，再選擇工具定位。us（用戶態(tài)CPU高）：CPU消耗來自業(yè)務代碼邏輯典型場景：死循環(huán)、高復雜度算法、大量計算、頻繁正則表達式、Java頻繁Full GC；工具：perf top -g -p pid定位業(yè)務熱點函數；Java配合jstack、jstat -gc。sys（系統(tǒng)CPU高）：CPU消耗來自內核，由系統(tǒng)調用、上下文切換、中斷引發(fā)典型場景：大量fork/exec短時進程；頻繁鎖競爭；海量細小系統(tǒng)調用；軟硬中斷風暴；進程數量多導致頻繁上下文切換；工具：perf record -ag -g做全系統(tǒng)采樣看內核調用棧；pidstat -w觀察上下文切換；execsnoop捕獲短時exec調用。??重要坑：短時進程場景，top、pidstat抓不到高CPU進程，必須全系統(tǒng)perf采樣，不能指定?p pid。實戰(zhàn)區(qū)分小技巧：us高優(yōu)先懷疑業(yè)務代碼；sys高優(yōu)先懷疑系統(tǒng)調用、進程創(chuàng)建、中斷，不要上來就修改業(yè)務代碼。??面試官深挖追問 + 參考答案追問：Java服務sys系統(tǒng)CPU很高，你會一步步怎么排查？答：① 先看pidstat -w，觀察自愿/非自愿上下文切換，如果非自愿切換很高，線程過多、爭搶CPU；② 使用perf record -ag -g全系統(tǒng)采樣，看內核調用棧，看是系統(tǒng)調用、線程創(chuàng)建、鎖、還是中斷消耗；③ execsnoop排查是否Java通過ProcessBuilder大量創(chuàng)建外部短時子進程；④ 查看JVM配置：線程數量是否過多；⑤ 排除硬件層面中斷風暴。追問：為什么短時進程，指定perf -p PID抓不到問題？答：短時進程生命周期極短，執(zhí)行完立刻退出。perf-p需要進程存活才能附著采樣；等執(zhí)行perf命令時進程已經消亡。必須?a全系統(tǒng)采樣，捕獲系統(tǒng)內全部事件，不綁定特定PID。追問：sys高，但是沒有看到大量fork，還會有什么可能性？答：① 海量細小系統(tǒng)調用，如頻繁read/write、epoll_wait；② 大量線程上下文切換，線程數量過多；③ 硬中斷、軟中斷風暴（網絡包量大）；④ 頻繁鎖競爭，內核態(tài)自旋鎖消耗；⑤ 內存缺頁異常頻繁。Q3：CPU優(yōu)化手段有：代碼算法優(yōu)化、緩存、CPU親和性綁定、cgroup限制CPU。生產環(huán)境如何取舍？各自適用場景？哪些手段不能隨便亂用？?完整參考答案（金字塔）結論先行：優(yōu)先應用層業(yè)務邏輯優(yōu)化，其次緩存；系統(tǒng)層面CPU綁定、