北京
你以为pthread_create是瞬间召唤一个工人？真相是：用户空间和内核之间要先讨价还价。
单线程时代：一个工人的 determinism
想象一间安静的作坊。进来一个人，叫主线程。他有一本笔记本（栈）、一双手（寄存器）、一条固定的路（指令指针）。
他逐行读取程序文本区的指令。一切平静、确定、线性。没有意外，没有争抢。
这是 C 程序最原始的形态。简单到近乎无聊，却也可靠到让人心安。
工作量爆了：经理要加人
需求不会放过任何人。任务堆积，一个工人干不完。
作坊经理开口："我们需要更多工人。"
于是你写下pthread_create(...)。看起来只是一行代码，背后却触发了一整套协作流程。
线程诞生前：库函数先动手
在惊动内核之前，libc/线程库（用户空间的库）要先完成一系列准备。这不是系统调用，是用户态的铺垫工作。
栈空间分配、线程本地存储初始化、调度属性设置——这些脏活累活，库函数默默做完。
只有万事俱备，才会向内核发出真正的请求。内核点头，线程才获得执行实体。
所以pthread_create的耗时，从来不只是"创建"的耗时。它是用户态准备 + 内核态授权的双重账单。
为什么这很重要
很多性能优化栽在这里：以为线程创建很快，疯狂create，结果用户态开销吃掉预期收益。
线程池的存在意义，正是把这场"谈判"的成本摊薄到多次任务中。
理解这行代码的分层逻辑，才能写出真正高效的并发代码——而不是在用户态和内核态的边界上盲目试错。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
