1. 面试官抛出 Linux 面试题时真正想知道的其实只有三件事我先抛一个可能挨骂的结论把网上那份Linux 面试题 100 问从头背到尾通常拿不到高分。我既当过被问的那一方也在桌子另一侧看过不少简历真正拉开差距的从来不是你记住了多少条命令而是面试官在你答完之后追的那一句为什么。那些背出来的标准答案只要被追问一层就会露馅——比如你答用 top 看 CPU 占用对方接着问top 第一行的 load average 是 1.5可 CPU 使用率只有 20%这算正常吗背题的人当场就卡住了而真干过活的人会顺口说一句得先看有没有进程卡在 D 状态等 IO。这就是 Linux 面试题最真实的模样它表面上考命令本质上考的是你的脑子里有没有一张完整的系统地图。所以这篇东西不打算再做一份题库搬运我想换个角度把高频题背后的考察意图拆开讲清楚再补上那些网上答案里永远不会写、但面试官特别爱听的现场细节。1.1 你会用还是你知道它为什么这么用同一道题答法分三个档次。以怎么查看一个端口被谁占用为例最低档的回答是用 netstat中间档会补上netstat -tunlp | grep 端口号不过现在更推荐用ss -lntp因为它走的是内核的 netlink 接口在连接数上万的时候比 netstat 快得多最高档还会加一句如果ss看不到进程名说明当前不是 root或者进程在容器独立的 network namespace 里得进容器再看。三层答案背后是三种人第一种查过一次第二种查过很多次并且踩过性能的坑第三种理解 ss 和 netstat 取数据的路径根本不一样。面试官拿着同一道题几分钟就能把候选人分层这也是为什么Linux 面试题这类搜索词下真正有价值的内容很少——大多数人想找的是第一层答案而决定 offer 的是第三层。我个人的经验是准备阶段与其多背 50 道题不如把 20 道高频题的答案往深挖两层。挖的方法很简单每写完一个答案强迫自己再问三句——这个命令的数据是从哪来的它有什么不适用的情况如果它给出的结果和我的预期不符我下一步看什么能答上这三句面试基本就稳了。1.2 运维、后端、嵌入式问的不是同一套东西很多人忽略了一个前提同样写着Linux 面试题不同岗位的考点几乎是三套体系。运维岗最爱问故障排查链路、日志分析、权限与自动化后端岗Java、Go 这类更关心进程线程模型、内存与文件描述符限制、容器里的资源可见性嵌入式方向则围着交叉编译、内核模块、设备树、启动流程打转。岗位方向最爱考的三类题明显高出镜率的关键词系统运维故障排查、服务管理、权限安全load average、inode、systemctl、iptables后端开发进程与资源限制、网络连接状态文件描述符、TIME_WAIT、OOM、cgroup嵌入式编译工具链、内核模块、启动链路交叉编译、lsmod、insmod、根文件系统数据/中间件磁盘 IO、内存映射、参数调优iostat、page cache、swap、mmap看这张表就能明白为什么有人刷了三百道题还是觉得没用——刷的题和目标岗位的评分表根本没对齐。我建议在动手复习之前先找到目标岗位的三五份 JD把里面出现的技术词抄出来再回头决定把哪一类题挖深。这个动作花不了一小时但能省掉大量无效努力。2. 命令类题目那些能把人问出真功夫的细节命令题是所有 Linux 面试题的入场券也是最容易被轻视的部分。很多人觉得命令谁不会但恰恰是这一块面试官最喜欢用一个小小的场景把候选人筛掉。这一章我挑三个最高频的方向把常见答案往上顶一层。2.1 文本处理三件套考的是组合而不是单点grep、sed、awk 几乎是必问的但面试官真正想看的不是你会不会用-i忽略大小写而是你能不能把三者组合起来解决一个具体问题。经典场景给一个几百兆的 Nginx 日志统计访问量最高的十个 IP 及其次数。标准链路是awk {print $1} access.log | sort | uniq -c | sort -rn | head -10。这一行命令里每一步都有考点。awk {print $1}默认以空白切分取第一列sort必须先排序因为uniq -c只能合并相邻的重复行这是最常被忽略的一个前提sort -rn的-n是按数值排序而不是字典序少了它会得到 9 比 100 大 这种荒唐结果。如果面试官再追问日志字段是逗号分隔怎么办你就补上awk -F,问IP 前面有空格就说awk天然会把连续空白当一个分隔符处理。sed 的高频考点集中在原地替换和分隔符上。把配置文件里所有/usr/local/app换成/opt/app直接写sed -i s/\/usr\/local\/app/\/opt\/app/g会看到一屏反斜杠实际工作中更常见的写法是换分隔符sed -i s#/usr/local/app#/opt/app#g。这里有个新手常踩的坑——-i在不同平台上的行为不一致某些环境下必须写成sed -i 才能正常执行。生产环境改配置前我一定先跑一遍不带-i的版本看输出确认无误再落盘这个习惯帮我避免过至少两次事故。grep 的深度在于上下文检索。查日志时只知道报错内容但不知道前后发生了什么grep -C 5 OutOfMemory app.log会把报错行的前后五行一起带出来-B和-A则分别只看前和后。再加一个--include*.log配合-r就能在几层目录里只搜日志文件不至于把二进制文件也翻出来刷屏。2.2 权限、用户与 umask年年考但年年有人答错权限题最常见的问法是644 和 755 分别代表什么这是送分题但紧接着的那句追问才是分水岭目录的 x 权限和文件的 x 权限是一回事吗答案是不是。对普通文件来说x 表示可执行对目录来说x 表示能否进入这个目录、能否访问目录内文件的元信息。所以只有 r 没有 x 的目录你连ls都列不出来更别提读里面的文件了。再往上SUID、SGID、Sticky Bit 这三个特殊权限位是面试官的心头好。chmod 4755给可执行文件加上 SUID运行时进程的有效用户会变成文件属主passwd命令能改/etc/shadow靠的就是这一手。SGID 用在目录上时新建的文件会自动继承目录的属组团队协作目录经常这么配。Sticky Bit 就是/tmp那个1777作用是目录里的文件只有属主本人能删别人最多能看能建。umask 这道题几乎每次都会衍生出一个计算题umask 是 027 时新建目录和新建文件的权限是多少记法很简单目录基数是 777文件基数是 666出于安全新建文件默认不带执行位用基数减 umask。所以 777-027750666-027640。我见过不少人把文件基数也写成 777一算就露馅。还有一个小细节值得提umask 是屏蔽位而不是设置位它只影响新建对象的初始权限不会去改已有文件的权限。2.3 find、xargs 和管道组合题的重灾区find 的考点在于筛选条件的组合和-exec与 xargs 的取舍。清理七天前的临时文件find /tmp -type f -name *.tmp -mtime 7 -delete。这里7表示七天以前-7是七天以内7是正好第七天三个写法的差异经常被拿来当陷阱。更值得讲的是-exec和xargs的选择。find . -name *.log -exec rm {} \;是一条一条执行文件多了慢得让人想砸键盘换成-exec rm {} 或者find . -name *.log -print0 | xargs -0 rm会把结果批量传进去效率高一个量级。为什么非要-print0配-0因为文件名里可能有空格甚至换行符默认以换行分隔会被切碎-0用空字符分隔就不会。这个细节不写出来大部分人不会主动讲但一说出来面试官就知道你在真实环境里被文件名坑过。还有一个反直觉的点find的-name用的是通配符匹配而不是正则想用正则得加-regex。我曾经在一个项目里写-name [0-9]*想匹配纯数字文件名结果匹配出一堆以数字开头的文件排查半天才反应过来方括号在 shell 通配里是字符集而不是正则的字符类。3. 进程、内存、IO把系统原理题答成排查题原理题是最容易背、也最容易被追问的部分。我的建议是不要把它当知识点背而是当成排查时我会看哪个文件、哪一列来记。这样答出来的内容天然带着现场感而且不容易忘。3.1 进程状态里藏着的排查线索ps aux和ps -ef的区别是个高频小问题答案是前者是 BSD 风格后者是 UNIX 风格输出字段略有差异。但真正有含量的是 STAT 那一列R 是运行或可运行S 是可中断睡眠在等事件D 是不可中断睡眠Z 是僵尸T 是停止。其中 D 和 Z 两个状态最值得展开。D 状态的进程通常卡在等磁盘 IO 或网络文件系统响应此时它不响应任何信号连kill -9都杀不掉——不是权限问题是内核不检查信号。遇到 D 状态堆积正确的方向不是杀进程而是去查存储看一下iostat -x 1里设备的%util和await是不是磁盘已经跑满。这个为什么 kill -9 杀不掉 D 状态进程的问题我身边能完整答出来的人不到一半。僵尸进程的成因是子进程退出后父进程没有调用 wait 回收进程表项还留着。处理方法也很直白僵尸本身几乎不占资源只占一个进程号关键是处理它的父进程让父进程正常回收或者让父进程退出由 1 号进程接管后回收。如果看到僵尸数量持续增长那基本可以判定是父进程代码里的资源回收逻辑有问题这时候就该去看代码而不是敲命令了。顺带说一句进程优先级。Linux 的 nice 值范围是 -20 到 19数值越小优先级越高普通用户只能往正的方向调降低优先级想提高优先级需要 root 权限。后台运行常用nohup command 但如果已经在前台跑起来了可以用 CtrlZ 挂起再bg放到后台、disown让它脱离当前 shell 的作业控制表这样终端关掉也不会被挂断信号带走。3.2 free 命令的输出怎么读才不会被追问倒free -h这份输出里最容易被误读的是 buff/cache。很多人一看可用内存只剩 200M就慌了其实 Linux 会把空闲内存尽量拿来做文件缓存这部分是可回收的真正该看的是 available 这一列它才是内核估算出来新程序要内存时实际能拿到多少。字段含义排查时该怎么理解total物理内存总量固定值used已用包含被应用占用的部分free完全空闲数值小不一定有问题buff/cache缓冲区与页缓存大部分可回收available可用估算值判断内存是否紧张就看它真正内存吃紧的信号是 swap 在被频繁使用。vmstat 1输出里的 si 和 so 两列分别代表从 swap 换入和换出如果这两个值持续不为零说明物理内存已经不够系统在拿磁盘当内存用性能会断崖式下跌。再严重一步就是 OOM Killer 出手dmesg | grep -i out of memory能看到它杀了哪个进程以及当时的内存快照。这道题如果只答free 看内存面试官多半会追一句那 buff/cache 算不算占用答不上来分数就掉了。3.3 load average 高但 CPU 空闲到底发生了什么这是我最喜欢问的一道题因为它能把背过 top和理解 top的人干净利落地分开。load average 统计的是运行队列里处于可运行状态和不可中断睡眠状态的进程数注意后半句——D 状态的进程也算进去。所以当磁盘 IO 打满时一堆进程堵在 D 状态load 会飙到很高但 CPU 因为无事可做使用率可能只有百分之十几。判断思路就三步。第一步top看 load 和使用率的组合load 高、CPU 低几乎可以锁定 IO 或锁等待。第二步vmstat 1看 b 列阻塞进程数和 wa 列IO 等待占比wa 长期偏高就实锤了。第三步iostat -x 1看具体是哪块盘%util接近 100% 说明设备已经饱和await是平均等待毫秒数数值明显偏大说明有排队。这一套走下来才是面试官想听到的答案而不是load 高于核数就有问题这种含糊的判断。4. 现场排查题面试官最爱看的那条完整链路排查类题目的特点是没法背因为面试官会顺着你的回答一直往下问。反过来说只要你能把一条链路完整讲出来这一轮基本就过了。下面四道题是出现频率最高的我把链路拆开写。4.1 CPU 使用率飙到 100%你从哪一步开始标准链路是top找到高 CPU 的进程号记下 PIDtop -Hp PID看这个进程里哪个线程占得最狠把线程号转成十六进制printf %x\n TID如果是 Java 应用jstack PID | grep -A 20 十六进制线程号就能看到那个线程当时在跑什么代码。如果是非 Java 应用可以用perf top -p PID或者pidstat看热点函数。这里有个很容易被忽略的细节top默认按 CPU 排序在多核机器上按的是所有核加起来的总占用一个把单核跑满的进程在 8 核机器上只显示百分之十几容易被漏掉。这时候按一下数字键 1 展开各核或者干脆用top里按 P 强制按 CPU 排序再看。还有一种情况是us和sy的比例用户态高说明是应用自身的问题系统态高就要怀疑是不是在疯狂做系统调用比如频繁读写小文件。我实际处理过一次线上告警CPU 占用一直在 60% 左右不算特别高但接口延迟抖得厉害。最后查出来是某个定时任务在批量读小文件sy占比异常把 IO 也拖起来了。这件事让我养成了一个习惯看 CPU 从来不只看一个总数一定同时看 us、sy、wa 三个值。4.2 磁盘写不进去是空间满了还是 inode 用完了很多人第一反应是df -h但df -h只反映块空间还有一半的可能是 inode 被耗尽。报错信息通常是 No space left on device但df -h显示还有几十 G 空闲——这时候换df -i一看inode 已经是 100%。成因通常是某个目录下堆了海量的小文件比如临时文件没清理、缓存目录膨胀。定位方法是从根目录一层层往下找du -sh /*排序确定是哪个一级目录爆了然后逐层深入。文件数量太多的话du会很慢可以先find /path -xdev -type f | wc -l数一下文件数确认是不是小文件问题再决定怎么清理。清理 inode 的时候还要注意删掉文件只是释放 inode如果进程还持有这些文件的句柄空间和 inode 都不会立刻归还这个坑下一节细说。4.3 文件删了空间没释放是怎么回事Linux 里文件的空间释放条件是链接数为零且没有任何进程打开它。进程正在写日志的时候你用rm删掉文件名消失了但那个进程手里的文件描述符还指向这块数据磁盘空间就一直占着。经典的定位命令是lsof | grep deleted它会把所有被删除但仍被打开的文件列出来后面跟着持有它的进程号。解决办法有两种一是重启或者让那个进程自己重新打开日志文件很多服务收到特定信号会重新打开日志配合日志切割工具用二是用 /proc/PID/fd/N这种写法清空内容而不是删除文件。生产上更稳妥的做法是从一开始就用日志切割工具管理避免直接rm正在写的日志。这道题几乎每次问都会带出lsof的用法顺带一提lsof -p PID还能查一个进程打开了哪些文件和连接排错时非常好用。4.4 DNS 解析异常与中文文件名解压乱码这两道题看着不搭但它们有个共同点都属于配置和编码细节类问题答得好特别加分。DNS 这块常见现象是ping 域名不通但ping IP通。排查顺序是先cat /etc/resolv.conf看 nameserver 配得对不对再cat /etc/hosts看有没有被本地记录劫持然后dig 域名或nslookup 域名确认解析链路。有个高频坑是/etc/resolv.conf被网络管理服务覆盖——手动改完重启网络又变回去了说明有服务在托管它得去改对应的配置源而不是直接改这个文件。另外要注意nsswitch.conf里 hosts 那一行的顺序决定了先查文件还是先查 DNS而 resolv.conf 里的 nameserver 一般最多生效三个写多了后面的不生效。中文压缩包乱码是另一个经典场景。在本地打包的中文文件名压缩包传到服务器上解压出来一堆问号或者乱码原因是打包时用的是 GBK 编码而服务器默认按 UTF-8 解释。用 unzip 的话可以加-O CP936指定编码tar 包则要看打包时的编码情况必要时可以先解出来再用convmv -f gbk -t utf8 -r 目录批量转换文件名。这里有个注意事项转换前务必备份因为文件名转换是不可逆的转错了只能重新打包。要想从根上避免打包前统一用 UTF-8 环境或者干脆在打包时避免中文文件名。5. 把答案讲出我做过的味道技术对的人不少能把技术讲清楚的人不多这是面试里一个很现实的落差。这一章聊的是表达层面的事但它的重要性不比技术本身低。5.1 结论先行再补证据链面试官也是人一天面七八个候选人注意力是有限的。所以回答问题时不要从背景铺垫开始先把结论抛出来。举个例子问服务器变慢了怎么查先给一句我会按 CPU、内存、磁盘、网络四个方向逐个排除先看资源有没有瓶颈再看是不是单点服务的问题然后每个方向讲一个具体的命令和一个判断标准。这样面试官能立刻抓住你的框架后面追问哪个细节都有话说。我见过太多候选人一道题讲了五分钟还在铺垫背景面试官已经走神了。技术表达的核心其实是信息密度不是长度。你完全可以把我遇到过类似情况当时的排查顺序是……这句话当作开场既给了结论又天然带上了实战经历一举两得。还有一点值得说尽量在回答里带上具体数字。比如我们的日志文件一天大概涨到 20G所以切割按小时做比我们会做日志切割有说服力得多。数字是最便宜的可信度证明。5.2 遇到不会的题怎么接住没有人什么都知道关键是别慌、别编。我自己的做法是先诚实说这块我没有实际处理过紧接着给出思路如果让我来解决我会先从 A 方向看因为……如果 A 没问题就到 B 方向。很多面试官其实不在乎你会不会而在乎你面对陌生问题时的分析方法。编答案是最危险的因为追问两句就会露馅一旦被发现编造前面答得再好也会被扣分。另一个技巧是把不会的题引到你熟的领域。比如问了一个你没碰过的内核参数你可以说这个参数我没调过不过类似的场景我用过另一个方式处理思路是这样的……。注意是自然过渡不是硬拗硬转话题面试官听得出来。6. 复习节奏与反问环节怎么安排最后说点备考方法层面的东西。技术题会背不代表考场上能想起来复习的节奏和方式其实很影响发挥。6.1 两周的复习清单怎么排我不建议按命令大全的顺序从头扫一遍那样记不住也没重点。更有效的排法是按排查场景归类第 1 到 3 天命令基础与文本处理重点是 grep、sed、awk、find 的组合使用配合几个真实日志做练习第 4 到 6 天进程与资源重点是 ps/top/vmstat 的字段含义动手制造一次僵尸进程和一次内存压力看看输出长什么样第 7 到 9 天磁盘与 IO重点是 df 与 df -i 的差异、lsof 定位被删除的文件、iostat 读表第 10 到 12 天网络与服务重点是 ss、dig、resolv.conf、systemctl 与日志查看第 13 到 14 天把上面所有链路连起来用一台虚拟机自造故障自己排查这个排法最关键的是最后一步。看别人写的排查步骤和自己动手做出一次故障记忆深度完全不是一个量级。我最推荐也最推荐给别人推荐的练习方式就是在一台测试机上手动制造几个故障——把某个目录塞满小文件、用 tail 打开一个日志然后删掉它、起一个死循环的 CPU 消耗进程然后不看答案自己排查一遍。做过一轮之后所有Linux 面试题的答案都会从记忆题变成经验题。6.2 轮到你提问的时候问什么面试最后一般会留时间让你提问很多人说没有问题这其实是在浪费一次加分机会。合理的问法是把问题和岗位绑起来比如这个岗位日常处理最多的 Linux 场景是哪个方向、团队现在的监控和日志体系大概是什么样的。这类问题既显得你真的想干活也能帮你判断这个岗位值不值得去。我个人最看重的一个问题是问对方如果线上出了故障从发现到定位一般是几个人负责流程是怎么走的。对方的回答基本能反映出这个团队的技术成熟度有明确流程的团队日常肯定有规范的排查工具和复盘机制进去之后能学到东西如果回答含糊其辞那多半是救火队模式做好长期加班的心理准备。至于复习的强度我的实际体会是Linux 面试题从来不需要背一百道把二十道挖到底、亲手复现过一遍比背一百道浅层答案管用。命令是死的排查链路是活的面试官要的是后者工作中真正用得上的也是后者。