.net clr 8年才修复的BUG，你让我损失太多了

一、概述

.NET社区修复问题可谓是龟速，一个BUG在.NET 7.0+版本才修复，你让我损失了几万块，我现在还记得客户那种质疑的表情，你了解那种尬尴的气氛吗？你让我一度怀疑dotnetty,我从来不去怀疑框架，运行时，每次碰到问题，我先提醒使用者先去找自己的问题，现在让我改变了这个看法。

凯亚 (Kayak) 是什么?

凯亚(Kayak)是基于.NET6.0软件环境下的surging微服务引擎进行开发的, 平台包含了微服务和物联网平台。支持异步和响应式编程开发，功能包含了物模型,设备,产品,网络组件的统一管理和微服务平台下的注册中心，服务路由，模块，中间服务等管理。还有多协议适配(TCP,MQTT,UDP,CoAP,HTTP,Grpc,websocket,rtmp,httpflv,webservice,等),通过灵活多样的配置适配能够接入不同厂家不同协议等设备。并且通过设备告警,消息通知,数据可视化等功能。能够让你能快速建立起微服务物联网平台系统。

凯亚物联网平台：http://117.72.121.2:3100（用户名：fanly  密码：123456）

链路跟踪Skywalking V8:http://117.72.121.2:8080/

surging 微服务引擎开源地址：https://github.com/fanliang11/surging（后面surging 会移动到microsurging进行维护）

二、压测分析

通过jmeter分析，高并发是没问题的，带宽一直是跑满的。

内存也没问题

但是你会发现，运行11天后内存就增长到1g多，每天要增长100多mb

三、用dump 分析

用vs 分析指出是dotnetty 的 ManualResetEventSlim 导致的，但是我看了代码没有问题啊，让我思绪有些混乱，就让我手足无措，甚至想下载dotnetty 把ManualResetEventSlim去掉试试，后面我发现mono社区有人讨论ManualResetEventSlim内存泄漏的问题，还是2020年提出的，一直没解决，后面2023年有人重提这个问题，有人回复这个问题是由于Queue删除队列没有把元素的引用一起删除导致的内存泄漏，而后在.NET 7.0把这个问题修复了。

原帖讨论：https://github.com/mono/mono/issues/19665

有人找到原因，在.NET CORE3.1 问题依旧存在

2023年重提这个问题

然后给出回复是.NET7.0 已经修复

然后surging和kayak 升级到.NET 8.0 ,启用几十个组件和协议，内存在70，80MB左右。后续观察内存是否还会增长