-
我那些频繁创建又销毁的对象,订阅了一个单例的事件却忘了退订,结果它们一个都没被回收、内存一路涨到 OOM:一次 C# 事件订阅未取消导致内存泄漏的深度复盘
我有一类频繁创建又销毁的对象(随每个请求创建的 Handler),创建时订阅了一个长生命周期单例 EventBus 的事件:bus.DataChanged += this.OnDataChanged。功能没问题,可线上内存一路缓慢上涨、只涨不降,跑久了 OOM。内存 dump 才看明白:那些本该被回收的 Handler 一个都没被 GC,全被 EventBus 的委托链引用着。根因是它们订阅了单例…- 2
- 0
-
我的服务运行越久内存涨得越凶,最后内存泄漏到崩溃,排查发现是一堆本该被回收的对象因为订阅了事件却没取消订阅、被发布者死死攥着无法回收,我对着 C# 事件订阅导致的内存泄漏这个坑排查大半天的复盘
一个让我对有了 GC 就不会内存泄漏这个错觉彻底清醒的 C# 坑,隐蔽在 C# 有垃圾回收我一直以为对象没用了 GC 自然会回收根本不用操心,可这次一堆本该被回收的对象却被一根我没注意到的引用线死死拴住、GC 怎么也回收不了。服务运行越久内存涨得越凶最后 OOM 崩溃。场景:短生命周期对象 TempHandler 订阅了长生命周期全局服务 GlobalService 的 DataChanged 事…- 2
- 0
-
页面明明都关了,程序内存却只升不降、最后被撑爆:我在 C# 里订阅了事件却忘了退订,埋下的那个悄无声息的内存泄漏的深度复盘
客户端程序的页面反复开关,内存却只升不降、最后撑爆。内存分析发现:那些"已关闭"的页面对象一个都没被 GC 回收!根因是页面在打开时订阅了长寿的"数据中心"单例的事件、关闭时却忘了退订——而订阅事件会让发布者持有对订阅者的引用,长寿的数据中心就一直拴着本该销毁的页面,导致它永远无法回收。这篇从事件订阅为何泄漏(发布者引用+GC规则+谁更长寿)讲到 -= 退订…- 0
- 0
-
事件订阅没退订:C# 内存缓慢泄漏避坑复盘
有个长期运行的 C# 服务跑着跑着内存就缓慢不可逆地往上涨,几天就逼近上限不得不重启,不像一下子爆掉而是温水煮青蛙式一点一点涨极难察觉,直到监控曲线连成一条只升不降的斜线。抓内存快照分析发现堆里积压了海量本该回收的对象——一类视图模型对象明明业务早结束、外部也不再引用,却像幽灵赖在内存里死活不被 GC 回收。顺引用链往上追真凶浮出水面:它们都被一个事件牵住了。原来这些短命视图模型创建时订阅了某个长…- 0
- 0
事件
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×