Linux系统需实操掌握：通过/proc、strace、ps等工具观察进程线程本质（均为task_struct）、文件描述符分配逻辑、SIGKILL对D状态进程无效、swappiness实际调控页面回收倾向，而非swap启用开关。
Linux 系统不是靠“背概念”掌握的，而是靠在 /proc 里看、在 strace 里跟、在 ps 和 lsof 里验证出来的。死记硬背 fork() 和 exec() 的区别，不如亲手 strace -f /bin/sh -c 'sleep 1' 看一遍系统调用序列。
进程和线程在内核里到底怎么存的？
Linux 不区分“进程”和“线程”的内核实现——它们都是 task_struct 结构体实例，区别只在共享哪些资源：mm_struct（内存）、fs_struct（文件系统上下文）、files_struct（打开文件表）等。一个 pthread_create() 创建的线程，和 fork() 出的子进程，内核眼里只是共享程度不同的 task_struct。
实操建议：
- 用
cat /proc/对比父子进程与线程组的字段差异/status | grep -E 'Tgid|Pid|PPid|Threads' -
readlink /proc/能看到线程是否共享主程序映像/task/ /exe - 不要依赖
ps -T显示的 “LWP” 列判断“是不是线程”——它只反映调度实体，不反映资源共享关系
文件描述符为什么总从 0/1/2 开始？
因为 C 标准库启动时会显式调用 dup2() 把标准输入、输出、错误绑定到 fd 0/1/2；而内核分配 fd 的策略是“找最小未用整数”，所以只要没关闭过 0/1/2，新打开的文件就必然从 3 开始。
常见错误现象：
- 程序启动前用
close(1)关闭 stdout，再execve()，结果日志全丢进黑洞——因为后续open()或pipe()会把 fd 1 分配出去 -
system("ls > /tmp/out")失败，实际是 shell 进程的 fd 1 被意外复用，重定向失败
验证方式：
bash -c 'exec 3>/dev/null; ls -l /proc/self/fd'观察 fd 分配顺序。
为什么 kill -9 有时也不管用？
SIGKILL（信号 9）确实不能被忽略、不能被阻塞、也不能被自定义处理，但它只对处于 TASK_RUNNING 或 TASK_INTERRUPTIBLE 状态的进程生效。如果进程卡在不可中断睡眠（TASK_UNINTERRUPTIBLE，即 D 状态），比如等待坏磁盘响应或内核锁竞争，kill -9 就完全无效。
使用场景：
-
ps aux | awk '$8 ~ /^D$/ {print $2}'找出 D 状态进程 PID -
cat /proc/查看它卡在哪一行内核代码（需开启/stack CONFIG_STACKTRACE） - 这类进程唯一出路通常是重启对应硬件或整个系统——没有用户态补救手段
/proc/sys/vm/swappiness 调高真的能“多用 Swap”吗？
不能。该值控制的是内核在内存压力下“倾向回收 file-backed 页面（如文件缓存）还是 anon 页面（如堆内存）”的权重，不是“是否启用 swap”。即使设为 0，只要物理内存彻底耗尽且有匿名页，swap 仍会被触发；设为 100 也不会让空闲内存主动写入 swap。
性能影响关键点：
- 数据库类应用通常设为
1：避免重要 anon 页被换出，宁可清空 page cache - 桌面环境设为
60～80：平衡响应速度与后台程序驻留 - 改完必须
sysctl -p或写入/proc/sys/vm/swappiness生效，仅改配置文件不生效
真正决定 swap 使用频率的是 vm.vfs_cache_pressure 和实际内存分配行为，不是这个数字本身。
最常被忽略的其实是 /proc/ —— 它不只显示 mmap 区域，还暴露了每个段的权限（rw-p）、是否共享（shmem）、是否脏页（dirty）。看懂它，比背十遍虚拟内存原理都管用。
