Go 语言采用 goroutine + channel 的用户态并发模型，由 runtime 自主调度、绕过内核，初始栈仅 2KB，支持十万级并发；G-P-M 模型管理调度，channel 优先于锁实现 CSP，GOMAXPROCS 控制并行度。

Go 语言没有传统意义上的“多线程编程”，它用 goroutine + channel 构建的是用户态并发模型，不是对 OS 线程的封装或抽象——这是最根本的区别。

goroutine 不是线程，更不是“轻量级线程”这种模糊说法

很多人说“goroutine 是轻量级线程”，容易误导。它既不映射到 1:1 的 OS 线程，也不共享线程的调度语义。真正的区别在于：

• goroutine 由 Go runtime 自主调度，完全绕过内核；OS 线程（如 pthread）由内核调度，每次切换都要陷入内核
• 一个 goroutine 初始栈仅 2KB，可动态伸缩；而典型 Java 线程栈默认 1MB，C++/Python 线程也常在几百 KB 级别
• 创建 10 万个 goroutine 很常见，内存开销约 200MB；同等数量的 OS 线程在大多数系统上会直接 OOM 或被内核拒绝
• Go 运行时通过 G-P-M 模型管理：G（goroutine）、P（逻辑处理器，数量由 GOMAXPROCS 控制）、M（OS 线程）。M 数量可远超 P，比如阻塞系统调用时自动启用新 M，但你完全不用管

channel 通信 vs 共享内存：不是“能不能”，而是“该不该”

你在 Java/C++ 里写多线程，第一反应是加 synchronized 或 mutex；但在 Go 里，第一反应应该是“这个数据要不要走 channel？”

• 共享内存（如全局变量 + sync.Mutex）在 Go 中合法，但属于“降级用法”——它绕过了 CSP 模型的设计哲学，容易写出难以推理的竞态
• channel 默认是同步的（无缓冲），发送和接收必须配对阻塞，天然防漏、防重、防乱序；而锁机制需要你手动保证临界区边界、加锁顺序、释放时机
• 缓冲 channel（如 make(chan int, 10)）适合解耦生产/消费节奏，但别滥用：缓冲区大小不是性能调优参数，而是业务语义约束（例如“最多积压 5 个待处理请求”）
• 错误示例：for range 遍历未关闭的 channel 会死锁；正确做法是发送方 close(ch) 后接收方才安全退出

并发 ≠ 并行：GOMAXPROCS 决定物理并行能力

即使你写了 1000 个 goroutine，它们是否真能“同时跑”，取决于 GOMAXPROCS 设置——它控制的是 P 的数量，即能并行执行的逻辑处理器上限。

Facet

Facet.ai是一款AI图像生成和编辑工具，具备实时图像生成和编辑功能

下载

立即学习“go语言免费学习笔记（深入）”；

• 默认值是机器 CPU 核心数（runtime.NumCPU()），但可以显式设置：runtime.GOMAXPROCS(2)
• 设为 1：所有 goroutine 在单个逻辑处理器上协作式调度 → 只有并发，没有并行（适合 I/O 密集+强顺序依赖场景）
• 设为 >1：多个 P 可绑定不同 OS 线程（M），真正利用多核 → 实现并行（计算密集型任务必须开多 P）
• 注意：修改 GOMAXPROCS 不影响已启动的 goroutine 调度行为，只影响后续新建的调度上下文分配

package main
import (
"fmt"
"runtime"
"time"
)
func main() {
fmt.Println("GOMAXPROCS before:", runtime.GOMAXPROCS(0)) // 查看当前值
runtime.GOMAXPROCS(1)
fmt.Println("GOMAXPROCS after:", runtime.GOMAXPROCS(0))
go func() {
    for i := 0; i < 3; i++ {
        fmt.Printf("goroutine running on P=%d/n", runtime.NumGoroutine())
        time.Sleep(time.Millisecond * 100)
    }
}()

time.Sleep(time.Second)
}
真正难的不是写 go f() 或 ch ，而是判断哪些状态必须隔离、哪些通信必须同步、哪些地方其实该用 sync.Once 或 atomic 替代 channel —— 这些边界，文档不讲，报错不管，全靠对模型的理解沉淀下来。
https://www.php.cn/faq/2019592.html