-
我在 Go 的 for 循环里写 select 处理 channel、为了让它别卡住顺手加了个 default 分支,结果服务一启动某个 CPU 核心就直接飙到百分之百风扇狂转,我盯着那段逻辑明明没干什么重活百思不得其解最后才反应过来那个 default 让 select 永远不阻塞整个循环变成了疯狂空转的忙轮询的深度复盘
我有个后台 goroutine 在 for 循环里用 select 监听几个 channel(收任务、收停止信号),担心万一所有 channel 都没消息 select 会卡住、就给它加了个 default 分支,想着没消息时走 default 不卡住挺稳妥,功能也正常。可一上线就发现:服务明明很闲没什么任务、某个 CPU 核心却常年 100% 风扇狂转、整体性能还下降了。top 看是我的进程吃满…- 0
- 0
-
我的 Go 程序某个功能莫名其妙地卡住、既不报错也不返回,goroutine 越积越多最后内存涨爆,排查半天才发现是一个 channel 忘了 make 初始化、它是 nil,而往 nil channel 收发竟然不是报错、而是永久阻塞的深度复盘
我有段 Go 代码用 channel 在 goroutine 间传数据,在结构体里声明了一个 channel 字段,启动 goroutine 往里发另一边收,自测小场景跑通了。可某功能上线后行为诡异:它莫名卡住——既不报错也不返回也不超时,就静静挂着;随请求进来卡住的 goroutine 越积越多内存一路涨爆。我以为是死锁、下游慢,查半天没问题。直到打 goroutine 栈,发现一大堆都阻塞在那…- 0
- 0
-
我用一个 channel 收集多个 worker 的结果,某个 worker 干完顺手把 channel 关了,其他还在干活的 worker 一发送就 panic:send on closed channel,一次 Go channel 关闭所有权的深度复盘
我用多个 worker goroutine 并发处理任务,每个 worker 把结果发到一个共享的 results channel,主 goroutine 收集。为了发完就通知结束,我让每个 worker 干完后 close(results)。功能偶尔能跑,可线上常崩 panic: send on closed channel。推演时序才明白:这个 channel 是多个 worker 共享发送的…- 0
- 0
-
一个每次请求都起一个 goroutine 却没人保证它能退出的服务,goroutine 越积越多、内存缓慢上涨,跑几天就 OOM:一次 goroutine 泄漏的深度复盘
服务内存缓慢上涨、跑几天就被 OOM,pprof 一看 goroutine 从几十个涨到几十万、只增不减,且全卡在同一行 channel 接收/发送上。根因是每请求起 goroutine 通过无缓冲 channel 返回结果,而主流程超时/取消后提前返回、不再接收,那个负责发送的 goroutine 就永远阻塞在 ch- 0
- 0
-
我的 Go 服务内存和 goroutine 数量只涨不跌、跑久了必 OOM,最后揪出是一堆 goroutine 永远卡在 channel 上、泄漏了出不来的深度复盘
我的 Go 服务有个怪病:跑得越久内存越高、只涨不跌,goroutine 数量也持续上爬,最终 OOM 崩溃。我一开始当普通内存泄漏找"哪个对象没释放",直到发现 goroutine 数量同步上涨才醒悟——是 goroutine 泄漏:有段代码启动 goroutine 把结果通过无缓冲 channel 发回,主流程却会因超时提前返回、不再接收,那个 goroutine 就永久卡…- 0
- 0
-
服务跑了几天,goroutine 数量涨到了几十万,内存也跟着爆了:我写的 goroutine 悄悄地泄漏了的那次排查复盘
Go 服务跑几天就内存越涨越高、最后崩溃,重启又能撑几天。pprof 一查,活跃 goroutine 竟有几十万个,绝大多数都卡在同一行 channel 发送上。根因是 goroutine 泄漏:我为每个查询起一个 goroutine 往无缓冲 channel 发结果,但主函数只接收一次拿最快的就 return 了,其余 goroutine 因为没人接收、永远阻塞在发送上、退不出去。这篇从 gor…- 0
- 0
-
内存慢性漏气定期 OOM:Go 协程泄漏避坑复盘
这是一个让我和运维被半夜告警折磨了快一周的事故:一个 Go 写的后端服务上线后一切正常,可跑上两三天内存就会悄悄爬到上限,然后被 OOM 杀掉自动重启,重启后归零又开始新一轮缓慢爬升,周而复始。它不是一上线就崩的急性病,而是跑着跑着就虚了的慢性病,每隔两三天准时 OOM 一次,最折磨人的是 QPS 没涨流量很平稳,内存却像漏气的轮胎只进不出。真正破案靠的是 Go 自带的神器 pprof:把 gor…- 0
- 0
-
内存只涨不降、几万协程卡死:Go goroutine 泄漏避坑
有个 Go 后台服务跑了几周后运维找上门:进程内存像吹气球一样一天涨一点、从不回落,最后逼近上限被 OOM 杀掉,重启再涨周而复始。我先按内存泄漏的老套路查对象没揪出元凶,直到顺手看了眼 runtime.NumGoroutine 返回的协程数量当场倒吸一口凉气:这个数字也在只涨不降,从启动时几十个涨到几万个还在稳步往上爬。真相浮出水面——不是对象泄漏,是 goroutine 泄漏:每处理一个请求代…- 3
- 0
-
Go 并发踩坑实录:一个共享 map 如何让整个服务瞬间崩溃
这次事故没有任何前兆:一个跑了大半年、从没出过岔子的 Go 服务,突然整个进程没了。登上机器翻日志,最后一行让我后背一凉——fatal error: concurrent map writes。不是 panic,是 fatal error,recover 写再多都拦不住一个字。根因朴素得讽刺:一个做本地缓存的普通 map,被好几个 goroutine 同时读写,平时并发不高一直没事,流量一冲高,两…- 2
- 0
-
Go goroutine 泄漏的 5 个真实场景:11 万协程 OOM 复盘 + 检测方案
一个 Go 微服务每天涨 200MB,heap profile 一切正常,goroutine profile 却显示 11 万个活跃协程,绝大多数卡在 chan receive 上等一个永远不会写入的 channel。本文整理了生产中最常见的 5 种 goroutine 泄漏场景,每种给出最小复现 + 修法,并给出 pprof + goleak 的 CI 检测方案。- 0
- 0
-
Go 并发编程完全指南:goroutine、channel 与 select 的正确打开方式
Go 的并发模型常被一句话概括:"不要通过共享内存来通信,而要通过通信来共享内存。"这句话很漂亮,但新手听完往往还是不会用。这篇文章不停留在口号,而是把 goroutine、channel、select 三件套讲透 —— 它们各自解决什么问题,怎么配合,以及最容易踩的几个坑。 goroutine:几乎免费的并发单元 goroutine 是 Go 运行时管理的轻量级线程。它&qu…- 0
- 0
channel
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×