当调用 Remove 失效时 [C^#]

Written by Allen Lee

有没有试过从一个集合里面移除一个对象之后，这个集合仍然留有这个对象？世界之大，无奇不有。稍有疏忽，便会导致这种奇怪的现象。现在让我们看看这个“不死”对象究竟是怎么一回事。

1、“不死”对象现身

这个问题起初是我一个同事提出的，为了重现“不死”对象，现把代码简化如下：

其中 Product 类代码如下：

而 GetProduct 方法则根据传入的 ID 从数据库读取数据并返回，它的签名如下：

要想知道编号为 1412 的对象是否从 products 中移除，只需在 Code #01 的最后加上这样一行：

2、一不小心掉进陷阱

不知道你有没有查看 SDK 的习惯，其实 SDK 里面蕴藏着很多对我们解决问题有启发作用的信息的。现在让我们看看 SDK 里面能否找到什么蛛丝马迹。

由于 products 的真身是 List<T>，所以我们有必要看看 List<T> 是如何实现 IList.Remove 的：

原来，List<T> 在 IList.Remove 中使用 EqualityComparer.Default 来判断两个对象是否相等。那么 EqualityComparer.Default 又是如何得知两个对象是否相等呢？

把上面这段话结合 Code #02 来看，我们可以发现 List<T> 中的 IList.Remove 判断两个 Product 对象是否相等的方法是从 Object 根类继承下来的 Equals 和 GetHashCode 方法，即比较两个对象的引用是否指向同一个对象。

由于 GetProduct 方法每次返回的都是一个新的对象（暂时让我们忘记对象缓存这家伙），于是就导致了集合里面出现“不死”对象。

3、不要被同一颗子弹打中两次

“不要被同一颗子弹打中两次”原意是指同一个错误不要两次犯，这句话暗含着对两个表示错误的对象进行逻辑上的判等，就像上面需要判断两个 Product 的对象在逻辑上是否相等那样。

至此，我们也知道了令 Remove 重新生效的两个可选办法是：

• 让 Product 类实现 IEquatable<T> 接口；
• 为 Product 类重写 Equals 和 GetHashCode 方法。

在大多数情况下，我们希望比较的并不是对象的引用，而是对象的内容，与此同时，我们又不太可能为了这些小对象劳师动众地实现对象缓存，于是，你就很有可能在类似的代码中邂逅“不死”对象了。