你以为pthread_create是瞬间召唤一个工人？真相是：用户空间和内核之间要先讨价还价。

单线程时代：一个工人的 determinism

打开网易新闻 查看精彩图片

想象一间安静的作坊。进来一个人，叫主线程。他有一本笔记本（栈）、一双手（寄存器）、一条固定的路（指令指针）。

他逐行读取程序文本区的指令。一切平静、确定、线性。没有意外，没有争抢。

这是 C 程序最原始的形态。简单到近乎无聊，却也可靠到让人心安。

工作量爆了：经理要加人

需求不会放过任何人。任务堆积，一个工人干不完。

作坊经理开口："我们需要更多工人。"

于是你写下pthread_create(...)。看起来只是一行代码，背后却触发了一整套协作流程。

线程诞生前：库函数先动手

在惊动内核之前，libc/线程库（用户空间的库）要先完成一系列准备。这不是系统调用，是用户态的铺垫工作。

栈空间分配、线程本地存储初始化、调度属性设置——这些脏活累活，库函数默默做完。

只有万事俱备，才会向内核发出真正的请求。内核点头，线程才获得执行实体。

所以pthread_create的耗时，从来不只是"创建"的耗时。它是用户态准备 + 内核态授权的双重账单。

为什么这很重要

很多性能优化栽在这里：以为线程创建很快，疯狂create，结果用户态开销吃掉预期收益。

线程池的存在意义，正是把这场"谈判"的成本摊薄到多次任务中。

理解这行代码的分层逻辑，才能写出真正高效的并发代码——而不是在用户态和内核态的边界上盲目试错。