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 的数量，即能并行执行的逻辑处理器上限。
立即学习“go语言免费学习笔记（深入）”；
- 默认值是机器 CPU 核心数（
runtime.NumCPU()），但可以显式设置：runtime.GOMAXPROCS(2) - 设为 1：所有
goroutine在单个逻辑处理器上协作式调度 → 只有并发，没有并行（适合 I/O 密集+强顺序依赖场景） - 设为 >1：多个
P可绑定不同 OS 线程（M），真正利用多核 → 实现并行（计算密集型任务必须开多 P） - 注意：修改
GOMAXPROCS不影响已启动的 goroutine 调度行为，只影响后续新建的调度上下文分配
package mainimport ( "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 —— 这些边界，文档不讲，报错不管，全靠对模型的理解沉淀下来。
