最近在看Dictionary的源代码的时候, 突然想到Dictionary的不当使用中有一种隐含内存泄漏的可能.
小A正在写一个简单的图书销售系统.
他首先需要处理的是订单和订单里面对应的书目集合. 接着他发现自己需要一个特定的内存结构, 来临时保存所有的订单及其伴随的销售书目集合, 以减小对数据库的压力. 小A想到了词典Dictionary这个保存关联数据最好用的结构 - 将订单Order对象做为键, 将对应的销售书目Books作为值, 保存在词典中.
订单中包含订单ID/订货人ID/订货时间. 小A知道, 要想将Order对象作为键, 他必须重写Order类的GetHashCode()方法和Equals()方法, 使这两个函数有意义而不是接受系统默认的实现, 这是Dictionary所要求的. 这个功能实现示意如下:
Order Class
后来他发现,对于已经存在的有些订单如果存在用户更改了购买的书籍等操作, 这些订单需要更新, 在更新后需要更新订单的时间戳:
Update Order Property
这个简单的系统写完后刚送去质量部门刚测试了两天, 老板就把小A叫到眼前狠狠剋了一顿, "Memory Leak!"
问题出在了作为Dictionary键的Order对象身上.
Dictionary的.NET实现有一个隐含的特性比较容易让人忽略, 那就是它对于存储数据的定位方式. Dictionary是通过对键的哈希值进行散列计算, 从而确定其对应的值存放的位置. 而Dictionary内部的添加/删除/修改操作, 都完全地依赖于这一定位方式. 这个定位方式, 在Dictionary源代码中体现为FindEntry()操作:
当某一个order的BoughtTime属性改变时, 对应的order的哈希值也改变了, 这时伴随该order的书目列表还在Dictionary中,但是FindEntry()操作却没法再定位到它. 这个书目列表将一直存在在Dictionary当中,直到这个Dictionary的生命周期结束. 这就是隐含的内存泄漏. 如果这是个WinForm程序, 或许影响还不是很大. 但是如果出于一个要求高在线率的网络服务当中时, 内存使用Overflow的异常将肯定是不可避免的.
在这个简单场景中体现出来的内存泄漏, 在更为复杂的场景下, 可能会更隐蔽也更难发现.虽然基本的道理是一样的,但是在更复杂的业务逻辑中, 我们可能更容易忽略它的危害.
如果一个业务对象在业务逻辑中可能会被修改, 千万不要将它作为Dictionary的键!!! 使用对象作为Dictionary的键时, 要慎重的考虑这个对象会不会在其余的地方有隐式或者显式地被改变的可能.
恰当的使用Dictionary.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。