Update 计算机操作系统 - 进程管理.md

补充 GOMAXPROCS 参考 cgroup 限额与虚拟线程阻塞时的补偿机制。

notes/计算机操作系统 - 进程管理.md

@@ -116,7 +116,7 @@ fork 调用一次、返回两次：父进程中返回子进程的 PID，子进
 
 Go 和 Java 虚拟线程把大量协程映射到运行时创建的少量线程（通常与 CPU 核数相当）上，称为 M:N 调度；Python 的 asyncio 则在一个线程的事件循环中轮流执行所有协程。大多数协程是协作式调度的，只在让出点切换，例如等待 I/O、等待锁、sleep；一个协程长时间计算而不让出，就会一直占住所在的线程。
 
-Go 的 GMP 模型是一个典型实现：G 是 goroutine，M 是系统线程，P 是执行 Go 代码需要的处理器，数量默认等于可用的 CPU 核数。每个 P 有自己的就绪队列，M 绑定一个 P 后从队列中取 G 执行，队列空了就从其它 P 的队列中偷取一半。Go 1.14 起运行时还会用信号打断长时间运行的 goroutine（异步抢占），避免没有函数调用的循环一直占住线程。
+Go 的 GMP 模型是一个典型实现：G 是 goroutine，M 是系统线程，P 是执行 Go 代码需要的处理器，数量默认等于可用的 CPU 核数（Go 1.25 起在 Linux 上还会参考 cgroup 的 CPU 限额）。每个 P 有自己的就绪队列，M 绑定一个 P 后从队列中取 G 执行，队列空了就从其它 P 的队列中偷取一半。Go 1.14 起运行时还会用信号打断长时间运行的 goroutine（异步抢占），避免没有函数调用的循环一直占住线程。
 
 与线程相比：
 
@@ -128,7 +128,7 @@ Go 的 GMP 模型是一个典型实现：G 是 goroutine，M 是系统线程，P
 
 Java 21 正式引入的虚拟线程（[JEP 444](https://openjdk.org/jeps/444)）就是 JVM 实现的协程：虚拟线程由 JVM 调度到少量的平台线程（称为载体线程，carrier thread）上运行，执行阻塞 I/O 时从平台线程上卸载，让平台线程去执行其它虚拟线程。调度器是一个工作窃取的 ForkJoinPool，平台线程数默认等于 CPU 核数，JDK 21 不按时间片抢占虚拟线程。
 
-虚拟线程卸载时，它的栈帧以栈块对象（stack chunk）的形式保存在堆中，等 I/O 就绪后再挂载到某个平台线程上继续执行，所以阻塞的虚拟线程只占用与调用深度相当的堆内存，不占用平台线程。虚拟线程的创建成本很低，不需要用线程池复用，需要限制并发数时使用信号量。在 JDK 21 中，虚拟线程在 synchronized 块内阻塞时无法卸载，会固定（pinning）在载体线程上，所以锁内有阻塞操作时改用 ReentrantLock（见 [Java 并发](Java%20并发.md#使用选择)）；JDK 24 起（[JEP 491](https://openjdk.org/jeps/491)）基本消除了这个限制。
+虚拟线程卸载时，它的栈帧以栈块对象（stack chunk）的形式保存在堆中，等 I/O 就绪后再挂载到某个平台线程上继续执行，所以阻塞的虚拟线程只占用与调用深度相当的堆内存，不占用平台线程。虚拟线程的创建成本很低，不需要用线程池复用，需要限制并发数时使用信号量。在 JDK 21 中，虚拟线程在 synchronized 块内阻塞时无法卸载，会固定（pinning）在载体线程上。读写文件、Object.wait() 同样会占住载体线程，但调度器会临时增加平台线程来补偿；pinning 没有补偿，载体线程被占满后其它虚拟线程都无法执行，所以锁内有阻塞操作时改用 ReentrantLock（见 [Java 并发](Java%20并发.md#使用选择)）；JDK 24 起（[JEP 491](https://openjdk.org/jeps/491)）基本消除了这个限制。
 
 <div align="center"> <img src="pics/virtual-thread-unmount.png" width="760px"/> </div><br>