Linux 操作系统面试常见题详解

基础概念类 1. 什么是Linux内核？它与整个Linux操作系统有什么区别？2. Linux 系统是否为实时操作系统，如何将Linux改为实时系统 3. 解释Linux系统中用户空间和内核空间的区别。编译、引导与初始化 1. Linux 内核镜像编译流程 2. Linux 从硬件上电到内核启动的全过程 3. U-Boot 启动和自身重定位过程 4. U-Boot 启动时使⽤的是物理地址还是虚拟地址？MMU 要开启吗？5. U-Boot 的启动过程中为什么会关闭中断，关闭 DCACHE，关闭 MMU，关闭 TLC 等 6. U-Boot 存储介质加载差异（NOR Flash vs. eMMC）7. U-Boot 引导uImage的过程（bootm 机制）8. Linux 系统启动流程 9. MCU 的启动流程有了解么？简单聊⼀下bootloader的⼯作流程 10. 比较SysVinit、Upstart和systemd初始化系统的区别。内存管理 1. 解释Linux的虚拟内存机制及其优势。2. Linux 虚拟地址分布，用户内存组成 3. 用户空间如何进入内核空间 4. 解释mmap系统调用的作用和应用场景 5. 用户态到内核态之间的数据拷贝(消息队列和共享内存)6. 什么是页面置换算法？Linux中主要使用什么页面置换算法？进程与线程 1. 解释Linux中进程、线程和协程的区别。2. 使用ps命令可以看到进程有多种状态(R/S/D/Z等)，请解释这些状态的含义。3. 列举Linux中的进程间通信方式并比较其优缺点。4. 解释共享内存与消息队列的区别，以及各自适用场景。5. 进程调度策略 5. 什么是系统调用？请解释fork()、exec()和wait()系统调用的作用及关系。6. 互斥和同步概念 7. 互斥/同步的实现和使⽤8. 生产者-消费者模型 9. 哲学家就餐问题 10. 读者/写者问题 11. 死锁问题 12. 如何提高高并发环境下锁适用效率文件系统 1. 解释Linux文件系统中inode的概念及其作用。2. 比较ext4、XFS和Btrfs文件系统的特点和适用场景。网络管理 1. 解释Linux网络协议栈的层次结构。2. select，poll 和 epoll 差异 3. IO多路复用和多线程多进程之间关系 4. Reactor 高性能网络模式演进 5. Reactor 组合模型 6. 零拷贝技术/pagecache/大文件传输设备和驱动类 1. 解释Linux中设备文件的分类及其特点。2. 简述Linux设备驱动的层次结构。调试设计模式

基础概念类

1. 什么是Linux内核？它与整个Linux操作系统有什么区别？

考察内容：Linux基础概念理解，操作系统架构认知答案： Linux内核是操作系统的核心部分，负责管理系统资源（CPU、内存、设备等），提供硬件抽象，实现进程调度和内存管理等基本功能。而Linux操作系统是指内核加上各种系统工具、应用程序和库组成的完整系统。内核是操作系统的基础，而完整的Linux操作系统则包括GNU工具、shell、文件系统工具、网络工具等用户空间组件。

2. Linux 系统是否为实时操作系统，如何将Linux改为实时系统

实时系统通常分为两类：

硬实时系统(Hard Real-Time): 必须在严格的截止时间内完成任务，任何超时都可能导致系统完全失效或引发灾难性后果。例如：飞行控制系统、工业机器人、汽车安全气囊控制系统等。

软实时系统(Soft Real-Time): 允许偶尔错过截止时间，系统性能会下降但不会彻底失效。例如：多媒体流处理、电信设备等。

实时操作系统(Real-Time Operating System, RTOS)是一种特殊类型的操作系统，它能够在预定义的时间约束内响应和处理外部事件或数据。与通用操作系统不同，实时操作系统的核心特性在于其确定性（Determinism）和可预测性（Predictability），而不仅仅是执行速度。

标准Linux内核本质上不是一个实时操作系统，主要原因包括：

不确定性因素: 标准Linux内核设计注重平均性能和吞吐量，而非最坏情况下的响应时间

不可抢占区域: 内核中存在长时间不可抢占的代码路径

优先级反转问题: 可能出现低优先级任务阻塞高优先级任务的情况

Linux 系统不可抢占的部分

自旋锁临界区

中断禁用区域

3. 显示禁用抢占

软中断

RCU读临界区

如何将Linux改为实时系统

PREEMPT_RT补丁

这是最常用的将Linux内核转变为实时系统的方法，也是最有可能最终完全整合到主线内核的方案。

核心改造内容：

内核完全可抢占：将大多数自旋锁转换为可睡眠的RT互斥量

中断线程化：将中断处理程序转变为内核线程，使其可被调度和抢占

优先级继承：解决优先级反转问题

高精度定时器：提供微秒级定时精度

实现这些功能后，Linux可以达到软实时甚至某些硬实时系统的要求，典型延迟可降至几十微秒级别。

性能指标	标准Linux + 实时调度类	PREEMPT_RT补丁
最大中断延迟	10-100ms	10-100μs
平均中断延迟	1-10ms	5-50μs
抢占延迟	不确定	确定的上限
调度器延迟	较高	显著降低
优先级反转	常见	有效避免

3. 解释Linux系统中用户空间和内核空间的区别。

考察内容：操作系统内存结构，特权级概念答案： Linux系统将虚拟内存空间分为用户空间和内核空间：

内核空间：运行在高特权级（Ring 0），可以直接访问所有硬件资源，执行特权指令，负责系统核心功能

用户空间：运行在低特权级（Ring 3），无法直接访问硬件，需通过系统调用接口与内核交互这种分离设计保障了系统安全性和稳定性，防止用户程序直接干扰系统核心功能。

编译、引导与初始化

1. Linux 内核镜像编译流程

编译uImage的过程如下：

首先编译出原始内核ELF文件（vmlinux）

这是一个ELF格式的可执行文件

链接地址固定在0x80008000

使用objcopy工具将vmlinux转换为纯二进制镜像（Image）

去除ELF头部和其他元数据（内核在裸机环境下启动，没有ELF执行环境，需要删除无关section）

得到原始二进制内核镜像

使用gzip对Image进行压缩

生成piggz.gzip文件

减小内核体积（提高启动速度，节省Flash存储空间）

编译自解压程序的组件

head.o：引导代码

misc.o：辅助功能

decompress.o：解压缩功能

piggz.gzip.o：将压缩的内核转换为目标文件

将这些组件链接生成新的vmlinux

这个新的vmlinux是位置无关的ELF文件，放在哪都能执行

具有自解压运行能力

使用objcopy将新vmlinux转换为zImage

去除ELF头部，生成纯二进制镜像

可以直接烧写到NOR Flash或NAND Flash上，系统上电后加载到内存运行。

最后使用mkimage工具（uboot作为bootloader，加载Linux内核镜像运行，需要添加0x40字节头部信息）

将zImage和0x40头部信息合并

生成U-Boot可识别的uImage格式

uImage包含校验和、加载地址等信息

这个过程确保了内核能够在嵌入式设备上正确加载和自解压执行。

-A arm：指定架构为ARM

-O linux：指定操作系统类型为Linux

-T kernel：指定镜像类型为内核

-C none：指定压缩类型（none表示已压缩）

-a 0x80008000：指定加载地址

-e 0x80008000：指定入口点地址

-n "Linux-4.9.88"：指定镜像名称

-d arch/arm/boot/zImage：指定输入文件

uImage：指定输出文件名

mkimage工具源码分析

mkimage工具是U-Boot项目的一部分，用于创建uImage格式的镜像。以下是其核心逻辑的简化版：

uImage头部结构

uImage头部是一个64字节的结构，定义在U-Boot源码的include/image.h文件中：

2. Linux 从硬件上电到内核启动的全过程

硬件上电和ROM引导

U-Boot启动和自身重定位（通过start.S、crt0.S、relocate.S等完成）

U-Boot初始化和进入命令行

执行bootm命令引导Linux内核

3. U-Boot 启动和自身重定位过程

第一阶段（BL1）：SoC内部ROM代码加载，汇编实现，初始化关键硬件（CPU核心、时钟、关闭看门狗），初始化寄存器，设置栈，为C环境做准备。

第二阶段（BL2）：C语言实现，完成复杂初始化：

内存控制器（如SDRAM/DDR初始化）
外设驱动（串口-配置基本控制台输出、Flash、网卡等）
加载环境变量（env分区或默认配置）

主循环阶段：

加载内核镜像（如从eMMC、网络）到内存
解析设备树（DTB）
执行bootcmd命令（如bootm启动内核）

内核移交：传递启动参数（内存地址、设备树地址），跳转到内核入口点，完成控制权转移。

start.S 分析

start.S是U-Boot启动的第一个文件，包含了最初的汇编代码。它负责设置处理器的工作模式，初始化寄存器，并调用更高级别的初始化代码。

crt0.S 分析

crt0.S是C语言运行时初始化的开始，主要负责设置C语言环境并准备重定位。

board_init_f是"board initialization, first phase"的缩写，表示重定位前的板级初始化。

基础硬件初始化:

CPU时钟配置

基本GPIO设置

UART初始化（用于调试输出）

中断控制器配置

内存控制器初始化:

SDRAM/DDR控制器配置

内存时序参数设置

初始环境设置:

设置全局数据结构(gd)

初始化定时器

配置基本的控制台输出

重定位准备:

计算重定位目标地址

分配重定位后的堆栈空间

准备要复制的代码段

board_init_r是"board initialization, relocate phase"的缩写，表示重定位后的板级初始化。

重定位后调整:

重新设置全局数据结构指针

调整重定位后的跳转表

清理BSS段

完整设备初始化:

网络接口初始化

存储设备初始化（Flash、NAND、eMMC等）

USB控制器初始化

显示设备初始化

高级功能设置:

命令解析器初始化

环境变量加载

文件系统挂载

控制台完整初始化

启动准备:

自动启动脚本加载

系统启动参数准备

内核镜像加载准备

特性	board_init_f	board_init_r
执行时机	重定位前	重定位后
内存环境	有限（Flash/ROM/临时RAM）	完整（SDRAM/DDR）
栈空间	临时小栈	正式大栈
主要目标	基础初始化，准备重定位	完整系统初始化，准备启动OS
C库功能	有限支持	完整支持
可用资源	最小化	全部可用
代码位置	通常在common/board_f.c	通常在common/board_r.c

relocate.S 分析

relocate.S包含了重定位代码的核心实现，这是U-Boot启动过程中的关键部分。

4. U-Boot 启动时使⽤的是物理地址还是虚拟地址？MMU 要开启吗？

U-Boot在启动时：

使用物理地址：U-Boot早期阶段直接使用物理地址进行操作，不依赖于虚拟内存映射

MMU状态：在大多数架构上，U-Boot启动初期MMU是关闭的

5. U-Boot 的启动过程中为什么会关闭中断，关闭 DCACHE，关闭 MMU，关闭 TLC 等

6. U-Boot 存储介质加载差异（NOR Flash vs. eMMC）

NOR Flash启动（如TI AM335x）：Uboot可直接XIP（eXecute In Place）运行，BL1阶段将自身重定位至RAM后初始化DDR [通用知识]。

eMMC启动（如NXP i.MX6）：芯片ROM从eMMC固定区域加载SPL，SPL需实现eMMC驱动才能读取完整Uboot至DDR运行 [通用知识]。此时BL2需包含MMC子系统初始化。

7. U-Boot 引导uImage的过程（bootm 机制）

U-Boot中bootm命令的核心实现（简化版）：

设备树二进制文件(DTB)加载

设备树是描述硬件配置的数据结构，U-Boot需要将其传递给Linux内核。

bootargs环境变量设置

bootargs是U-Boot传递给Linux内核的命令行参数，通常包含根文件系统位置、控制台设备等信息。

U-Boot将bootargs环境变量插入到设备树的"/chosen"节点中：

boot_prep_linux过程

boot_prep_linux是U-Boot启动Linux内核前的准备过程，在这个过程中，会设置三个关键的ARM寄存器(r0、r1和r2)，这些寄存器用于向Linux内核传递重要的启动参数。

根据ARM Linux启动规范，这三个寄存器的设置和含义如下：

r0 寄存器

设置值：0

含义：根据ARM Linux启动协议，r0必须设置为0

作用：这是一个约定值，Linux内核启动代码会检查这个值，确保是从正确的启动环境中调用的

r1 寄存器

设置值：machine type ID (机器类型ID)

含义：特定的数字标识符，用于识别硬件平台/开发板

作用：

告诉内核它运行在哪种硬件平台上
内核使用这个值查找对应的machine_desc结构体，该结构体包含平台特定的初始化代码和硬件描述
对于使用设备树(DTB)的平台，可以设置为~0（全1），表示使用设备树来确定机器类型

r2 寄存器

设置值：ATAG列表或设备树(DTB)的物理地址

含义：指向内存中包含启动参数的数据结构

作用：

提供内核启动所需的关键信息，如：

内存大小和布局
根文件系统位置
命令行参数(如console设置)
初始化ramdisk/initramfs的位置

对于较新的系统，这通常是设备树二进制文件(DTB)的地址
对于较旧的系统，这是ATAG参数列表的地址

执行过程

在U-Boot的boot_prep_linux过程中：

首先清空r0寄存器，设置为0

将board_id(机器类型ID)加载到r1寄存器

将ATAG列表或设备树的物理地址加载到r2寄存器

确保CPU处于正确的状态：

SVC模式(监督模式)

所有中断禁用(IRQ和FIQ)

MMU关闭

数据缓存关闭

指令缓存可以开启或关闭

完成这些设置后，U-Boot会直接跳转到内核镜像的第一条指令，开始执行Linux内核代码。内核会读取这些寄存器中的值，用于初始化过程。

8. Linux 系统启动流程

考察内容：系统初始化，启动机制答案： Linux系统启动流程包括以下阶段：

BIOS/UEFI阶段：硬件初始化，自检，定位启动设备

Bootloader阶段：加载GRUB/LILO等引导程序，提供启动选项

内核加载阶段：加载内核镜像和initramfs到内存

内核初始化阶段：内核自解压，初始化硬件和内存管理

根文件系统挂载：从initramfs切换到实际根文件系统

用户空间初始化：启动init进程(systemd/SysVinit)

系统服务启动：根据运行级别启动各种服务

登录界面呈现：启动图形界面或终端登录提示

硬件初始化与固件阶段

计算机加电后，首先由BIOS/UEFI固件进行硬件自检（POST）和初始化。

固件检测可启动设备（如硬盘）并加载主引导记录（MBR）或UEFI启动管理器。

引导加载程序（Boot Loader）

MBR中的GRUB等引导加载程序接管控制权，加载内核映像文件（通常位于/boot目录）。

若为嵌入式系统，可能涉及U-Boot等特定引导程序[9]。

内核加载与初始化

内核解压后接管硬件，初始化内存管理、进程调度等核心功能。

挂载根文件系统并载入必需的驱动模块。

用户空间初始化（init进程）

内核启动首个用户态进程/sbin/init（现代系统可能为systemd替代）。

读取/etc/inittab或相应配置文件，进入预设的运行级别（如多用户模式）。

系统服务与终端建立

执行系统初始化脚本（如/etc/rc.d/rc.sysinit），配置网络、挂载文件系统等。

启动守护进程和服务（如SSH、cron），最终建立登录终端。

用户登录

出现登录界面，用户通过认证后进入Shell环境。

9. MCU 的启动流程有了解么？简单聊⼀下bootloader的⼯作流程

上电/复位：MCU接通电源或接收到复位信号

硬件初始化：时钟、电源管理等底层硬件初始化

向量表加载：从Flash的起始地址加载中断向量表

跳转到复位向量：执行复位向量指向的代码

应用程序执行：开始执行主程序代码

Bootloader工作流程

Bootloader是MCU中一段特殊的程序，通常位于Flash存储器的起始位置，主要职责是引导系统启动并可能提供固件更新功能。

Bootloader详细工作流程

初始化阶段

配置系统时钟

初始化必要的通信接口(UART、SPI、USB等)

初始化Flash控制器

决策阶段

检查特定标志位或GPIO状态决定进入正常启动或更新模式

可能会有超时等待机制

固件更新阶段 (如果需要)

建立与外部设备的通信

接收新固件数据

校验数据完整性(CRC校验等)

擦除目标Flash区域

写入新固件

更新校验和或版本信息

应用程序验证阶段

检查应用程序的完整性和有效性

可能包括签名验证、CRC校验等

跳转执行阶段

重置栈指针(SP)

设置程序计数器(PC)跳转到应用程序入口

可能需要重新配置中断向量表

10. 比较SysVinit、Upstart和systemd初始化系统的区别。

考察内容：系统管理工具，初始化机制演进答案：三种初始化系统比较：

SysVinit (传统):

特点：顺序启动，使用运行级别，脚本基于Shell

优点：简单，易于理解，兼容性好

缺点：串行处理慢，依赖关系处理简单，不支持按需启动

Upstart (过渡):

特点：基于事件的启动系统，支持并行启动

优点：比SysVinit快，事件驱动模型更灵活

缺点：配置复杂，功能不如systemd全面

systemd (现代):

特点：并行启动，基于依赖，统一管理系统资源

优点：启动速度最快，功能丰富(日志/容器/socket激活)

缺点：复杂度高，破坏了Unix简单性原则，争议较大

功能：统一服务管理，按需启动，资源控制，日志管理

systemd已成为大多数现代Linux发行版的默认初始化系统，提供了统一的服务管理接口。

内存管理

1. 解释Linux的虚拟内存机制及其优势。

考察内容：内存管理核心机制，分页系统答案： Linux虚拟内存机制通过将物理内存抽象为虚拟地址空间，每个进程拥有独立的虚拟地址空间，由MMU将虚拟地址转换为物理地址。主要优势包括：

内存隔离：各进程地址空间相互独立，提高安全性

超过物理内存大小的寻址能力：可使用交换空间扩展

内存保护：可设置不同页面的读/写/执行权限

共享内存实现：多进程可映射同一物理页面

按需分配：只有实际使用的内存才会分配物理页面

拓展内容：介绍 MMU

维度	等级	核心机制	典型应用场景
地址转换	★★★★★	页表遍历 (Page Walk)	Linux进程隔离
权限控制	★★★★☆	AP位 + XN位	安全飞控系统(DO-178C)
缓存加速	★★★☆☆	TLB(Translation Cache)	手机SoC性能优化
错误处理	★★★★☆	MMU Fault异常	航天器内存容错设计

2. Linux 虚拟地址分布，用户内存组成

32位系统：

总虚拟地址空间：4GB（0x0000 0000 - 0xFFFF FFFF）。
内核空间：占用高地址 1GB（0xC000 0000 - 0xFFFF FFFF），映射到所有进程的公共物理内存，存放内核代码、设备驱动等。
用户空间：占用低地址 3GB（0x0000 0000 - 0xBFFF FFFF），为进程私有的独立地址空间。
典型分界线：3:1比例（用户:内核）。

64位系统：

地址空间极大扩展（例如48位地址空间），用户空间与内核空间通过高/低地址划分，具体布局依赖于架构（如x86_64）。

代码段（Text Segment）：

存放可执行指令（如ELF文件的.text段）。

属性：只读，防止意外修改指令。

数据段（Data Segment）：

包含已初始化全局变量和静态变量（如ELF的.data段）。

属性：可读写，初始化值非零。

BSS段（Block Started by Symbol）：

存放未初始化或零初始化的全局/静态变量（如ELF的.bss段）。

属性：可读写，运行时由内核清零。

堆（Heap）：

动态内存分配区（通过malloc()/free()管理）。

增长方向：向高地址扩展（调用brk()/sbrk()调整堆顶）。

内存映射区（Memory Mapping Segment）：

加载共享库（如.so文件）、文件映射（mmap()）。

特点：可动态调整大小，用于高效I/O操作。

栈（Stack）：

存放函数调用栈帧、局部变量、参数。

增长方向：向低地址扩展（固定大小，通常8MB）。

溢出风险：无限递归可致栈溢出。

3. 用户空间如何进入内核空间

用户空间进入内核空间的核心方式是通过系统调用（system call），具体实现机制和步骤如下：

1️⃣ 硬件特权级切换

CPU通过特权级别（如ARM的EL0/EL1，x86的Ring 0-3）隔离空间：

用户态：运行在低特权级（如Ring 3），禁止直接操作硬件或执行特权指令
内核态：运行在高特权级（如Ring 0），可访问全部系统资源

2️⃣ 系统调用过程

触发软中断：

用户进程通过int 0x80（x86）或svc（ARM）指令发起软中断 [9]，主动陷入内核

上下文保存：

CPU冻结用户进程现场（寄存器值、栈指针等），存储至内核栈

向量表跳转：

通过中断描述符表（IDT） 定位系统调用处理函数入口（如system_call()）

参数传递：

用户进程需通过特定寄存器（如x86的EAX存放系统调用号）传递请求

🌰 示例： write(fd, buf, size) 的系统调用号 → 通过EAX传递 → 触发int 0x80 → 内核路由到sys_write()

3️⃣ 模式切换本质

地址空间连续性：系统调用保持进程原有页表，内核通过固定的高端地址区域（如3GB-4GB）映射物理内存

执行流切换：CPU从用户指令流重定向至内核预置的系统调用函数

自动返回机制：内核执行完对应服务后，通过iret/sret指令恢复用户进程寄存器现场并降权

⚠️ 关键约束

强制隔离：除系统调用外，进程无法通过直接修改地址访问内核空间（MMU页表禁止用户态访问内核地址页）

性能损耗：上下文切换需复制数百字节寄存器数据，高频调用需考虑零拷贝优化

💡 扩展机制

在特定场景中还可通过：

异常/中断：硬件外设触发（如缺页异常、定时器中断）自动进入内核

内核模块加载：insmod命令触发动态加载内核模块实现空间跨越

4. 解释mmap系统调用的作用和应用场景

考察内容：内存映射，高效I/O机制答案： mmap系统调用将文件或设备映射到进程的地址空间，主要作用：

文件映射：将文件内容直接映射到内存，通过内存访问操作文件

匿名映射：创建与文件无关的内存区域，常用于内存分配

共享映射：多进程可映射同一区域实现共享内存

应用场景：

应用场景	说明	示例
大文件处理	避免频繁read/write系统调用，通过内存映射直接操作文件	视频编辑软件加载4K视频文件时使用mmap减少I/O延迟
内存分配	大内存块分配时直接映射物理页，减少用户态-内核态切换	Jemalloc等现代内存分配器管理超过2MB的块时优先使用mmap
共享内存	多进程通过映射相同物理内存实现高效通信	PostgreSQL的shared_buffers使用mmap实现多后台进程共享缓存
内存映射文件	将磁盘文件"视为"内存，兼顾持久化和访问速度	LevelDB/RocksDB用mmap管理SSTable文件，MongoDB的WiredTiger存储引擎
设备驱动	直接映射设备内存到用户空间，避免内核缓冲拷贝	FPGA加速卡通过mmap暴露寄存器空间供用户程序直接控制

优势是零复制I/O和按需加载页面，提高性能和内存利用率。

5. 用户态到内核态之间的数据拷贝(消息队列和共享内存)

1. 消息队列的数据拷贝机制

在消息队列的读取和写入过程中，每次操作都会发生从用户态到内核态的数据拷贝。例如：

写消息：应用程序的数据从用户空间缓冲区复制到内核管理的队列缓冲区。
读消息：内核将队列中的数据复制到接收进程的用户空间缓冲区。

这种拷贝过程涉及两次上下文切换（用户态→内核态→用户态）和两次数据复制，导致显著性能开销。

2. 拷贝操作的根源

安全隔离需求：操作系统需要隔离用户进程与内核，确保内核数据不被用户程序直接篡改。因此用户态无法直接访问内核态内存，必须通过拷贝交换数据。

实现流程示例：

3. 对比优化方案（共享内存）

共享内存技术直接规避了上述拷贝：通过将同一块物理内存映射到多个进程的虚拟地址空间，数据直接在用户态交互。其优势包括：

零拷贝：无需经过内核缓冲区中转。
上下文切换减少：进程直接操作共享区域，无需系统调用切换状态。

4. 性能影响分析

ㅤ	消息队列	共享内存
数据拷贝次数	2次（用户↔内核）	0次
上下文切换	至少2次	无
延迟	高（微秒级）	极低（纳秒级）
适用场景	安全性要求高	高性能需求[2]

完整流程参考：用户态调用send()触发软中断进内核 → 内核锁定队列 → DMA或CPU完成用户缓冲区到内核的拷贝 → 唤醒接收进程 → 内核向接收方用户空间复制数据

结论：消息队列的数据拷贝本质是操作系统安全机制的代价，而共享内存等技术通过绕过内核中转实现性能跃升。实际选型需权衡安全隔离与性能需求[4]。

6. 什么是页面置换算法？Linux中主要使用什么页面置换算法？

考察内容：内存管理策略，缓存淘汰机制答案：页面置换算法决定内存不足时哪些页面被换出到交换空间。Linux主要使用改进的LRU (Least Recently Used) 算法，具体实现为两个LRU链表：

活跃链表（Active List）：最近被访问的页面

非活跃链表（Inactive List）：较长时间未访问的页面

Linux采用这种双链表机制实现了"近似LRU"算法，避免了传统LRU的高开销，同时考虑页面访问频率和时间因素，通过内核参数swappiness可调整交换行为倾向。

进程与线程

1. 解释Linux中进程、线程和协程的区别。

考察内容：并发编程基础，资源管理理解答案：

进程：独立的执行单元，拥有独立的地址空间、资源和PID，进程间通信需要IPC机制

线程：进程内的执行单元，共享进程的地址空间和资源，有独立的线程ID，同进程内线程通信开销小

协程：用户态的轻量级线程，由应用程序自己调度，不需要内核参与调度，切换开销极小

2. 使用ps命令可以看到进程有多种状态(R/S/D/Z等)，请解释这些状态的含义。

考察内容：进程状态管理，进程调度原理答案：

R (Running/Runnable)：进程正在运行或准备运行（在运行队列中）

S (Sleeping)：可中断睡眠，等待某事件完成

D (Disk Sleep)：不可中断睡眠，通常在等待I/O操作，不响应信号

Z (Zombie)：僵尸进程，已终止但其父进程未调用wait()回收

T (Stopped)：进程被暂停，通常由SIGSTOP或SIGTSTP信号触发

I (Idle)：空闲内核线程

3. 列举Linux中的进程间通信方式并比较其优缺点。

考察内容：IPC机制，并发编程基础答案： Linux支持多种IPC机制：

管道(Pipe)/命名管道(FIFO)：

优点：实现简单，适合父子进程通信

缺点：半双工，仅支持相关进程或同一文件系统内通信

信号(Signal)：

优点：异步通信机制，可用于进程控制

缺点：信息量有限，主要用于通知事件发生

消息队列(Message Queue)：

优点：结构化数据传输，持久化

缺点：复杂性较高，传输大数据效率不高

共享内存(Shared Memory)：

优点：传输速度最快，无需数据复制

缺点：需要同步机制，可能出现竞态条件

信号量(Semaphore)：

优点：适合多进程同步

缺点：主要用于同步而非数据传输

套接字(Socket)：

优点：可用于网络通信，跨主机，灵活性高

缺点：相对复杂，开销较大

4. 解释共享内存与消息队列的区别，以及各自适用场景。

考察内容：IPC机制选择，性能和安全性平衡答案：共享内存与消息队列的主要区别：

数据传输方式：

共享内存：直接映射同一物理内存区域，进程可直接访问

消息队列：数据需复制到队列再复制到接收进程

性能特性：

共享内存：零复制，性能最高

消息队列：需内核介入，有数据复制开销

同步机制：

共享内存：需额外同步机制（如信号量）

消息队列：自带同步特性

适用场景：

共享内存：大量数据高频传输，如视频处理、科学计算

消息队列：结构化中小数据传输，需队列缓冲特性，如生产者-消费者模型

5. 进程调度策略

5. 什么是系统调用？请解释fork()、exec()和wait()系统调用的作用及关系。

考察内容：操作系统接口，进程创建机制答案：系统调用是用户空间程序请求内核服务的接口，提供了受控的硬件资源访问方式。

三个关键系统调用及其关系：

fork()：创建当前进程的副本（子进程），子进程获得父进程的数据/代码副本，但有新的PID

exec()：用新程序替换当前进程的内存空间，保持PID不变，常在fork()后在子进程中调用

wait()/waitpid()：父进程等待子进程结束并回收资源，防止僵尸进程

典型使用模式：父进程fork()创建子进程，子进程exec()执行新程序，父进程wait()等待子进程结束。这是Unix/Linux创建新进程的基本机制，也是shell执行命令的基础。

6. 互斥和同步概念

互斥概念：由于多线程执⾏操作共享变量的这段代码可能会导致竞争状态，因此我们将此段代码称为临界区（critical section），它是访问共享资源的代码⽚段，⼀定不能给多线程同时执⾏。我们希望这段代码是互斥（mutualexclusion）的，也就说保证⼀个线程在临界区执⾏时，其他线程应该被阻⽌进⼊临界区，说⽩了，就是这段代码执⾏过程中，最多只能出现⼀个线程。

所谓同步，就是并发进程/线程在⼀些关键点上可能需要互相等待与互通消息，这种相互制约的等待与互通信息称为进程/线程同步。

注意，同步与互斥是两种不同的概念：

同步就好⽐：「操作 A 应在操作 B 之前执⾏」，「操作 C 必须在操作 A 和操作 B 都完成之后才能执⾏」等；

互斥就好⽐：「操作 A 和操作 B 不能在同⼀时刻执⾏」；

7. 互斥/同步的实现和使⽤

锁：加锁、解锁操作；

信号量：P、V 操作；

这两个都可以⽅便地实现进程/线程互斥，⽽信号量⽐锁的功能更强⼀些，它还可以⽅便地实现进程/线程同步。

锁

使⽤加锁操作和解锁操作可以解决并发线程/进程的互斥问题。根据锁的实现不同，可以分为「忙等待锁」和「⽆忙等待锁」。

忙等待锁 - 自旋锁

运⽤ Test-and-Set 指令来实现「忙等待锁」，

现代 CPU 体系结构提供的特殊原⼦操作指令 ——测试和置位（Test-and-Set）指令。

该指令既可以测试旧值，⼜可以设置新值。

忙等待锁伪代码

第⼀个场景是，⾸先假设⼀个线程在运⾏，调⽤ lock() ，没有其他线程持有锁，所以flag 是 0。当调⽤ TestAndSet(flag, 1) ⽅法，返回 0，线程会跳出 while 循环，获取锁。同时也会原⼦的设置 flag 为1，标志锁已经被持有。当线程离开临界区，调⽤unlock() 将 flag 清理为 0。

第⼆种场景是，当某⼀个线程已经持有锁（即 flag 为1）。本线程调⽤ lock() ，然后调⽤TestAndSet(flag, 1) ，这⼀次返回 1。只要另⼀个线程⼀直持有锁， TestAndSet() 会重复返回 1，本线程会⼀直忙等（一直while循环，不做任何事情，称为忙等待锁）。当 flag 终于被改为 0，本线程会调⽤ TestAndSet() ，返回 0 并且原⼦地设置为 1，从⽽获得锁，进⼊临界区。

⚠️

这是最简单的⼀种锁，⼀直⾃旋，利⽤ CPU 周期，直到锁可⽤。在单处理器上，需要抢占式的调度器（即不断通过时钟中断⼀个线程，运⾏其他线程）。否则，⾃旋锁在单 CPU 上⽆法使⽤，因为⼀个⾃旋的线程永远不会放弃 CPU。

无等待锁 - 互斥锁

⽆等待锁顾明思议就是获取不到锁的时候，不⽤⾃旋。既然不想⾃旋，那当没获取到锁的时候，就把当前线程放⼊到锁的等待队列，然后执⾏调度程序，把 CPU 让给其他线程执⾏。

无等待锁伪代码

信号量

信号量实现互斥

为每类共享资源设置⼀个信号量 s ，其初值为 1 ，表示该临界资源未被占⽤。

第⼀个线程执⾏ P 操作后 s 值变为0，表示临界资源为空闲，可分配给该线程，使之进⼊临界区。

第⼆个线程想进⼊临界区，也应先执⾏ P 操作，结果使 s 变为负值，这就意味着临界资源已被占⽤，因此，第⼆个线程被阻塞。

直到第⼀个线程执⾏ V 操作，释放临界资源⽽恢复 s 值为 0 后，才唤醒第⼆个线程，使之进⼊临界区，待它完成临界资源的访问后，⼜执⾏ V 操作，使 s 恢复到初始值 1。

⚠️

对于两个并发线程，互斥信号量的值仅取 1、0 和 -1 三个值，分别表示：如果互斥信号量为 1，表示没有线程进⼊临界区；如果互斥信号量为 0，表示有⼀个线程进⼊临界区；如果互斥信号量为 -1，表示⼀个线程进⼊临界区，另⼀个线程等待进⼊。

信号量实现同步

同步的⽅式是设置⼀个信号量，其初值为 0 。

妈妈⼀开始询问⼉⼦要不要做饭时，执⾏的是 P(s1) ，由于s1 初始值为 0，此时 s1 变成 -1，表明⼉⼦不需要吃饭，所以妈妈线程就进⼊等待状态。

当⼉⼦肚⼦饿时，执⾏了 V(s1) ，使得 s1 信号量从 -1 变成 0，表明此时⼉⼦需要吃饭了，于是就唤醒了阻塞中的妈妈线程，妈妈线程就开始做饭。

接着，⼉⼦线程执⾏了 P(s2) ，相当于询问妈妈饭做完了吗，由于 s2 初始值是 0，则此时 s2 变成 -1，说明妈妈还没做完饭，⼉⼦线程就等待状态。

最后，妈妈终于做完饭了，于是执⾏ V(s2) ， s2 信号量从 -1 变回了 0，于是就唤醒等待中的⼉⼦线程，唤醒后，⼉⼦线程就可以进⾏吃饭了。

8. 生产者-消费者模型

识别多线程并发协调机制

缓存属于共享资源，生产消费线程访问需要互斥
缓冲区空时，消费者必须等待⽣产者⽣成数据；
缓冲区满时，⽣产者必须等待消费者取出数据。说明⽣产者和消费者需要同步。
初始化emptyBuffers为N（缓存大小），初始化fullBuffers为0（默认为空）。

实现生产消费者模式

临界缓存保护

消费者线程：“满槽”非零，有数据时才能消费。操作一次减少“满槽”，增加“空槽”
生产者线程：“空槽”非零，有空间时才能生产。操作一次减少“空槽”，增加“满槽”

9. 哲学家就餐问题

死锁问题

互斥锁，确保满足进餐条件 → 不会出现死锁，进餐效率低，只能实现单人进餐

引入叉子优先级（资源排序） → 打破了循环等待的条件，不会出现死锁，可以两人进餐

奇偶编号策略 → 打破了同时持有部分资源的情况，不会出现死锁，可以两人进餐

有限等待和超时策略 → 避免了系统陷入永久死锁状态，但可能导致"活锁"问题（所有哲学家反复尝试但都失败）

信号量数组管理哲学家状态 → 更精细通知机制，只有两边没有进餐，才能进餐，进餐完毕，提醒两边等待的哲学家

详细解释第五种方式，并与方案1做对比

参考代码

时序图

主线程初始化互斥量和条件变量，并创建5个哲学家线程

每个哲学家线程交替在思考和进餐状态之间切换

当哲学家想进餐时，需要获取互斥锁，检查能否拿到两边的叉子

如果不能获取两把叉子，则通过条件变量进入等待状态

当哲学家放下叉子后，会检查左右两侧的哲学家是否可以进餐，若可以则通过条件变量发信号唤醒

程序结束时，主线程向所有哲学家线程发出信号，等待它们结束，然后清理资源

与方案一对比

两种实现方式的关键差异和改进：

锁粒度不同：

方案1：使用全局互斥量控制整个临界区，同一时间只允许一个哲学家进入临界区

方案5：使用互斥量+条件变量，只保护状态变更，而不是整个进餐过程

并发度：

方案1：严格串行，一次只有一个哲学家可以拿叉子和进餐

方案5：允许多个哲学家同时进餐（只要不共用叉子）

改进：

资源利用率提升：方案5允许不相邻的哲学家同时进餐（如1号和3号），提高了叉子利用率

吞吐量更高：可以同时有多个哲学家进餐，不必等待单个哲学家完成整个进餐过程

条件检测更精确：方案5只检查左右邻居是否在进餐，而不是阻塞所有哲学家

实现机制：

方案1：使用信号量P/V操作简单直接控制

方案5：使用条件变量实现更精细的唤醒机制，只有真正可以进餐时才被唤醒

性能优势：

方案5减少了不必要的阻塞

提高了系统整体吞吐量

更公平地分配资源，避免了某些哲学家可能的"饥饿"问题

方案5本质上实现了更细粒度的资源控制，实现了更高效的并发方案。

线程饥饿问题

方案5检查机制，按固定数组顺序，只检查是否饥饿以及左右邻居是否在进餐，不考虑等待时间，这可能导致某些位置的哲学家获得更多进餐机会，而其他哲学家长时间等待。

改进措施

引入公平性机制：

记录每个哲学家的等待时间或等待次数
在资源竞争时优先考虑等待时间最长的哲学家（动态优先级）

实现排队机制：

维护一个饥饿哲学家的等待队列
按照先到先得的原则分配资源

解决方案	实现机制	效率	线程饥饿问题	优点	缺点
1. 叉子优先级（资源排序）	给每个叉子分配唯一的编号，哲学家必须按叉子编号顺序获取	中等	可能存在	• 完全避免死锁 • 实现简单 • 可以保证两人同时进餐	• 可能导致特定哲学家频繁获得资源 • 资源利用不均衡 • 低编号叉子竞争更激烈
2. 奇偶编号策略	奇数编号哲学家先拿左边叉子，偶数编号先拿右边叉子	中等	较低风险	• 完全避免死锁 • 简单易实现 • 可以保证两人同时进餐 • 资源分配更均衡	• 奇偶哲学家组之间可能存在资源偏好 • 在某些情况下仍可能出现部分哲学家长时间等待
3. 有限等待和超时策略	哲学家获取叉子时设置超时时间，超时后放下已获得的叉子并重试	较低	高风险	• 避免永久死锁 • 系统总能继续运行 • 简单易实现	• 容易出现活锁问题 • 资源利用效率低 • 可能导致严重的线程饥饿 • 大量无效的加锁/解锁操作
4. 条件变量和互斥锁 (dining_philosophers.c)	使用条件变量等待条件满足，只有两边都空闲才能进餐	高	几乎不存在	• 避免死锁 • 资源分配公平 • 高效率 • 减少无谓的尝试 • 可以保证两人同时进餐	• 实现相对复杂 • 需要额外的条件变量和状态管理

10. 读者/写者问题

11. 死锁问题

死锁概念

多线程编程中，可以添加互斥锁防止多线程竞争共享资源导致的数据错乱。假如两个线程为了保护两个共享资源而使用了互斥锁，可能会造成两个线程都在等待对⽅释放锁，两个线程一直互相等待，没办法继续运行，这种情况叫做死锁。

死锁只有同时满⾜以下四个条件才会发⽣：

互斥条件；

持有并等待条件；

抢占但不可剥夺条件；

环路等待条件；

死锁示例-deadlock_example.c

strace + gdb 排查死锁

使用 strace 分析死锁场景时，关注 futex 系统调用尤为重要。下面是一个线程死锁的示例输出及其解读：

解读：

进程附加：首先可以看到 strace 附加到了主进程(12658)及其创建的两个线程(12659, 12660)

锁获取情况：

线程1获取了 mutex1，之后尝试获取 mutex2

线程2获取了 mutex2，之后尝试获取 mutex1

死锁形成：通过 futex 系统调用可以清晰看到：

[pid 12659] 线程在地址 0x58c58afa2100 上调用 futex 并处于 FUTEX_WAIT_PRIVATE 状态，等待 mutex2

[pid 12660] 线程在地址 0x58c58afa20c0 上调用 futex 并处于 FUTEX_WAIT_PRIVATE 状态，等待 mutex1

两个调用都是 <unfinished ...>，表示系统调用未完成，线程被阻塞

死锁特征：最关键的特征是多个线程都在等待 futex，且都处于未完成状态

通过这种方式，strace 让我们能够直观地看到死锁形成的过程：两个线程各自持有一个锁，同时试图获取对方持有的锁，形成了经典的死锁局面。

因为线程 1 在等待线程 2 所持有的 mutex2, ⽽同时线程 2 ⼜在等待线程 1 所拥有的 mutex1, 所以可以断定该程序发⽣了死锁。

死锁易发场景和解决方法

1. 资源获取顺序不一致

场景：当多个线程以不同顺序获取多个锁时，容易形成循环等待。

解决方案：

实施一致的锁获取顺序（有序资源分配）

对所有线程强制使用相同的锁获取顺序，例如按锁的内存地址排序

2. 嵌套锁（锁层次结构混乱）

场景：在已持有锁的情况下获取另一个锁，尤其是在复杂的调用层次中。

示例：函数A获取锁1并调用函数B，函数B获取锁2并调用函数C，函数C尝试获取锁1。

解决方案：

定义清晰的锁层次结构，低级别的锁不能在持有高级别锁的情况下获取

使用锁层级设计模式，为每个锁分配层级编号，只允许从高到低获取

使用工具（如Java的JVM锁分析）检测潜在的锁层次违规

示例

锁层次设计模式示例

锁层次结构是一种防止死锁的有效策略，通过为每个锁分配层级编号，并强制按照从高到低的顺序获取锁。以下是具体实现示例：

基本原则

为系统中的每个锁分配一个唯一的层级编号

线程只能按照从高层级到低层级的顺序获取锁

必须在获取低层级锁之前释放所有高层级锁

代码实现示例

使用示例

实际应用场景

在复杂系统中，可以按照以下方式组织锁层次：

系统级锁 (最高层级 10000+)

全局配置锁

进程管理锁

应用级锁 (层级 5000-9999)

用户会话锁

应用状态锁

服务级锁 (层级 2000-4999)

网络连接锁

数据库连接池锁

缓存管理锁

资源级锁 (层级 1-1999)

具体文件锁

内存区域锁

单个对象锁

锁层次结构的优势

死锁预防：通过强制锁获取顺序，从根本上消除循环等待条件

问题早期检测：违反层次规则时立即报错，而不是等到死锁发生

代码可维护性：明确的锁层次结构使并发代码更易于理解和维护

调试简化：当发生锁相关问题时，层次结构提供了清晰的上下文信息

注意事项

确保在设计初期就定义好锁层次结构，后期修改成本高

为锁层级预留足够的空间，以便将来可以在现有层级之间插入新层级

记录并文档化锁层级设计，确保团队成员理解并遵循

考虑使用自动化工具验证锁层级规则的遵守情况

通过实施锁层次设计模式，可以有效防止嵌套锁导致的死锁问题，提高并发程序的可靠性和可维护性。

参考: Use Lock Hierarchies to Avoid Deadlock

3. 无限等待资源（无超时机制）

场景：线程无限期等待一个永远不会被释放的资源。

示例：线程等待一个已经崩溃的线程释放的锁。

解决方案：

实现锁超时机制（如pthread_mutex_timedlock）

使用尝试获取锁的非阻塞方法（如pthread_mutex_trylock）

实现资源分配的回退机制，当无法获取所有需要的资源时释放已获取的资源

4. 持有锁时进行阻塞操作

场景：线程在持有锁的同时执行可能阻塞的操作（如I/O、网络请求）。

示例：线程获取锁后执行数据库查询，导致其他需要该锁的线程长时间等待。

解决方案：

最小化临界区，锁保护的代码应尽可能简短

避免在持有锁时执行可能阻塞的操作

使用细粒度锁替代粗粒度锁，只锁定必要的资源

考虑使用读写锁等更灵活的同步机制，允许并发读取

12. 如何提高高并发环境下锁适用效率

锁的对比分析与性能优化

1. 锁的成本开销

互斥锁 (Mutex)

成本开销: 中等

特点:

涉及用户态和内核态切换
线程阻塞与唤醒操作成本较高
适用于竞争不频繁但持续时间较长的场景

自旋锁 (Spinlock)

成本开销: 轻量级（但可能导致CPU高负载）

特点:

避免了线程上下文切换
通过循环检测锁的状态（忙等待）
持续占用CPU资源
适用于锁竞争持续时间非常短的场景

读写锁 (Read-Write Lock)

成本开销: 中等到较高

特点:

区分读操作和写操作
允许多个读操作并发
实现比互斥锁更复杂
额外维护读写状态增加了开销

乐观锁 (Optimistic Lock)

成本开销: 轻量级

特点:

非阻塞算法
基于冲突检测而非预防
通常使用版本号或CAS操作
无需内核态切换

2. 适用场景

互斥锁

临界区执行时间较长的场景

线程竞争不是特别激烈的情况

需要保证强一致性的共享资源访问

示例：哲学家就餐问题中的资源分配

自旋锁

临界区执行时间极短的场景

在多CPU系统中效果更佳

预期等待时间短于上下文切换时间的情况

示例：短时间的计数器更新、状态标志修改

读写锁

读多写少的场景

读操作远多于写操作的数据结构

需要提高读取性能的共享资源

示例：配置信息、缓存数据的并发访问

乐观锁

冲突概率低的高并发场景

读操作远多于写操作的情况

不希望阻塞线程的场景

示例：数据库事务、无锁数据结构

3. 锁选择依据

竞争频率与强度

高频率强竞争: 考虑使用互斥锁或分段锁策略

低频率竞争: 可以使用乐观锁

中等竞争: 可根据读写比例选择合适的锁

临界区执行时间

极短 (<1μs): 自旋锁

短 (1-10μs): 自旋锁或互斥锁

中等 (10-100μs): 互斥锁

长 (>100μs): 互斥锁或读写锁

读写比例

读多写少: 读写锁或乐观锁

读写平衡: 互斥锁

写多读少: 互斥锁

系统资源

CPU核心数: 多核系统更适合自旋锁

内存限制: 需考虑锁实现的内存开销

实时性要求: 自旋锁可能提供更好的响应时间

4. 提高高并发性能的策略

减少锁粒度

使用细粒度锁替代粗粒度锁

实施分段锁策略（如Java中的ConcurrentHashMap）

只锁定必要的共享资源

减少锁持有时间

缩小临界区范围

将非必要操作移出临界区

优化临界区内的算法效率

避免不必要的锁竞争

使用线程本地存储(TLS)

采用无锁数据结构

使用原子操作替代锁

合理选择锁类型

根据具体场景选择最合适的锁

考虑混合使用多种锁策略

在某些情况下使用无锁算法

采用更高级的并发控制方式

读写分离

使用并发队列

采用actor模型或CSP模型

考虑无共享设计

5. 实际案例分析

案例：哲学家就餐问题

使用互斥锁保护临界资源（叉子）

使用条件变量实现线程等待和唤醒

这种情况适合互斥锁，因为：

资源争用明确（每个哲学家需要两把叉子）
需要强一致性保证（避免死锁）
持有资源时间相对较长（进餐过程）

可能的优化：按顺序获取资源来避免死锁

文件系统

1. 解释Linux文件系统中inode的概念及其作用。

考察内容：文件系统核心数据结构，存储管理答案： inode（索引节点）是Linux文件系统中的核心数据结构，每个文件/目录都对应一个inode，存储了文件的元数据（不包含文件名），主要包括：

文件大小、类型、权限、时间戳（创建/修改/访问时间）

文件所有者和组信息

文件数据块的指针（直接/间接指针）

硬链接计数

inode的作用是将文件名与实际数据分离，实现硬链接机制，并高效存储文件元数据。文件名存储在目录项中，目录项将文件名映射到inode号。

2. 比较ext4、XFS和Btrfs文件系统的特点和适用场景。

考察内容：文件系统类型比较，存储方案选择答案：

ext4:

特点：ext家族的改进版，稳定成熟，兼容性好，支持日志功能

优势：性能稳定，兼容性最佳，碎片化较低

缺点：缺乏高级特性如快照、内置RAID

适用：通用系统，对稳定性要求高的场景

XFS:

特点：高性能64位日志文件系统，优化大文件和并行I/O

优势：大文件处理能力强，可扩展性好，元数据操作并行化

缺点：收缩文件系统困难，小文件性能较弱

适用：大文件存储，高吞吐量要求（如媒体服务器）

Btrfs:

特点：新一代写时复制(CoW)文件系统，支持快照、校验和、内置RAID

优势：数据完整性高，支持透明压缩/加密，动态调整大小

缺点：相对较新，部分功能稳定性仍在提高中

适用：需要快照/数据完整性校验的场景，如数据库存储

网络管理

1. 解释Linux网络协议栈的层次结构。

考察内容：网络子系统架构，协议实现答案： Linux网络协议栈基于OSI和TCP/IP模型，具有以下层次结构：

说⼀下⽹络分层。然后⾯试官在我回答之后⼜问了⼏个常⽤协议在哪层；其中，还问了ARP协议在哪层，我回答在⽹络层。然后⾯试官问我你知道ARP协议是什么吗？我解释了⼀通。最后⾯试官说通常认为它是在数据链路层。我是记得我看书的时候是写的属于⽹络层，回来之后查了⼀下，具体内容如下：很多教科书和培训教材上，都把ARP协议划分到⽹络层。我想主要的原因在于ARP协议属于TCP/IP协议簇，⽽在TCP/IP模型中，所有定义的协议⾄少是在⽹际层（或称⽹络层，IP层）。但是，按照OSI的标准,当数据向下传递时,每层会加上⾃⼰的信息,各层互不⼲扰.这样当⽹络层的IP包进⼊链路层时,链路层该如何加这个头部的⽬标信息呢?它要依靠ARP协议来完成.显然如何加链路头并不是⽹络层的功能。⽽且，ARP协议⼯作时，并不使⽤IP的包头。所以也有很多⼈说，ARP是链路层的。可以说，在TCP/IP模型中，ARP协议属于IP层；在OSI模型中，ARP协议属于链路层。

11、TCP黏包问题是如何解决的？（我是通过在头部携带数据包的⼤⼩，然后对⽅接收完同等⼤⼩的数据后再回发⼀个标志通知继续发下⼀个包）⾯试官继续问那还要别的⽅法？（我说⽬前我只⽤过这种⽅法，别的还不清楚

2. select，poll 和 epoll 差异

IO多路复用技术是单进程可以监测多个文件描述符技术，提高系统运行并发性。

select 使用BitsMap存储已连接文件描述符（对于网络事件，就是socket集合）集合，然后调用select函数，将文件描述符集合拷贝到内核里。内核负责检测是否有事件产生，检测方式是遍历文件描述符集合，检测到就将对应的socket设置为可读或者可写，接着将文件描述符拷贝到用户态里。用户态再用遍历方式找到可读或者可写的socket，然后对其进行处理。

发生两次遍历，两次拷贝
BitsMap固定长度，内核支持的文件描述符长度有限（由FD_SETSIZE指定，默认为1024）

poll 突破BitsMap限制，使用链表存储文件描述符，但仍然都需要遍历⽂件描述符集合来找到可读或可写的 Socket，时间复杂度为 O(n)。也需要在用户态和内核态拷贝文件描述符集合。

epoll 有两个方面改进，1. 内核中使用红黑树存储文件描述符集合，增删改查复杂度是O(log n)通过epoll_ctl() 添加待检测的文件描述符，而不是传输文件描述符集合；2. 采用事件驱动机制，内核维护一个链表来管理就绪事件，只将有就绪事件的文件描述添加进来。用户调用epoll_wait()，返回就绪文件描述链表，而非遍历查询整个文件描述符集合。

监听文件描述符越多，性能不会大幅度降低
可以同时监听的socket非常多，为系统定义的进程打开的最大文件描述符个数
epoll支持水平触发和边缘触发机制，而select和poll只支持水平触发，边缘触发比水平触发更高效些
IO多路复用要采用非阻塞I/O使用，因为返回的事件不一定可读取，最好搭配非阻塞I/O，以应对一些特殊情况。

3. IO多路复用和多线程多进程之间关系

多进程和多线程可以充分利用多核潜力，适合计算密集型任务。但多进程和多线程上下文切换，共享资源管理更麻烦，相比多进程，多线程间通讯负担更小些。总体来说，多进程最多支持几百连接，多线程最多支持1000多连接。而要解决C10K问题，必须要采用IO多路复用技术。

4. Reactor 高性能网络模式演进

多进程/多线程模型，建立新进程/线程来处理新连接，连接完成后关闭新进程/线程，频繁创建和销毁带来性能开销，造成资源浪费。另外一个线程负责一个连接，只能建立几百到几千连接。

采用“资源复用”方式，使用线程池来处理连接，连接分配给线程，一个线程负责多个连接。这会引入新问题，线程⼀般采⽤「read -> 业务处理 -> send」的处理流程，当负责的某个连接业务发生阻塞，线程无法处理其他连接的业务。

socket改成非阻塞方式，不断轮询调用read操作，这种解决方法提高CPU占用率，连接变多，轮询效率会变低。

那有没有办法在只有当连接上有数据的时候，线程才去发起读请求呢？答案是有的，实现这⼀技术的就是 I/O 多路复⽤。（在检测到是否有数据这步骤非阻塞，再调用read方法，还会有存在阻塞，需要等待数据从内核拷贝到用户空间。）

最后对 I/O 多路复⽤，形成 Reactor 模式，Reactor 模式也叫 Dispatcher 模式，即I/O 多路复⽤监听事件，收到事件后，根据事件类型分配（Dispatch）给某个进程 / 线程。

5. Reactor 组合模型

Reactor 模式主要由 Reactor 和处理资源池这两个核⼼部分组成，它俩负责的事情如下：

Reactor 负责监听和分发事件，事件类型包含连接事件、读写事件；

处理资源池负责处理事件，如 read -> 业务逻辑 -> send；

Reactor 模式是灵活多变的，可以应对不同的业务场景，灵活在于：

Reactor 的数量可以只有⼀个，也可以有多个；

处理资源池可以是单个进程 / 线程，也可以是多个进程 /线程；

灵活组合Reactor和处理资源池类型，可以获得如下几个模式：

单 Reactor 单进程 / 线程

Reactor 对象的作⽤是监听和分发事件；Acceptor 对象的作⽤是获取连接；Handler 对象的作⽤是处理业务；

第一个方案存在两个缺点：

第⼀个缺点，因为只有⼀个进程，⽆法充分利⽤多核 CPU 的性能；

第⼆个缺点，Handler 对象在业务处理时，整个进程是⽆法处理其他连接的事件的，如果业务处理耗时⽐较⻓，那么就造成响应的延迟；

所以，单 Reactor 单进程的⽅案不适⽤计算机密集型的场景，只适⽤于业务处理⾮常快速的场景。

单 Reactor 多线程 / 多进程（基本看不到应用）

单 Reator 多线程的⽅案优势在于能够充分利⽤多核 CPU 的能，那既然引⼊多线程，那么⾃然就带来了多线程竞争资源的问题。

「单 Reactor」的模式还有个问题，因为⼀个 Reactor 对象承担所有事件的监听和响应，⽽且只在主线程中运⾏，在⾯对瞬间⾼并发的场景时，容易成为性能的瓶颈的地⽅。

多 Reactor 多进程 / 线程

多 Reactor 多线程的⽅案虽然看起来复杂的，但是实际实现时⽐单 Reactor 多线程的⽅案要简单的多，原因如下：

主线程和⼦线程分⼯明确，主线程只负责接收新连接，⼦线程负责完成后续的业务处理。

主线程和⼦线程的交互很简单，主线程只需要把新连接传给⼦线程，⼦线程⽆须返回数据，直接就可以在⼦线程将处理结果发送给客户端。

6. 零拷贝技术/pagecache/大文件传输

read/write方法：对于网络文件服务场景，read/write方法产生两次系统调用，4次上下文切换，存在4次数据拷贝（磁盘文件到内核空间DMA拷贝，read方法将内核空间数据拷贝到用户空间，write方法将用户空间数据拷贝到内核socket缓存，socket缓存通过DMA拷贝到网口硬件，其中两次需要CPU参与）。

mmap/write方法：使用mmap替代read方法，mmap/write方法产生两次系统调用，4次上下文切换，存在3次数据拷贝（mmap直接将内核空间数据缓存拷贝到socket缓冲区，取代内核空间和用户空间之间两次拷贝，但还是需要CPU参与，因此还不是真正意义上的0拷贝。而且存在上下文切换，带来系统资源的浪费）。

sendfile方法：使用sendfile取代read/write，减少一次系统调用，上下文切换只有两次。但是内核态下，还是需要CPU将内核缓冲区的数据拷贝到Socket缓冲区。

如果⽹卡⽀持支持SG-DMA，可以进⼀步减少CPU 把内核缓冲区⾥的数据拷⻉到 socket 缓冲区的过程。缓冲区描述符和数据⻓度传到 socket 缓冲区，这样⽹卡的 SG-DMA 控制器就可以直接将内核缓存中的数据拷⻉到⽹卡的缓冲区⾥，此过程不需要将数据从操作系统内核缓冲区拷⻉到 socket 缓冲区中，减少了⼀次数据拷⻉，而且全程无需CPU参与数据拷贝。

pagecache（LRU，预读）内核将磁盘文件拷贝到内核缓冲区里，这个缓冲区就是磁盘高速缓存（pagecache）。零拷⻉使⽤了PageCache技术，可以使得零拷⻉进⼀步提升了性能，主要通过两点实现：

缓存最近使用文件
预读功能

这两个做法，将⼤⼤提⾼读写磁盘的性能。但在传输⼤⽂件（GB 级别的⽂件）的时候，PageCache 会不起作⽤。主要有两个原因：

PageCache 由于⻓时间被⼤⽂件占据，其他「热点」的⼩⽂件可能就⽆法充分使⽤到PageCache，于是这样磁盘读写的性能就会下降了；
PageCache 中的⼤⽂件数据，由于没有享受到缓存带来的好处，但却耗费 DMA 多拷⻉到 PageCache ⼀次；

因此对于大文件，无法使用pagecache（使用pagecache叫做缓存IO，跳过叫做直接IO），只能使用直接IO。另一个问题是：大文件读写情况下，假如使用阻塞方式，会造成系统长时间阻塞，造成系统性能下降，因此要更换成非阻塞异步IO方式。

为什么不用IO多路复用方式？这是因为多路复用技术只是不阻塞数据就绪过程，将数据从内核缓冲区拷贝到用户缓冲区还是需要阻塞等待，大文件情况下仍会严重影响系统性能。

因此在高并发传输⽂件的时候，我们要根据⽂件的⼤⼩来使⽤不同的⽅式：

传输⼤⽂件的时候，使⽤「异步 I/O + 直接 I/O」；
传输⼩⽂件的时候，则使⽤「零拷⻉技术」；

设备和驱动类

1. 解释Linux中设备文件的分类及其特点。

考察内容：设备模型，驱动基础答案： Linux使用设备文件表示设备，分为三类：

字符设备(Character Device)：

特点：顺序访问，不可随机寻址

示例：终端、串口、键盘

主要操作：read/write按字节流处理

块设备(Block Device)：

特点：随机访问，以块为单位

示例：硬盘、SSD、U盘

主要操作：支持缓冲和随机访问

网络设备：

特点：不通过设备文件访问，使用socket接口

示例：以太网卡、无线网卡

主要操作：通过网络协议栈访问

设备文件位于/dev目录，使用主次设备号标识，通过"一切皆文件"哲学，统一了设备访问接口。

2. 简述Linux设备驱动的层次结构。

考察内容：驱动架构，内核模块化设计答案： Linux设备驱动的层次结构分为：

用户空间接口层：系统调用、设备文件、ioctl接口

内核子系统层：VFS、字符/块/网络设备框架

设备驱动层：实际的驱动程序代码，实现设备操作

硬件抽象层：提供硬件访问的通用方法

物理设备层：实际的硬件设备

这种分层结构使驱动开发模块化、可重用，并提供了统一的接口。

5、Linux设备驱动开发过程中，要调⽤相关的API进⾏内存分配，能答上⼏个（kmalloc、 vmalloc...），⾯试官进⼀步问，这⼏个API的区别（没答上）

内存 kmalloc vmalloc

usb全双⼯、半双⼯

移植过程中，⽹卡驱动做了那些⼯作？

写过那些驱动，讲⼀个你熟悉的？

写驱动过程中，遇到过什么问题，如何解决的？

对⽹络设备驱动有了解吗？

3.linux中断底半步机制。 4.linux应⽤同步和互斥的⼿段。

字符设备有哪些？和块设备有什么区别？如何写⼀个字符设备驱动？字符设备有键盘，⿏标等。字符设备和块设备的区别主要是访问⽅式不同，访问字符设备是以字符流的⽅式访问的，访问块设备是以块为单位，并且可以随机访问。

⽤⼾栈和内核栈是同⼀个区域吗？有什么区别？不是。⽤⼾栈和内核栈是两个独⽴的区域。内核栈保存的是内核态程序运⾏的时候相关寄存器信息，⽤⼾栈保存的是⽤⼾态的内容。

⽤⼾空间和内核空间的通信⽅式？ API函数，Copy_from_user，get_user等。2.proc⽂件系统 3.mmap系统调⽤ 4.使⽤⽂件

中断的响应执⾏流程？听过顶半部和底半部吗？讲讲 cpu接受中断->保存中断上下⽂跳转到中断处理历程->执⾏中断上半部->执⾏中断下半部->恢复中断上下⽂。顶半部执⾏⼀般都是⽐较紧急的任务，⽐如清中断。下半部执⾏的是⼀些不太紧急的任务，可以节省中断处理的时间。

写过那些驱动？讲下LCD驱动如何编写？

10. tcp粘包（协议栈的粘包？这个不是很清楚）

调试

在⽤⼾态开发中程序跑⻜，出现段错误等情况，你通过什么⽅式去定位？

你对内存泄漏了解吗，在写代码中如何防⽌内存泄漏，如何进⾏调试？出了⼀道题⽬：如何判断程序写的是否有内存泄漏，只是⽤⽂本检测，写⼀段伪代码。也即是是说，将.c⽂件读取到程序中，结果输出是否有内存泄漏，请实现这个测试程序。（这道题没有很好思路，⼤概讲了⼀些正则表达式做判断之类的）

设计模式

软件设计六⼤原则、开闭原则