写一个保存文件的接口，最直觉的写法是：拿到路径，open 一个文件，把数据 write 进去，最后 close。文件少、并发低、机器不出故障的时候，这套流程看起来没什么难度。
可一到面试追问，问题就来了。open() 返回的 fd 到底指向什么？文件名是存在 inode 里吗？两个硬链接为什么能看到同一份内容？write() 返回成功，数据是不是已经落盘？日志文件删了，为什么 df -h 还是显示磁盘满？
这些问题都绕不开文件系统。它要把路径解析成文件对象，把文件的第 N 个字节定位到底层数据块，还要处理权限、缓存、删除、重命名和崩溃恢复。
打开一个普通进程的内存信息，你会看到很多看起来反直觉的数字：进程有自己的虚拟地址空间，地址范围可能很大；真正占用的物理内存又是另一回事；同一个动态库还可能被多个进程共享。
程序写代码时只是在访问地址，操作系统看到的却是一堆更具体的问题：这块内存给谁？能不能让别的进程碰？物理内存不够时换谁出去？释放之后留下的空洞还能不能继续用？
这就是内存管理要处理的事。小 G 建议不要一上来就背分页、分段、TLB 这些名词，先抓住一条线：操作系统把程序看到的地址和真实物理内存隔开，再用分配、映射、保护和回收把内存管起来。
两个线程同时给同一个计数器加 1，看起来很小的一件事，最后结果却可能少加一次。
原因其实很简单。count++ 在源码里是一行，机器执行时通常要经历读取、计算、写回几个步骤。线程 A 刚读到旧值，还没写回；线程 B 也读到了同一个旧值。两边各自算出新值，最后写回的却是同一个结果。
为了避免这类并发问题，操作系统提供了锁和一系列同步机制。它们要解决的问题不只是一段代码能不能同时执行，还包括线程该不该阻塞、资源数量怎么控制、条件不满足时怎么等待。到了内核里，还要继续考虑中断、抢占、多 CPU、实时性和调度延迟。
这篇文章只讲操作系统视角下的同步机制。Java 里的 synchronized、ReentrantLock、AQS、CAS 和锁优化已经在 Java 锁详解 里展开过，这里不会重复那套内容。本文重点看 mutex、semaphore、condition variable、spinlock、futex 这些概念各自解决什么问题。等理解了这些同步原语，再去看 死锁详解，就更容易看懂“等待关系为什么会绕成环”。
线程 A 已经拿到了资源 1，线程 B 也拿到了资源 2。接下来，线程 A 想继续往下走，需要资源 2；线程 B 想继续往下走，又需要资源 1。
两个线程都没抛异常，也不是 CPU 把机器打满了。线上看到的现象可能只是几个请求一直不返回，线程池里的工作线程慢慢被占住。
这类问题麻烦就麻烦在这里：程序没有“算错”，而是卡在一条自己解不开的等待链上。
线程死锁说的就是这种情况：一组线程互相等对方释放资源，等待关系绕成闭环，参与其中的线程都没办法靠自己继续执行。
如果这些线程正好承载订单、支付、库存这类关键流程，外部看到的就不只是某个线程 BLOCKED 了，而是接口超时、队列堆积，甚至进程迟迟退不干净。
两个进程想交换一段数据，最直觉的想法是：A 进程把数据写到自己的内存里，然后 B 进程直接去读就行了。
不过，这在操作系统里行不通。每个进程都有独立的虚拟地址空间，A 进程里的 0x7f... 地址和 B 进程里的 0x7f... 地址并不是同一块内存。用户态进程之间不能随便互相摸内存，否则权限隔离也没法谈。
所以 IPC（Inter-Process Communication，进程间通信） 绕不开操作系统。
不要想得太复杂，我更习惯把 IPC 看成三件事：怎么传数据、怎么同步控制流、怎么做命名和权限检查。只记“管道、消息队列、共享内存”这些名字，很容易背完就忘。
进程和线程是操作系统里最基础、也最容易被混着背的两个概念。
面试里问它们的区别，很多回答会停在“进程是资源分配的基本单位，线程是 CPU 调度的基本单位”。这句话可以作为入口，但不够用。
继续往下追，就会遇到一串更具体的问题：为什么进程之间默认隔离？线程到底共享了什么？fork() 后父子进程有哪些东西相同、哪些东西已经分开？为什么多线程程序里随便 fork() 会出问题？Java 虚拟线程又算不算操作系统线程？
这篇文章就顺着这些问题展开。先把程序、进程、线程的边界讲清楚，再看 Linux 里的 fork、exec、wait、clone，最后回到上下文切换、线程模型和 Java 虚拟线程。读的时候可以抓住一条主线：进程更像资源和隔离边界，线程更像一条可以被调度的执行路径。
写一个 TCP 服务端，最直觉的写法是：主线程 accept 一个连接，就丢给一个新线程去 read、处理、write。连接少的时候这套跑得很好。
可一旦连接数冲到上万，问题就来了。在不少 Linux 发行版里，新线程默认会预留数 MB 的栈空间，常见配置是 8 MB（实际值取决于 ulimit -s、运行库和线程属性）。一万个连接哪怕栈页是按需提交的，预留的地址空间、真正用到的栈页加上线程元数据叠起来也很可观；更要命的是几千上万个线程挤在几个 CPU 核上，光是线程间的上下文切换就把 CPU 啃掉一大半，真正干活的时间所剩无几。更别提大部分连接其实是空闲的——它们各自占着一个线程，却只是在那儿干等数据。
打开任务管理器时，你可能会看到一个挺反直觉的现象：每个进程都像拿着一大片“自己的内存”，有些进程里的地址看起来还差不多，但它们并不会互相影响。浏览器、IDE、数据库同时跑，大家都以为自己有一块连续、干净、独占的空间。
这不是因为程序之间互相信任，而是操作系统在中间加了一层翻译。
程序看到的是虚拟地址，真正落到内存条上的位置，由内核和硬件一起决定。虚拟内存要讲的，也就是这层翻译怎么做、进程为什么能隔离、内存不够时又怎么把一部分数据先挪到磁盘上。
先看一个反例。
很多人大学里玩过单片机。单片机上没有复杂的操作系统，CPU 直接操作物理地址。这个环境里如果想同时跑两个程序，麻烦马上就来了：第一个程序往地址 2000 写了个值，第二个程序也刚好把数据放在 2000，那一写就把对方的数据覆盖了，两个程序一起出问题。
面试里有个很常见的套路：先问你“Kafka 为什么快”“RocketMQ 为什么扛得住堆积”，等你答出顺序写、Page Cache、零拷贝之后，面试官顺势往下挖：“零拷贝具体省掉了哪几次拷贝？”“mmap 和 sendfile 有什么区别？”“splice 又是干嘛的？”
到这一步，很多人就开始打太极了。能背出“零拷贝就是不经过用户态”的不少，能把四次拷贝、两次 DMA、几次上下文切换的账算清楚的不多。
这篇文章就从一次文件发送说起：传统 I/O 会拷几次，零拷贝的“零”到底省在哪，mmap、sendfile、splice 三条路线分别省了什么，又各自要付出什么代价。
能 Ping 通，TCP 就一定能连通吗？小 G 先给结论：不是。
这时候你可能就会有疑问了：明明 Ping 通了，TCP 怎么就挂了？更准确地说，Ping 通只能说明 ICMP Echo 这条路径在当前策略下能往返，不等于目标 TCP 端口一定可达。
说实话，我认真学完了一遍网络，还看了挺多专栏资料，在面试中第一次遇到这个问题时，确实有点懵。
答案其实很简单：Ping 使用 ICMP，TCP 连接使用 TCP。两者可能经过同一条网络路径，但中间设备会按协议类型、端口、连接状态和安全策略分别处理。
