重构一些遗留代码 - 潜在的内存泄漏
由于某些内存泄漏，除非执行 IISreset，否则某些内存不会被释放。
我发现一些代码，其中有一类属性和方法，其中只有 10% 的方法特定于该类，90% 可以移动到另一个类。
那有多糟糕？这是否会影响我的记忆，因为我正在向使用该应用程序的每个用户启动此类？
它是 IIS6 上的 ASP.NET 应用程序。
Due to some memory leaks, some memory is not released except when doing IISreset.
I found some code where I have a class of properties and methods, where only 10% of the methods are specific for the class, 90% can be moved to another class.
how bad is that? is this is affecting my memory, because I am initiating this class with every user using the application?
It is a ASP.NET Application on IIS6.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想如果这些方法不需要实例状态但需要一个实例来调用（即它们是从不引用“this”的实例方法），那么它们可以被制作成静态方法并为您节省一个对象分配。但是，如果您无论如何都必须分配对象（听起来就像您所做的那样，对于您提到的其他“10% 的功能”），这听起来并不能解决问题。
您可能应该使用调试器对应用程序中的内存使用情况进行分析。 Rico Mariani 有一篇关于跟踪托管内存泄漏的非常好的博客文章：http://blogs.msdn.com/b/ricom/archive/2004/12/10/279612.aspx。它很旧但仍然相关。 （注意：如果您碰巧使用 .NET 4.0，则需要执行“.loadby sos clr”而不是“.loadby sos mscorwks”来在 WinDBG 中加载 SOS 调试器扩展。）
I suppose if the methods require no instance state but require an instance to call (i.e. they are instance methods that never reference 'this'), they could be made into static methods and save you one object allocation. However, if you have to allocate the object anyway (as it sounds like you do, for the other "10% of functionality" you mention) that doesn't sound like it will fix the issue.
You should probably do an analysis of memory usage in your application using the debugger. Rico Mariani has a pretty good blog post about tracking down managed memory leaks here: http://blogs.msdn.com/b/ricom/archive/2004/12/10/279612.aspx . It is old but still relevant. (Note: If you happen to be using .NET 4.0 you'll need to do ".loadby sos clr" instad of ".loadby sos mscorwks" to load the SOS debugger extension in WinDBG.)