-
我在 Go 的 for-select 循环里用 time.After 做超时、自以为简洁标准,结果服务跑久了内存一路缓慢上涨、profile 一看堆里全是没释放的定时器,最后才搞懂 time.After 每次求值都新建一个定时器而它要等到到期那一刻才会被回收的深度复盘
我有个后台 goroutine 在 for 循环里用 select 处理一个高频消息 channel,同时想加一个多久没消息就做点别的的超时,很自然写成 case- 6
- 0
-
我用 ThreadLocal 存当前登录用户,本以为线程私有绝不会串,结果某个用户偶尔会看到另一个用户的数据,因为在线程池里线程是复用的、用完没清的 ThreadLocal 残留给了下一个请求的深度复盘
我用 ThreadLocal 存当前登录用户(请求进来时 set、后续各层从 ThreadLocal 取,避免层层传参),想当然以为 ThreadLocal 线程私有、每个请求一个线程各存各的绝不会串。结果线上出了最可怕的 bug:偶发地某个用户页面上显示出了另一个用户的数据(订单、隐私),用户身份串了、是严重越权。排查才定位到线程池:Web 服务器用线程池处理请求、线程是复用的(处理完一个请求会…- 0
- 0
-
我那些频繁创建又销毁的对象,订阅了一个单例的事件却忘了退订,结果它们一个都没被回收、内存一路涨到 OOM:一次 C# 事件订阅未取消导致内存泄漏的深度复盘
我有一类频繁创建又销毁的对象(随每个请求创建的 Handler),创建时订阅了一个长生命周期单例 EventBus 的事件:bus.DataChanged += this.OnDataChanged。功能没问题,可线上内存一路缓慢上涨、只涨不降,跑久了 OOM。内存 dump 才看明白:那些本该被回收的 Handler 一个都没被 GC,全被 EventBus 的委托链引用着。根因是它们订阅了单例…- 0
- 0
-
一个每次请求都起一个 goroutine 却没人保证它能退出的服务,goroutine 越积越多、内存缓慢上涨,跑几天就 OOM:一次 goroutine 泄漏的深度复盘
服务内存缓慢上涨、跑几天就被 OOM,pprof 一看 goroutine 从几十个涨到几十万、只增不减,且全卡在同一行 channel 接收/发送上。根因是每请求起 goroutine 通过无缓冲 channel 返回结果,而主流程超时/取消后提前返回、不再接收,那个负责发送的 goroutine 就永远阻塞在 ch- 0
- 0
-
我的服务运行越久内存涨得越凶,最后内存泄漏到崩溃,排查发现是一堆本该被回收的对象因为订阅了事件却没取消订阅、被发布者死死攥着无法回收,我对着 C# 事件订阅导致的内存泄漏这个坑排查大半天的复盘
一个让我对有了 GC 就不会内存泄漏这个错觉彻底清醒的 C# 坑,隐蔽在 C# 有垃圾回收我一直以为对象没用了 GC 自然会回收根本不用操心,可这次一堆本该被回收的对象却被一根我没注意到的引用线死死拴住、GC 怎么也回收不了。服务运行越久内存涨得越凶最后 OOM 崩溃。场景:短生命周期对象 TempHandler 订阅了长生命周期全局服务 GlobalService 的 DataChanged 事…- 2
- 0
-
页面明明都关了,程序内存却只升不降、最后被撑爆:我在 C# 里订阅了事件却忘了退订,埋下的那个悄无声息的内存泄漏的深度复盘
客户端程序的页面反复开关,内存却只升不降、最后撑爆。内存分析发现:那些"已关闭"的页面对象一个都没被 GC 回收!根因是页面在打开时订阅了长寿的"数据中心"单例的事件、关闭时却忘了退订——而订阅事件会让发布者持有对订阅者的引用,长寿的数据中心就一直拴着本该销毁的页面,导致它永远无法回收。这篇从事件订阅为何泄漏(发布者引用+GC规则+谁更长寿)讲到 -= 退订…- 0
- 0
-
内存慢性漏气定期 OOM:Go 协程泄漏避坑复盘
这是一个让我和运维被半夜告警折磨了快一周的事故:一个 Go 写的后端服务上线后一切正常,可跑上两三天内存就会悄悄爬到上限,然后被 OOM 杀掉自动重启,重启后归零又开始新一轮缓慢爬升,周而复始。它不是一上线就崩的急性病,而是跑着跑着就虚了的慢性病,每隔两三天准时 OOM 一次,最折磨人的是 QPS 没涨流量很平稳,内存却像漏气的轮胎只进不出。真正破案靠的是 Go 自带的神器 pprof:把 gor…- 0
- 0
-
事件订阅没退订:C# 内存缓慢泄漏避坑复盘
有个长期运行的 C# 服务跑着跑着内存就缓慢不可逆地往上涨,几天就逼近上限不得不重启,不像一下子爆掉而是温水煮青蛙式一点一点涨极难察觉,直到监控曲线连成一条只升不降的斜线。抓内存快照分析发现堆里积压了海量本该回收的对象——一类视图模型对象明明业务早结束、外部也不再引用,却像幽灵赖在内存里死活不被 GC 回收。顺引用链往上追真凶浮出水面:它们都被一个事件牵住了。原来这些短命视图模型创建时订阅了某个长…- 0
- 0
-
用户A看到了用户B的信息:ThreadLocal 串号避坑
这是我职业生涯里最惊出一身冷汗的一次线上事故。我们用 ThreadLocal 存当前登录用户的上下文——请求进来时在拦截器里把用户信息塞进 ThreadLocal、后续业务随时取当前是谁,用了很久一直稳稳的。可某天客服收到一个让所有人头皮发麻的投诉:一个用户登录后在自己的页面里看到的却是另一个陌生用户的姓名手机号订单,用户信息串了——这涉及隐私泄露性质极其恶劣。连夜拉日志排查才拼出全貌:Web 服…- 2
- 0
-
GC 语言也会内存泄漏:Python 服务被 OOM 反复杀死的排查
一个稳稳跑了好几个月的数据处理服务,突然开始被 OOM Killer 反复杀死:重启,过几小时,又被干掉。盯着监控曲线看,那条内存线像爬楼梯一样只涨不跌,撞到上限被杀、清零、再爬。这是教科书级的内存泄漏症状——可这是 Python,一门带垃圾回收的语言,怎么还会漏?几天排查下来真相平淡得让人脸热:漏的不是解释器,正是我们自己的代码。一个图省事的可变默认参数、一个只进不出的全局缓存字典、再加几处循环…- 2
- 0
-
Python 服务内存只涨不跌:从一次 OOM 揪出几个经典内存陷阱
有个 Python 后台 worker 功能很朴素:从队列取任务、处理、写库。可它内存像潮水一样只涨不退,每隔三天就被 OOM Killer 打死,重启又从几百兆开始爬到十几个 G。加了一倍内存,只是把三天 OOM 拖成了六天。最迷惑人的是:Python 明明有垃圾回收,怎么会像 C 那样泄漏?用 tracemalloc 打出增量后真相大白:不是 GC 坏了,而是我们用几种经典写法让本该回收的对象…- 0
- 0
-
JavaScript 内存泄漏排查实战:定时器、闭包、缓存与游离 DOM
一个 Node 服务三天一 OOM、靠定时重启续命,推上去彻查后才发现:JS 有 GC 也照样漏内存,因为 GC 回收的是不可达对象,而你忘了断开的引用让它一直可达。从五类最高发的泄漏面孔(未清的定时器监听器、捕获大对象的闭包、只增不删的全局缓存、游离 DOM、囤进全局的变量)讲到三次堆快照对比法,再到追 Retainers 引用链的固定排查流水线。- 0
- 0
-
Vue 3 + Pinia 大型 SaaS 后台 4 小时浏览器内存从 180MB 涨到 2.4GB 的 14 天复盘:watch 未 stop + Pinia 持有组件实例 + composable 闭包三重叠加 + EffectScope/useScope/ 六套修法 + 13 条 Vue 3 内存治理纪律
2026 年 3 月,我们一个 Vue 3 + Pinia + Vue Router 4 + Vite 5 重度 SaaS 后台(在线营销自动化平台,日活 32 万、单用户平均会话时长 47 分钟、SPA 路由 287 个)在生产环境暴露了一组诡异故障:Chrome Tab 持续使用 4-6 小时后,内存稳定地从 180MB 涨到 2.4GB,操作明显卡顿,P95 帧时间从 16ms 飙到 87m…- 3
- 0
-
Go time.After 在 for-select 循环里每秒 5 万次的内存泄漏 3 天复盘:18 小时准时 OOM + ticker / NewTimer.Reset / Go 1.23 三套正解
event-fanout 服务跑 18 小时稳定 OOM,goroutine 不泄漏 channel 不堆积,heap profile 显示 time.NewTimer 占 63% 分配。根因是 for-select 里 time.After(30s) 每秒触发 5 万次,稳态留 150 万个未到期 timer。本文讲清 time.After 的 runtime 行为、3 种修法、Go 1.23 …- 3
- 0
-
Node.js 风控网关 12 小时 OOM 复盘:Map 改 Object 触发 V8 字典模式 1.7GB 爆炸的 4 天定位
看似无害的 code review 建议把 Map 换 Object 省 25MB,结果两天后 Pod RSS 从 280MB 涨到 2.4GB 周期 OOMKilled。复盘 4 天才发现:500k key 的 Object 被 V8 切到 dictionary mode,backing store 暴涨 + hot path delete 触发 IC 失效双重 deopt 雪崩。本文给出 6 …- 5
- 0
-
FastAPI 每隔 6 小时变僵尸:SQLAlchemy async 连接池静默泄漏 4 天复盘
FastAPI + SQLAlchemy 2.x async 服务每 6 小时连接池打满变僵尸。根因:Depends 用 return 而非 yield + 中间件吞掉 CancelledError + SQLAlchemy close 时机微妙。完整复盘 + 5 层修法 + 监控告警。- 0
- 0
-
Java 服务每周 OOM Metaspace 续命 22 个月的复盘:CGLIB ClassLoader 锁死 + 5 种修法
一个 Spring Boot 服务每周都要 rolling restart 一次救命,运维忘了发起 cron 直接 OOMKilled。挖了 5 天,发现是某 SDK 用 CGLIB 每次反射都新建匿名 ClassLoader,Metaspace 类只增不减。本文是完整复盘:jstat/jcmd/MAT 工具链 + 三层引用链 + 5 种修法 + 8 条字节码使用纪律。- 11
- 0
-
Python 内存泄漏定位实战:tracemalloc + objgraph 8 小时找到 FastAPI 服务 32GB 内存被吃满的根因
分享一次 FastAPI 推荐服务内存从 1.2GB 缓慢吃到 32GB 触发 OOMKilled 的真实排查:用 tracemalloc 定位分配热点 + objgraph 追引用链,8 小时找到三个独立泄漏点(无 bound 缓存、调试代码持引用、fire-and-forget task 抓大对象),附完整工具链对比和预防机制。- 2
- 0
-
Go goroutine 泄漏的 5 个真实场景:11 万协程 OOM 复盘 + 检测方案
一个 Go 微服务每天涨 200MB,heap profile 一切正常,goroutine profile 却显示 11 万个活跃协程,绝大多数卡在 chan receive 上等一个永远不会写入的 channel。本文整理了生产中最常见的 5 种 goroutine 泄漏场景,每种给出最小复现 + 修法,并给出 pprof + goleak 的 CI 检测方案。- 0
- 0
-
JVM 内存与 GC 完全指南:从一次半夜 OOM 告警看懂堆内存怎么排查
2023 年的一个凌晨两点,我被告警电话叫醒:一个核心 Java 服务被系统 OOM Killer 杀掉了。重启、又挂、再重启,堆内存像一条笔直的斜线一路往上爬,涨到顶就崩。我第一反应是"流量涨了内存不够",准备提工单扩容——幸好在提单之前先把堆 dump 下来看了一眼:堆里 80% 的空间被一个 static HashMap 占着,塞了几百万个对象,一个都没被清理。这根本不是…- 7
- 0
-
线上内存慢慢涨到 OOM:一次 ThreadLocal 内存泄漏的复盘
Web 服务运行三五天后内存只涨不落,最终 OOM,靠定时重启续命。堆 dump 显示对象被线程池线程通过 ThreadLocal 死死拽住。几天彻底搞清:ThreadLocal 存值原理、ThreadLocalMap 弱引用设计、线程池复用导致的泄漏与数据串号、finally remove 铁律与 TTL 跨线程传递。- 3
- 0
-
Full GC 后堆只降了 21M:一次 JVM 内存泄漏排查的复盘
服务每隔三四天就有实例变慢、CPU 冲高、重启即愈,典型的频繁 Full GC。GC 日志里 Full GC 后堆只降 21M,基本锁定内存泄漏。dump 堆用 MAT 一查,根子是一个 static HashMap 缓存只进不出。几天排查 JVM 内存:泄漏与容量之分、GC 日志、MAT 分析、缓存治理、ThreadLocal、内存监控。- 2
- 0
-
Full GC 频繁:接口每隔几分钟卡顿一次的排查复盘
查询服务接口 P99 周期性尖刺,每隔三五分钟卡顿两三秒。查慢 SQL、网络都不是,打开 GC 日志才看清是频繁 Full GC。几天治理:读懂 GC 日志、jstat/jmap 定位、dump 出一个 static 无界本地缓存占堆 76%、缓存加上限、换 G1、排查其他诱因、补齐 GC 监控。- 0
- 0
-
ThreadLocal 内存泄漏:网关服务每三天重启一次的真相
网关服务跑几天内存就涨满,频繁 Full GC、接口卡顿,只能定时重启。dump 堆发现一堆对象被 ThreadLocalMap 拽住——经典 ThreadLocal 泄漏;还查出线程池复用导致用户上下文串号。几天治理:set 配对 remove、收口到 Filter、封装 AutoCloseable 强制清理、InheritableThreadLocal 改 TransmittableThrea…- 0
- 0
内存泄漏
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×