Linux内核基础如何理解_系统运行原理全面解析【教程】

linux内核是系统调用、进程调度、内存管理与文件抽象的实时执行者；用户态程序受限制，需通过系统调用进入内核态；task_Struct标识进程，oom_killer按评分杀进程；VFS统一文件接口，一切皆文件是抽象而非实现。

Linux内核不是“要学的理论课”，而是你每次敲 ls、ps、top 甚至按 Ctrl+C 中断程序时，背后正在实时调度、切换、分配资源的那个“隐形操盘手”。理解它，不为写驱动，只为看懂系统为什么卡、为什么 OOM、为什么 strace 出来的系统调用总在 read() 或 epoll_wait() 上挂住。

什么是内核态和用户态？别被概念绕晕

简单说：你的程序（比如 vim 或一个 python 脚本）默认运行在 用户态——它被内核“关在笼子里”：不能直接读硬盘、不能改页表、不能发网络包。一旦它想干这些事，就得通过 open()、malloc()、sendto() 这类函数“敲门”，触发一次 系统调用，让内核代劳。
这个“敲门”过程会从用户态切到 内核态，CPU 切换特权级，栈也换成内核栈。如果内核在处理这个请求时崩溃，整机就 panic；而用户程序崩了，顶多自己退出。
常见误区：glibc 的 printf() 不是系统调用，它只是把数据塞进缓冲区，真正落盘靠的是最后调用的 write() 系统调用。

进程怎么跑起来的？从 fork() 到 task_struct

你在终端敲 bash，实际是 shell 调用 fork() 复制出一个新进程，再用 execve() 把新进程的内存空间替换成 bash 的代码和数据。每个活进程在内核里都对应一个 task_struct 结构体——它就是进程的“身份证+档案袋”，存着 PID、状态（RUNNING/INTERRUPTIBLE）、打开的文件描述符、内存映射、CPU 寄存器快照……
关键点：

• 所有 task_struct 都被链入 CPU 对应的 runqueue（运行队列），调度器只从这里挑活儿干
• 多核机器上，每个 CPU 有自己的 runqueue，进程默认绑定到某个 CPU（除非显式 sched_setaffinity()）
• 执行 ps -o pid,comm,state,wchan 时，wchan 列显示的就是该进程当前阻塞在哪个内核函数上（比如 do_sys_poll 表示正等 I/O）

内存不够用了，为什么不是直接 kill 进程？

Linux 内核不会等到物理内存彻底耗尽才行动。它有一套叫 oom_killer 的机制，在内存严重紧张时，根据每个进程的 oom_score（综合 RSS、CPU 时间、特权级等算出）选一个“最该死”的进程干掉。
但更常遇到的情况是：free -h 显示 “available” 还剩 2G，系统却卡死——这往往是因为内核无法快速回收 page cache 或 slab 缓存，或大量进程陷入 D 状态（不可中断睡眠，通常卡在磁盘 I/O）。
实操建议：

• 查 cat /proc/meminfo | grep -E "^(Mem|Swap|SReclaimable)"，重点看 SReclaimable（可回收 slab）和 SwapCached
• 用 echo 1 > /proc/sys/vm/drop_caches 可手动清 page cache（仅测试环境！生产慎用）
• 避免写死循环频繁 malloc()/free() 小块内存——容易导致 slab 碎片化，kmemleak 或 /sys/kernel/debug/slab 可辅助诊断

文件系统那句“一切皆文件”，到底怎么抽象的？

open("/dev/sda1", O_RDONLY) 和 open("/tmp/log.txt", O_WRONLY) 看似一样，但内核处理路径天差地别：
前者走的是块设备驱动，最终发命令给硬盘控制器；后者走 VFS（Virtual File System）层，再分发给 ext4 或 XFS 的具体实现。
VFS 是个“中间协议层”，它定义了统一的 struct file_operations 接口（如 read、write、ioctl），所有文件系统都必须填好这张“考卷”。
所以：

• ls /proc 看到的不是磁盘文件，而是内核内存中动态生成的“伪文件”，读它们本质是调用 proc_read() 这类内核函数
• mount -t tmpfs 创建的内存文件系统，write() 直接操作 page cache，不经过块设备层
• 误删正在被进程使用的文件（如日志），lsof +L1 能查到“deleted” 状态的 fd——只要 fd 没关，数据还在内存/磁盘上，可从 /proc/PID/fd/ 恢复

内核的复杂性不在代码行数，而在所有模块都共享同一地址空间、同一堆栈、同一中断上下文——一个驱动里的空指针解引用，可能让整个系统静默重启。所以真正要盯住的，从来不是“怎么编译内核”，而是 dmesg -T 里那几行报错、/proc 下某个值的突变、以及 perf record -e sched:sched_switch 捕获的上下文切换毛刺。