P的状态转换由Go runtime调度器自动触发，不可控且不对外暴露；常见于系统调用（_Prunning↔_Psyscall）、GC停顿（→_Pgcstop）及M释放P（→_Pidle）三类场景。
P 的状态转换不是用户可控的，它完全由 runtime 调度器在 G 执行系统调用、GC 停顿或调度切换时自动触发。你无法手动调用 entersyscall 或 exitsyscall，也不能通过 API 查询某个 P 当前是 _Pidle 还是 _Prunning——这些状态只在 runtime/runtime2.go 中作为内部标记存在，且不对外暴露。
什么时候会触发 P 的状态变更
状态切换发生在极短的上下文临界点，常见于以下三类场景：
- 当一个正在运行的 goroutine 发起阻塞式系统调用（如
read、accept），P 会从_Prunning切换到_Psyscall；调用返回后，再切回_Prunning - GC 开始 STW 阶段时，所有正在工作的 P 会被强制设为
_Pgcstop，暂停调度；STW 结束后恢复为_Prunning或_Pidle - 当 M 释放 P（比如因系统调用休眠）而没有其他 M 立即抢占时，该 P 会变为
_Pidle；一旦有空闲 M 绑定上来，就回到_Prunning
entersyscall 和 exitsyscall 干了什么
这两个函数是 P 状态切换的核心入口，但它们不是“普通函数”——它们被汇编直接调用，且带有 //go:nosplit 标记，禁止栈分裂，确保执行路径绝对轻量。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
-
entersyscall：保存当前 G 的寄存器上下文，将 P 状态改为_Psyscall，并解绑当前 M 与 P；M 进入阻塞等待，P 可被其他 M 抢占 -
exitsyscall：尝试重新绑定原 M 与 P；若失败（P 已被其他 M 占用），则把当前 G 推入全局队列runtime.runq，自己进入休眠；成功则恢复 P 为_Prunning，继续调度 - 注意：
entersyscallblock是更激进的版本，用于已知会长时间阻塞的调用（如time.Sleep底层），它会直接让出 P，不尝试快速重绑定
为什么看不到 P 的状态？
Go 不提供任何公开接口读取或监听 P 状态，原因很实际：
- P 状态变化频率极高，一次 HTTP 请求可能经历多次
_Prunning → _Psyscall → _Prunning循环，轮询毫无意义 - 状态本身不承载业务语义，
_Psyscall并不等于“慢”，只是表示“当前 P 正在等一个系统调用返回” - 调试时若真需观察，只能通过
runtime.ReadMemStats+GODEBUG=schedtrace=1000输出调度器 trace，其中每行开头的P后数字即为当时活跃 P 数，间接反映状态分布
真正需要关注的不是 P 的状态值，而是它背后的行为含义：P 在 _Psyscall 时不会调度新 G，若大量 P 卡在这，说明系统调用密集或阻塞严重；P 长期处于 _Pidle 则可能意味着 G 不够、GOMAXPROCS 设置过小，或所有 G 都在 channel 上等待。
