Linux 进程、线程与协程的区别与联系

进程是资源隔离的最小单位，拥有独立虚拟地址空间，fork()开销大且不适用于高并发；线程共享地址空间但需同步，崩溃会终止整个进程；协程由用户态调度、切换快，但依赖非阻塞IO和事件循环。

进程是资源隔离的最小单位，别指望它共享内存

在 linux 中，fork() 创建的每个进程都有独立的虚拟地址空间：代码段、堆、栈、文件描述符表全都不互通。你改了父进程的全局变量，子进程完全看不到；子进程 malloc 出来的内存，父进程也碰不到。这种强隔离带来稳定性——一个进程段错误（Segmentation fault），不会拖垮其他进程。但代价也很实在：每次 fork() 都要复制页表、分配内核数据结构（如 task_struct），开销大到没法用于高并发连接场景。

• 别用进程做 10k+ 并发服务，光是内存和调度压力就扛不住
• 父子进程通信必须走 pipe()、socketpair() 或 shm_open()，不能直接传指针
• ps aux 看到的每个 COMMAND 行基本对应一个独立进程，PID 不同、VSZ（虚拟内存）各自计数

线程共享地址空间，但得自己管好竞态

Linux 的线程本质是“轻量级进程”（LWP），由 clone() 系统调用带 CLONE_VM 标志创建。它们共用同一个 mm_struct（即堆、全局变量、代码段），但每个线程有独立的用户栈、寄存器上下文和 thread_info。这意味着你可以让多个线程同时读写同一块 int counter，但必须加锁——pthread_mutex_lock() 不是可选项，是必选项。否则出现 counter++ 被两个线程同时读-改-写，结果只加了一次，这种 bug 很难复现却极难排查。

• 线程崩溃（比如野指针解引用）会直接 kill -SEGV 整个进程，所有线程一起退出
• top -H 可以按线程视图看 CPU 占用，LWP 列就是线程 ID（TID），和 PID 可能不同
• 默认栈大小通常 8MB，开太多线程（比如 >2k）容易触发 Cannot allocate memory 错误，不是内存真不够，而是线程栈占满虚拟地址空间

协程不进内核，切换快但得自己调度

Linux 内核根本不认识协程。像 go 的 goroutine、python 的 asyncio.Task、c++20 的 std::coroutine，全靠运行时在用户态用 setjmp/longjmp 或 ucontext（或更现代的 makecontext）保存/恢复寄存器与栈指针。一次协程切换不触发系统调用，耗时纳秒级；而线程切换要进内核，至少微秒级。但代价是：协程必须主动让出控制权——遇到 read()、sleep() 这类阻塞调用时，整个线程（及其上所有协程）都会卡住。所以真实项目里，协程必须配合非阻塞 IO 和事件循环（如 epoll）使用。

• Go 程序中 runtime.GOMAXPROCS(1) 强制单 OS 线程，仍可跑百万 goroutine，因为调度在用户态完成
• Python 的 asyncio.sleep(1) 是协程安全的，但 time.sleep(1) 是同步阻塞，会冻结整个 Event loop
• 不要在协程里调用未适配异步的 C 扩展（比如某些数据库驱动），它可能内部用了 read() 阻塞，直接拖垮所有协程

选哪个？看瓶颈在哪儿

不是越“轻量”越好。CPU 密集型任务（如图像编码、科学计算）用多进程能真正并行利用多核；IO 密集型且连接数极高（如网关、爬虫）才适合协程；而混合型任务（如 Web 服务器既要解析 jsON 又要查 DB）常采用“进程+线程+协程”分层：用多进程抗崩溃，每进程内用线程池跑 CPU 工作，再用协程处理海量网络请求。关键在于——别让调度器成为瓶颈，也别让错误传播范围失控。

最容易被忽略的是信号处理：Linux 信号默认作用于整个进程，不是某个线程或协程。你给一个线程发 SIGUSR1，实际收到的是该线程所在进程里任意一个未屏蔽该信号的线程。协程更麻烦——它连信号掩码都得靠运行时模拟。这事一旦出错，调试起来连 gdb 都抓不住上下文。