在最近的公司框架开发中，利用了网上某大牛的反射缓存库作为辅助。在测试的时候发现出现了巨大的内存泄露，在频繁的操作后，内存不断的产生巨大的开销，10多分钟就占有了5,6m的内存。解决问题的时，公司不能上网，没有内存分析工具，没有我钟爱的ANTS Memory Profiler帮助下，我们只能靠简单的内存输出来二分查找缩小范围，利用

命名空间下的Process的WorkingSet64属性来统计两次输出的内存增长量（WorkingSet64：描述关联的进程分配的物理内存量（以字节为单位））。花了半天终于定位到了第三方的缓存块，一看吓一跳居然缓存了2,3万的对象。看到这里我很清楚的猜测到自定义缓存key一定没有重写来自Object的Equal方法，在三两下很快解决了这次问题。哎，本不该相信第三方，刚开始还以为我数据绑定注册的一大堆客户端控件的事件引起的，但是我实现了IDisposable并取消了事件的，必究事件代理是强类型引用。

    在这里我简单说说这个本是基础知识的东西。说道Equal，我们会联想到==操作符，==对于值类型表示的是值相等，除string类型（内部重写）外表示的是对象的引用，同一个引用地址才会相等。Equal描述的是对象的内容是否相等。但是在Object中默认实现是对引用reference的比较，我们要实现值的比较这必须重写Equal方法和GetHashCode方法，这两个是同时重写的。在我们的IList.Contains，IDictionary.Contains中利用对象的比较就是默认的Equal方法比较，所以我们必须重写这个方法，来达到我们实际的值比较。

   然而在我们3.0后的表达式linq中对于对象的比较，我们需要实现的IEqualityComparer<T>接口，如下定义：

public static bool Contains<TSource>(this IEnumerable<TSource> source, TSource value, IEqualityComparer<TSource> comparer);

在微软内部实现了5个重要的类，如下图（图来自博客园鹤冲天大牛）：

在这里我不想在说很多，关于可以参见博客园鹤冲天大牛的，文章实战。

最后给初学者提醒一句，对于IList.Contains，IDictionary.Contains注意实现Equal和GetHashCode，Linq比较IEqualityComparer<TSource>。

本不该错的，应该是大牛忘写了吧，可是害惨了我。

 本文转自 破狼 51CTO博客，原文链接：http://blog.51cto.com/whitewolfblog/835245，如需转载请自行联系原作者