Azure Web站点无响应求助：CaliEventHandlerDelegateProxy内存泄漏排查

从你描述的问题来看，这个随机无响应+代理类泄漏的情况有点特殊，尤其是附加DotNetMemory就会触发泄漏加速这个点，是个非常关键的线索。我来拆解下可能的根源和具体排查方向：

一、先排除内存分析工具本身的影响 #

你提到仅仅把DotNetMemory附加到w3wp.exe进程，就会让CaliEventHandlerDelegateProxy和ArglessEventHandlerProxy快速增长直至站点崩溃，这大概率和工具的动态注入机制有关：

• 这类带Cali前缀的代理类，通常和代码插桩、覆盖率分析相关。DotNetMemory在捕获内存状态时，可能会通过动态生成代理来拦截应用内的事件，而如果你的应用事件模型和工具的插桩逻辑存在兼容性问题，就会导致代理对象无法被GC正常回收。
• 建议尝试：
  • 升级DotNetMemory到最新稳定版本，看看是否有已知的代理泄漏bug已被修复；
  • 换用WinDbg配合SOS扩展来分析内存，验证不使用DotNetMemory时，这些代理类是否依然会缓慢增长（彻底排除工具本身的干扰）。

二、定位代理对象的根引用（核心步骤！） #

不管是工具触发还是应用本身的问题，找到这些代理被什么对象持有是解决问题的关键：

• 在DotNetMemory中，选中这些代理类的实例，查看引用链（Retained By），找到最上层的根对象——是静态集合？未释放的页面/控件实例？还是第三方库的缓存容器？
• 如果根引用是DotNetMemory的内部钩子对象，那就是工具兼容性问题；如果是应用内的静态对象或未清理的事件订阅，那就是代码/第三方库的问题。

三、Redis异常是表象，而非根源 #

你提到崩溃后出现大量Redis连接异常，但Azure Redis负载从未超过10%，这完全符合代理泄漏引发的连锁反应：

• 当数千个代理对象占用大量内存和线程资源时，ASP.NET的线程池会被耗尽，Redis客户端（比如StackExchange.Redis）无法获取空闲线程来处理连接/请求，进而抛出连接超时、无法获取连接池等异常。
• 建议用PerfMon监控以下指标验证这个推论：
  • .NET CLR Threads -> ThreadPool Thread Count
  • .NET CLR Threads -> ThreadPool Queue Length
  • 如果崩溃前线程数飙升、队列长度超过阈值，就能确认是线程耗尽导致的Redis异常。

四、排查第三方工具/框架的干扰 #

CaliEventHandlerDelegateProxy这类命名风格的代理，很大概率来自AOP框架、性能监控工具或者代码覆盖率工具：

• 检查你的应用是否集成了PostSharp、Fody这类AOP工具，或者Azure Application Insights、New Relic这类监控工具的旧版本——这些工具可能通过动态生成代理来拦截事件，若清理逻辑不完善就会导致泄漏。
• 尝试临时禁用这些第三方工具，观察代理泄漏是否消失，逐步排查出元凶。

五、ASP.NET页面生命周期的残留问题 #

虽然你已经修复了WebUserControls对母版页的依赖，但还是要再确认：

• 有没有在Global.asax或者自定义控件中，注册了静态事件订阅但从未取消？比如Application_Start中绑定的全局事件，没有在应用停止时清理；
• 检查页面/控件的Unload事件，是否有未清理的事件绑定——即使事件处理逻辑极少，只要有一个静态引用持有页面实例，就会导致整个页面树无法被GC回收，连带代理对象一起泄漏。

临时解决方案优化 #

目前的定时回收应用池可以优化下，减少不必要的服务中断：

• 在IIS/Azure Web App的应用池设置中，将回收条件从“固定时间间隔”改为内存阈值触发（比如私有字节达到2GB时回收），这样既能避免泄漏积累到崩溃，又能减少正常运行时的回收次数。

内容的提问来源于stack exchange，提问作者Tom Gullen