在 CentOS 上跑 Golang 并发程序，很多人上来就写一堆 goroutine，结果跑着跑着内存爆了，或者 CPU 利用率上不去。其实这事儿没那么玄乎，核心就几个关键点：合理利用系统资源、控制并发粒度、避免锁竞争。下面结合实战经验，把几个最有效的优化方向拆开讲讲。
1. 合理设置 GOMAXPROCS
GOMAXPROCS 控制的是 Go 程序能同时利用多少个操作系统线程去执行用户级 goroutine。默认值就是机器 CPU 核心数，但有时候并不一定是最优的——比如在容器化环境里，宿主机核心数可能被限制，或者程序本身有大量 I/O 等待，这时候手动调一下反而更好。建议在 init() 里显式设置：
import "runtime"func init() {runtime.GOMAXPROCS(runtime.NumCPU())}也可以在程序启动前通过环境变量指定：
export GOMAXPROCS=8经验值：CPU 密集型任务可以设为核心数，I/O 密集型可以适当放大到核心数的 1.5~2 倍。
2. 用 goroutine 池控制并发数量
goroutine 虽然轻量，但也不是无限制的。一个 goroutine 初始栈只有 2KB，但跑起来可能膨胀到几 MB。如果突然创建几十万个 goroutine，内存压力瞬间飙升，GC 也会跟着遭殃。更务实的做法是用 worker pool 模式，限制同时活跃的 goroutine 数量。
package mainimport ("sync")type Job struct {// 任务相关字段}type WorkerPool struct {jobs chan Jobwg sync.WaitGroup}func NewWorkerPool(size int) *WorkerPool {wp := &WorkerPool{jobs: make(chan Job, size),}for i := 0; i < size; i++ {go wp.worker()}return wp}func (wp *WorkerPool) worker() {for job := range wp.jobs {// 处理任务job.Process()wp.wg.Done()}}func (wp *WorkerPool) Submit(job Job) {wp.wg.Add(1)wp.jobs <- job}func (wp *WorkerPool) Shutdown() {close(wp.jobs)wp.wg.Wait()}池的大小取决于任务类型和系统资源，一般可以先压测找到拐点。
3. 避免全局锁，尽量用局部锁或无锁结构
全局锁 (sync.Mutex) 是并发性能的头号杀手。一旦多个 goroutine 频繁争抢同一把锁，程序大概率会退化成串行执行。更优的做法是缩小锁的粒度，比如只锁需要保护的临界区，或者干脆用无锁数据结构（如 CAS 操作）。
import "sync"var mu sync.Mutexvar data map[string]intfunc updateData(key string, value int) {mu.Lock()defer mu.Unlock()data[key] = value}如果 map 的并发读写非常频繁，可以考虑用 sync.Map 替代，它内部做了分段锁优化，读多写少场景下效果显著。
4. 读多写少场景用 sync.Map
Go 标准库自带的 sync.Map 专门为这种场景设计，内部通过读写分离和原子操作来减少锁竞争。对比普通 map + 大锁，性能提升可能不止一个数量级。
import "sync"var m sync.Mapfunc store(key, value interface{}) {m.Store(key, value)}func load(key interface{}) (interface{}, bool) {return m.Load(key)}不过要注意：sync.Map 不适合写密集的场景，因为写操作会触发较重的锁升级。
5. 优化 I/O 操作：异步 + 缓冲
I/O 往往是并发程序的瓶颈，尤其是磁盘读写。用 bufio 包做缓冲读取，能显著减少系统调用次数。同时，可以考虑把 I/O 操作放到单独的 goroutine 里，用 channel 把数据吐给处理协程，实现异步流水线。
import ("bufio""os")func readFileAsync(filename string) {file, err := os.Open(filename)if err != nil {log.Fatal(err)}defer file.Close()scanner := bufio.NewScanner(file)for scanner.Scan() {// 处理每一行}}如果文件很大，还可以配合内存映射（mmap）来加速。
6. 用 context 做超时和取消控制
goroutine 的生命周期管理是并发编程的难点。用 context.WithTimeout 或 context.WithCancel 可以安全地终止长时间运行的任务，避免资源泄漏。
import ("context""time")func doSomething(ctx context.Context) {select {case <-ctx.Done():// 处理超时或取消case <-time.After(5 * time.Second):// 任务完成}}func main() {ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)defer cancel()go doSomething(ctx)// 等待任务完成或超时<-ctx.Done()}这里有个细节：ctx.Done() 返回的 channel 在超时或取消时会关闭，所有 select 到它的 goroutine 都能干净退出。
7. 用 pprof 定位瓶颈
优化没有银弹，只有数据才能告诉你该往哪个方向使劲。Go 自带的 pprof 工具可以实时抓取 goroutine 堆栈、CPU 热点、内存分配等信息。在 CentOS 上启动 net/http/pprof 后，直接通过浏览器或命令行分析：
go tool pprof https://localhost:6060/debug/pprof/goroutine重点关注 goroutine 数量异常、锁等待时间过长的堆栈，以及频繁分配内存的热点函数。
8. 网络请求的连接池和复用
如果你的程序需要发起大量 HTTP 请求，每次新建连接的开销非常大。Go 的 net/http 包默认就支持连接池，但默认参数比较保守（MaxIdleConns 只有 100）。可以手动调整 Transport 配置来提升吞吐量：
import ("net/http""sync")var httpClient = &http.Client{Transport: &http.Transport{MaxIdleConns:100,IdleConnTimeout: 90 * time.Second,DisableCompression:true,},}func fetchData(url string) {resp, err := httpClient.Get(url)if err != nil {log.Fatal(err)}defer resp.Body.Close()// 处理响应}DisableCompression 设为 true 可以避免额外的 CPU 开销，前提是服务端不强制压缩数据。另外，如果请求的目标是同一台服务器，还可以考虑使用 HTTP/2 的多路复用。
以上这几个方向基本覆盖了 CentOS 上 Golang 并发优化的常见场景。实际落地时，建议先压测，再针对瓶颈做针对性调整，不要盲目套用所有技巧。
