日志聚合接口已经超时后台任务为什么还没结束日志查询接口已经返回超时为什么后台 goroutine 还留在进程里代码里有 context也写了defer cancel()看起来请求结束时该做的清理都做了。可沿着任务往下看真正决定它能否退出的可能只是最后一条结果发送。目录1. 请求返回了后台任务却不一定结束2. 先看它在等什么不急着把总数叫作泄漏3. 把查询拿掉单独验证结果还能不能交出去4. 真正留下任务的是这一条普通发送5. 数量增长只是线索栈才把它连到发送行6. cancel 发出了通知为什么它没有醒来7. 把退出路径放到实际可能阻塞的地方8. 两个平台上的对照回答了多大的问题9. 缓冲、关闭通道和超时各自能解决什么10. 回到服务里怎样把这次修复收住11. 留下复现入口也留下问题的边界这一篇就围绕日志聚合来拆这个问题先分清请求在哪一步结束再找后台任务停在哪里最后用一个小程序验证取消到底能不能解除等待。业务背景用于说明排查路径文中的计数和堆栈来自本地验证。1. 请求返回了后台任务却不一定结束一次日志查询通常不只查一个地方。这里让 CK 提供日志明细MySQL 补充应用和服务信息Redis 提供近期统计或热点标签。三路数据用途不同可以并行获取再组合成一个响应。聚合函数为每一路查询启动 worker通过结果 channel 收集返回值同时设置一个总超时。正常情况下它收齐所需结果后返回如果某一路太慢就走超时分支让调用方及时得到响应。接下来容易被忽略的是聚合函数结束了慢的 worker 可能还在完成它自己的工作。稍后查询返回worker 继续向结果 channel 发送。此时负责接收的聚合函数已经离开这条结果还有谁接如果使用无缓冲 channel发送需要与接收配对。没有接收方又没有其他退出分支worker 就会停在发送上。接口从用户视角已经结束从后台任务视角却还没有走到 return。这种情况下单看请求结束日志很容易放心。但“请求返回”“下游查询结束”“后台任务退出”分别发生在不同位置把它们合成一条成功或超时记录就可能看不到剩下的等待。即使数据库调用响应了取消返回的是一个错误问题也不一定消失。如果 worker 仍要通过同一个 channel 把错误交回调用方它一样需要完成那次发送。排查不能只停在“查询有没有超时”还得继续看结果交付。2. 先看它在等什么不急着把总数叫作泄漏如果发现 goroutine 数在请求高峰后没有明显回落我会先确认观察窗口里的任务是否真的都应当结束。连接管理、定时刷新和固定 worker 本来就可能长期存在不能因为总数大就直接认定它们有问题。更有用的是比较多次 profile同一个业务函数下是否持续留下相同的等待栈停止增加这类请求以后它们有没有回落如果只是一批仍在执行的查询和已经没有推进者的发送后续处理方向完全不同。沿 worker 的路径我会分三段看取数据、交付结果、退出。栈如果停在数据库驱动或网络读取就继续检查调用的超时和取消传递栈如果停在业务代码的[chan send]就去找谁会接收这条结果。这一步也需要把创建位置一起看。相同的发送函数可能被多个请求入口调用只有知道谁创建了 worker、把结果交给了谁才能判断接收者是暂时没运行还是已经永久离开。仅凭一行“查询完成”还不能解释任务为什么没有结束。我也会区分本轮任务和后续重试创建的任务。一个请求超时之后如果上游很快再次请求而旧任务没有退出表面上就可能同时看到新增任务和旧残留。它们使用相似的函数名单看总数不容易分开需要结合请求归属和重复栈的位置判断。这里选择追踪的是接收方已经离开后的结果发送。把这个条件确认清楚才能避免修到不相关的地方调大查询超时可能只是让用户等得更久增加连接数也不会给结果 channel 凭空补出接收方。还有一种容易误导判断的日志位置worker 在查询返回时就打印“任务完成”然后才向通道发送结果。排查者看到这条日志会以为整个 worker 已经退出。其实它只说明取数据这一段结束了。更清楚的做法是区分查询返回、交付成功或放弃、函数退出这几个事件并在需要时用同一个请求标识关联起来。这样才能回答慢查询结束之后留下的究竟是仍在计算的任务还是已经无处交付的结果。日志不需要每一步都长期保留但在定位问题时它应当描述实际发生的动作。3. 把查询拿掉单独验证结果还能不能交出去为了验证发送这一段我没有先搭完整的 CK、MySQL 和 Redis 服务而是把 worker 前面的查询替换成一个可以控制的 gate。gate 打开后worker 进入发送路径调用方不再接收结果只负责发出取消并观察任务是否退出。这个简化保留的是等待关系结果已经准备交付使用者却不在了。它不验证数据库驱动怎样中断查询也不测完整 HTTP 请求的超时行为。先把一条可疑路径弄清楚回到服务时再把其余阻塞点逐段接上。想先运行小程序可以使用条命令在 Lab 目录执行完整驱动入口放在文末。go run ./src-modebad -profile-dir .work/manual-bad go run ./src-modegood -profile-dir .work/manual-good本地程序分五波每波启动 50 个 worker。同一波共用一个无缓冲结果 channel而且从一开始就不安排接收方。这比真实请求更刻意它直接固定了“没有人再取结果”让观察不依赖某次网络查询恰好超时。驱动等到所有 worker 都走向发送路径后再调用 cancel。发送前的标记只说明到达了相关代码不能单独证明已经挂起所以最后仍要检查真正的阻塞栈。这样的控制是为了排除时序上的歧义不是要模拟线上故障发生的频率。4. 真正留下任务的是这一条普通发送下面是 bad.go 中的 worker。前面的通道用来控制本地验证的执行顺序最后一行才是需要关注的业务等待funcbadWorker(outchan-int,gate-chanstruct{},ready,attemptedchan-struct{}){ready-struct{}{}-gate attempted-struct{}{}out-1}out无缓冲也没有接收者。这个函数没有接收 context普通的out - 1自然也不知道调用方发出了取消通知。它等的是结果 channel 上的配对操作而取消发生在另一条通知路径上。放回日志查询这一行可能是resultCh - queryResult。即使计算已经结束发送也是任务生命周期的一部分。把查询耗时记录完整、把结果构造出来都不能替这一步完成交接。这一点容易被函数调用的表象掩盖。外层创建 context内层某个数据库调用也接收了它看起来整条链路都支持取消。但是否能退出仍要逐个检查内部的等待。一个函数接收 context不代表它里面所有 channel 操作都自动观察 context。如果调用方在另一条 goroutine 中等待结果而 worker 的发送又没有任何超时或取消分支那么调用方提前离开的分支就必须有专门安排。正常路径一直有人接收只能说明正常路径能够推进不能替这个分支作保证。5. 数量增长只是线索栈才把它连到发送行本地一次原生运行里启动时只有 1 个 goroutine五波以后依次看到 51、101、151、201、251。每次增加 50正好对应一波 worker。更关键的是特定badWorker [chan send]栈也按同样数量增加。观察位置goroutine 总数停在该 worker 发送上的数量启动10第一波结束后5150第三波结束后151150第五波结束后251250手工 GC 后251250下面是同一次运行保存的原始堆栈片段goroutine 20 [chan send]: main.badWorker(...) engineering-lab/001-go-goroutine-leak/src/bad.go:8 main.run.func1() engineering-lab/001-go-goroutine-leak/src/main.go:83 0xc5 created by main.run in goroutine 1 engineering-lab/001-go-goroutine-leak/src/main.go:80 0x593总数、函数位置和等待状态指向同一条路径这比仅仅看到曲线向上更有说服力。停止新增 worker 以后代码里没有再出现接收方等待也不会因为流量下降自行得到满足。这里也特意在 GC 后再观察一次。如果只是把尚未完成的调度当作残留需要给任务退出的机会如果期待 GC 终止后台任务就会在这里看见假设不成立。这次 250 个 worker 在手工 GC 后仍然停在发送上。这份结果没有给出每个 worker 占用多少内存也没有测 RSS 随流量怎样变化。栈上的引用可能影响对象存活但具体代价还需要相应测量。排查时先确认等待关系再讨论容量避免从一个数量直接猜出一组资源开销。6. cancel 发出了通知为什么它没有醒来普通发送不会因为相关请求被取消就自动改为观察ctx.Done()。要让两者发生联系worker 需要在可能阻塞的位置明确选择结果能够交付就发送取消已经到来就放弃这次交付并退出。CancelFunc的职责是发出取消通知它本身也不等待工作停止。这个 API 边界在排查时很重要调用 cancel 返回只能说明取消动作已经被发起不能把它当作所有子任务的完成回执。context 文档顺着固定版本的实现看阻塞发送会把等待节点放入c.sendq再由gopark挂起当前 goroutine。这个发送路径没有读取业务 context。Go 1.25.4 runtime/chan.go 能帮助解释为什么栈里的等待不会仅因另外一条 Done 通道关闭就结束。GC 同样不会替任务执行 return。一个仍在等待的 goroutine需要有能让它继续运行并退出的协议把结果引用留在栈上也可能延长相关对象的存活。Go 官方的 Pipelines and cancellation讨论了接收方提前停止消费的同类问题。所以这类代码里至少有三个需要分清的动作通知取消、任务响应取消、创建者确认任务结束。只写好了第一个动作后面两步仍然可能缺失。它们不一定需要三个不同的工具但责任需要明确。7. 把退出路径放到实际可能阻塞的地方对这个小程序我保留相同数量的 worker给 gate 等待和结果发送都加上取消分支。good.go 的代码是funcgoodWorker(ctx context.Context,outchan-int,gate-chanstruct{},ready,attemptedchan-struct{}){ready-struct{}{}select{case-gate:case-ctx.Done():return}attempted-struct{}{}select{caseout-1:case-ctx.Done():return}}其中真正对应结果交付的是第二个 select。如果没有人接收out取消分支仍然能推进让 worker 返回。调用方再通过 WaitGroup 等待所有 worker 完成随后采样就能把“通知已经发出”和“任务已经退出”分开确认。ready、attempted的容量等于 worker 数每个 worker 只发送一次属于数量受控的实验同步标记。不要把它们当作生产环境里任意通道都不会阻塞的例子。真实代码中每一个等待位置都仍然要单独检查。select 还有一个常被误解的地方它没有取消优先级。如果发送与取消都可以执行可能选择发送。本地验证里因为没有接收者发送分支无法进行才由取消路径退出不能把这份结果读成“取消后绝不交付任何结果”。语言规范给出了相应选择规则。对于日志查询调用方已经离开后放弃这份只读查询结果通常可以作为一种明确的设计选择。但如果 worker 执行的是需要提交的业务副作用就还要定义取消与提交之间的边界。不能把“任务数回落”直接等同于所有业务要求都满足。取消分支里的处理也应该尽量直接。如果为了记录“已经放弃结果”又向另一个无人接收的错误通道发送消息就可能把等待搬到清理代码里。退出路径上仍要检查是否存在阻塞以及负责接收或释放资源的那一方是否还活着。修复时真正需要补齐的是一条能走到函数返回的路径不能只在原发送位置多写一个分支就停止检查。8. 两个平台上的对照回答了多大的问题修复后本地五个波次以及 GC 后的 goroutine 总数都回到启动时的 1相关 worker 阻塞栈为 0。Windows 原生与 Linux 容器中原实现和修复实现分别运行十个独立进程观察到的残留数量一致。图中每个点来自同组十次运行这些计数恰好完全重合。五个波次表示同一进程里的增长过程不能把它们当成五次独立样本GC 后的观察也单独保留。原始 Windows 清单本地归档、Linux 清单本地归档和图表数据可以继续核对。这个对照支持的是一个具体判断当结果通道无人接收时在发送位置监听取消并返回消除了当前负载里的 worker 残留。它没有验证所有数据库驱动的取消能力也没有覆盖完整日志服务的全部执行路径。真实 worker 是否也经过了同样的发送位置所有提前返回的分支是否都能发出取消有没有另一处在构造结果之前就已经卡住的 I/O小程序把可疑机制说明白真实调用链仍需要逐段对应。9. 缓冲、关闭通道和超时各自能解决什么最容易想到的另一个改法是加缓冲。对于只有一个发送者、恰好回传一个结果的独立通道一格缓冲可以让发送先完成再让 worker 返回。但本地一波有 50 个发送者一格只能接住其中一个结果剩下的仍可能等待。即使把缓冲扩大到容纳所有结果也要说明发送次数确实有上界。任务重试、进度通知、错误回报都可能增加发送次数。如果协议持续产生数据消费者离开后再大的固定缓冲也有被写满的一天。缓冲是容量选择取消与结束仍然需要安排。另一种容易出错的处理是接收方返回时直接关闭结果 channel。向关闭的通道发送会 panic关闭不会把尚未交付的结果安全地撤销。谁负责关闭应该由发送者数量和完成顺序决定在确认不会再有发送后协调执行。官方 pipeline 示例可以对照这一点。延长超时也需要看目标。如果任务本来有合理的完成时间调整预算可能有意义但在接收方已经离开的这条路径上多等一会儿并不会改变最终无人接收的事实。可以改善触发条件的措施不能代替缺失的退出分支。10. 回到服务里怎样把这次修复收住我会先沿一个请求检查三条路径正常收齐结果、调用方超时离开、后台先失败。每条路径都追问任务由谁创建结果交给谁哪些分支可以放弃最后由谁确认完成。这样才能看见正常调用时被掩盖的责任缺口。再把完成信息和请求日志对应起来。请求结束的位置说明对外响应已经完成worker 的退出位置才说明后台工作已经交还。如果只记录进入查询和接口返回中间的结果发送就容易成为没有观测的空白。修复后的检查也应该回到原来会触发问题的条件。相同请求形态下等待位置是否消失相关任务是否能结束必要结果是否仍能交付都比单独看总数下降更有用。数量下降可能只是创建得更少甚至是少执行了工作需要与业务结果一起看。同时留意有意长期运行的后台任务。请求级 worker 适合随请求结束而收拢定时刷新或队列消费者可能由服务级作用域管理。把不同生命周期的任务都绑到一个请求 context 上也可能造成另外的错误。先明确归属再选择取消来源。如果为了让某项工作在请求结束后继续选择了独立作用域就要给它新的所有者、资源预算和完成去向。简单换成不会取消的 context只会让请求退出与任务退出彻底分离不会自动建立后台工作的管理方式。11. 留下复现入口也留下问题的边界这个小程序没有完整业务依赖适合用来反复检查发送与取消的关系。源码和运行说明在 Lab 001。回查实现时始终把它与真实服务中对应的发送位置对齐。公开代码实验目录 · 运行入口。固定提交c3d8b36a。原始日志和协议等本地归档没有上传 GitHub。两套环境都使用 Go 1.25.4。原生为 Windows/amd64容器为 Linux/amd64容器镜像为固定 digest 的 golang bookworm限制 2 CPU、512 MiB禁网络。每个模式十个独立进程五波各五十个 worker。又使用固定提交的公开代码完成一轮复跑保存 40 条核验记录。下图是实际报告页面的真实浏览器截图命令、退出码和清单来源在执行记录与报告页面中保存。报告中的通过表示相应预期现象得到验证。原实现出现残留是被观察到的问题不表示它已经正常退出。正文历史图和这次复跑的 PID、时间等数值分别保留不要求逐项相同。文本栈由 debug2 输出二进制 profile 可供工具继续分析。pprof 文档
