直接用goroutine做矩阵乘法容易出错，因其不保证执行顺序、无内置分片逻辑，易致内存耗尽和调度开销过大，且未同步时会引发resulti的数据竞争。
为什么直接用 goroutine 做矩阵乘法容易出错
因为 goroutine 本身不保证执行顺序，也不自带任务分片逻辑——如果直接为每行或每元素起一个 goroutine，会快速耗尽内存（尤其大矩阵），且调度开销远超计算收益。更关键的是，没做同步控制时，result[i][j] 可能被多个 goroutine 同时写入，引发数据竞争。
- 别用
go func() { ... }()包裹单个元素计算，除非矩阵极小（ - 避免在循环内无节制启动 goroutine，要用固定数量的工作器（worker pool）
- 必须用
sync.WaitGroup或chan struct{}等待全部 worker 完成，不能靠 sleep 猜时间
如何设计一个可控的 worker 函数抽象
核心是把“计算某一块子矩阵”封装成可复用、可调度的单元，而不是让 worker 直接操作整个 A 和 B。典型做法是让每个 worker 接收一个任务结构体，包含行范围、列偏移等上下文信息，而非原始切片指针。
示例任务定义：
type MatMulTask struct {
startRow, endRow int
A, B [][]float64
result [][]float64
}
对应 worker 函数：
func worker(tasks
- worker 不持有全局状态，只处理传入的
task，便于测试和复用 - 任务 channel 类型为
，done channel 为 <code>chan，明确职责边界 - 不要在 worker 内部重新分配
result，它必须由主协程预先分配好并传入
怎么划分任务才能真正压满多核又不浪费
按行划分最简单，但可能负载不均（比如某些行涉及稀疏计算）。实际中推荐按“块”（tile）划分：把结果矩阵切成若干矩形块，每个 worker 负责一块。这样 cache 局部性更好，也更容易适配不同 CPU 核数。
- 设 CPU 核数为
runtime.NumCPU()，任务数建议设为该值的 1–2 倍，避免过度调度 - 块大小取 32×32 或 64×64（需实测），太小导致调度开销大，太大则无法充分利用空闲核
- 用整除+余数方式均匀分块，别用浮点除法再四舍五入，会导致最后一块越界
- 注意边界检查：
min(i+blockSize, len(result))比i+blockSize更安全
常见 panic 和竞态问题怎么快速定位
最常触发的是 panic: runtime error: index out of range，基本都源于任务划分时没校验 B 列数或 A 行数；而 data race 通常来自两个 worker 写了同一行同一列——哪怕你用了块划分，若块边界算错，仍会重叠。
- 运行时加
-race参数：go run -race main.go，它会报出具体哪两行 goroutine 冲突 - 用
len(A)、len(A[0])、len(B)、len(B[0])四个值做前置校验，缺一不可 - 别依赖
defer wg.Done()在 worker 入口，要放在实际计算完成之后，否则可能提前结束等待 - 如果用
sync.Mutex保护result，性能会暴跌——正确做法是确保每个 worker 写的内存区域完全不重叠
实际跑起来后，你会发现：当矩阵超过 2000×2000，worker 数设为 runtime.NumCPU() * 1.5、块大小 48×48 时，加速比最稳。再往上堆 goroutine 数量，反而因调度和 cache 冲突变慢。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
