#操作系统相关题库（第六批：高频笔试题、知识点与详细解答）

很多大模型岗位虽然是算法、平台或推理方向，但笔试和面试里经常会穿插操作系统题。原因很直接：只要你碰训练系统、推理服务、并发编程、网络服务、C++ 工程或者 infra，这些题就会决定你能不能把“模型问题”解释成“系统问题”。下面这一节专门补这部分。

#为什么 OS 会出现在大模型面试里

操作系统题在这里不是独立的计算机基础考试，而是用于验证你是否理解并发、内存、进程线程、IO、锁、调度和网络这些工程底座。推理服务的排队、超时、吞吐抖动、显存/内存泄漏、日志采集和服务隔离，都离不开这些概念。

系统问题通常会把模型指标转成资源和调度问题。例如 batch 调度背后有队列和延迟；多 worker 推理背后有进程模型和共享资源；线上 RAG 背后有网络 IO、缓存、超时和回退策略。

#阅读顺序

• 先读第 60 章笔试题，补进程、线程、锁、内存和 IO 的基本概念。
• 再读第 61 章面试题，把基础概念连接到高并发服务和推理系统。
• 回答时始终补一句“大模型系统里对应哪个资源或故障现象”。

#和大模型系统的连接点

进程和线程可以连接到推理 worker、服务隔离和崩溃恢复；锁和并发可以连接到请求队列、缓存一致性和日志写入；内存管理可以连接到 CPU 内存、GPU 显存、mmap、零拷贝和泄漏定位；IO 和网络可以连接到 RAG 检索、对象存储、模型加载、超时和重试。

复习 OS 题时，不要只停在教材定义。每个概念都要补一个线上现象：线程太多导致上下文切换，锁粒度太粗导致吞吐下降，内存泄漏导致服务逐步 OOM，网络超时导致 RAG 证据缺失。这样答案才能和大模型工程岗位真正连上。

平台和应用岗位尤其要准备“从现象到 OS 概念”的反向回答。比如请求延迟长，可能是队列堆积、锁竞争、IO 阻塞或模型 decode 慢；服务偶发崩溃，可能是内存越界、资源泄漏或进程隔离不足。能把现象拆回系统资源，才说明 OS 基础不是孤立背诵。

如果目标是算法岗，OS 题不必无限深入内核实现，但要掌握和训练/推理直接相关的部分：进程线程、内存、文件 IO、网络、并发控制和性能观测。这样既能应对基础追问，也不会偏离大模型岗位的主线。

如果目标是平台岗，则需要进一步把 OS 概念和性能工具连起来：CPU 利用率、上下文切换、内存占用、文件句柄、网络连接数、队列长度和日志延迟都可能是定位线索。面试中能说出“我会先看哪些指标”，比只背进程线程定义更有工程价值。

这部分的复习边界也要清楚：它服务于大模型工程，不要求把所有内核实现细节都背完。优先掌握会直接影响训练、推理和服务稳定性的概念，剩下的按岗位需要扩展。

面试回答可以用一句话收束：OS 基础的价值，是把模型服务里的慢、抖、崩、堵拆成可观测的系统资源问题。

后续维护时，OS 附录应保持“服务于模型工程”的边界。新增内容优先补和训练、推理、并发服务、网络 IO、性能观测相关的题，不把它扩成完整操作系统教材。