Go 协程池满了怎么办？面试官问我“兜底策略”，我差点挂了……

昨天有个兄弟跟我吐槽，说他去面字节，被面试官问懵了。

面试官先问："Go 的协程（Goroutine）那么轻量，为什么还需要协程池？"

这兄弟答得挺好："虽然 Goroutine 初始栈只有 2KB，但如果无限制地 go func()，在高并发下几百万个协程同时跑，内存照样会爆（OOM），而且调度开销也会拖垮 CPU。所以需要协程池（Worker Pool）来限制并发数。"

面试官点点头，接着抛出了杀手锏：

"那如果你的协程池满了（Channel 塞满了），新来的任务怎么办？"

这兄弟心里一慌，支支吾吾说了个"阻塞等待"，结果面试官继续追问："一直阻塞会导致上游请求超时，有没有别的办法？"他又说了"直接丢弃"，面试官眉头一皱："丢数据你负责？"

最后这兄弟挂在了这个问题上。

其实，这道题考察的是你对高并发降级的理解。今天咱们就来拆解一下，Go 协程池满了之后的几种经典应对姿势，以及面试官最想听的"兜底大招"。

常见的 3 种"常规操作"及其隐患

在 Go 语言里，无论是手写的 chan 缓冲队列，还是用第三方库（比如 ants），面对"池子满"的情况，通常有这么几种处理方式：

1. 阻塞等待（Block）

这是最自然的反应。向一个满的 Channel 发送数据，默认就是阻塞。

go 复制代码

taskCh <- task // 如果 ch 满了，这里会卡住，直到有 worker 取走任务

生产风险 ：级联故障。如果消费端处理慢，生产端（比如处理 HTTP 请求的 Handler）就会全部卡死在这里。客户端会看到请求一直转圈圈，最后超时。这在微服务架构里是灾难性的。

2. 直接丢弃或返回错误（Non-blocking）

利用 select 的 default 分支，或者 ants 库的 WithNonblocking(true)。

go 复制代码

select {
case taskCh <- task:
    // 提交成功
default:
    // 满了，直接报错返回
    return errors.New("pool is full")
}

生产风险 ：数据丢失。如果是日志采集还好，丢了就丢了。但如果是"支付回调"或者"订单状态更新"，你直接把任务丢了，用户那边显示支付成功，你这边数据库没更新，这就要出生产事故了。

3. 调用者运行（Caller Runs）

借鉴 Java 线程池的思路：谁提交的任务，谁自己去跑。

go 复制代码

select {
case taskCh <- task:
default:
    // 既然池子满了，我自己跑
    task() 
}

生产风险 ：阻塞主流程 。如果 task() 执行得很慢（比如查数据库、调 RPC），那么原本负责接收请求的 HTTP Handler 就会被卡住去干苦力，导致吞吐量瞬间暴跌。

面试官想要的"第 4 种"：兜底策略（业务降级）

面试官问"怎么办"，其实是在问你：在不阻塞、不丢核心数据的前提下，如何削峰填谷？

这时候，你得祭出"持久化降级"这招。

核心思路

当协程池满时，我们不阻塞，不丢弃，也不自己跑，而是把任务**"暂存"**起来，等高峰期过了再慢慢处理。

具体方案

告警：首先，必须打点监控。协程池满说明系统负载过高，运维得知道。
转存 MQ：把任务序列化（Json/Protobuf），扔到 Kafka、RabbitMQ 的降级队列里。
转存 Redis/DB：如果没有 MQ，扔到 Redis List 或者 MySQL 的本地表中也可以。

代码实战（伪代码）

go 复制代码

// Submit 提交任务
func (p *Pool) Submit(task func()) {
    select {
    case p.taskQueue <- task:
        // 1. 正常提交到池子
        return
    default:
        // 2. 池子满了，触发兜底策略
        p.handleReject(task)
    }
}

func (p *Pool) handleReject(task func()) {
    // 3. 记录 ERROR 日志
    log.Errorf("Goroutine pool is full! Rejecting task.")

    // 4. 序列化任务（假设 task 包含了数据）
    payload, _ := json.Marshal(task.Args)

    // 5. 写入 Kafka 降级队列
    err := kafkaProducer.Send("topic-downgrade", payload)
    
    // 6. 如果 Kafka 也挂了...（极度倒霉）
    if err != nil {
        // 最后的倔强：写入本地磁盘文件，或者为了保命只能丢弃
    }
}

后续处理： 你还需要一个独立的 Consumer 服务，专门在后台慢慢消费这些降级队列里的任务，把它们重新喂给系统执行。

总结：面试怎么答？

下次再遇到"协程池满了怎么办"，你可以这样一套连招：

先分析利弊："直接阻塞会拖垮上游，直接丢弃会丢数据，CallerRuns 会阻塞主线程，都有风险。"
提出兜底方案："针对核心业务，我通常采用**'异步持久化'**的策略。"
展开细节 ："利用 select 检测满载情况，一旦满了，将任务降级写入 MQ 或 Redis，并通过监控报警。事后通过异步 Worker 补偿执行，既保证了系统高可用，又保证了数据最终一致性。"

这一波回答下来，面试官绝对会觉得你是个懂实战、有经验的老司机。

END

⚡️ 别把时间浪费在低效复习上

很多人复习抓不住重点。作为过来人，我分析了100+份大厂面试记录，将 Go/Java/AI 的核心考察点、高频题、易错点 浓缩进了一份 PDF。

不搞虚的，全是干货。

加我：wangzhongyang1993 ，备注 【面经】 免费发你，立即纠正你的复习方向，把时间用在刀刃上。

wangzhongyang.com 也欢迎大家直接访问我的官网，里面有Go / Java / AI 的资料，免费学习！