将Object.GetHashCode()转换为Guid

Question

我需要为应用程序启动和关闭时管理状态的对象分配一个guid看起来我可以使用字典将查找值存储在字典中

dictionary<int,Guid>.Add(instance.GetHashCode(), myGUID());

这里有什么潜在的问题需要注意吗？

注意

这不需要在执行运行之间持续存在,只需要像这样的guid

• 创建对象
• gethashcode(),与新的或旧的guid相关联

• 在应用程序终止之前,gethashcode()和查找guid以更新()或插入()到持久性引擎USING GUID

  唯一的假设是gethashcode()在进程运行时保持一致

  在相同的对象类型(从窗口派生)上调用gethashcode()

更新2 - 这是更大的图片

• 创建一个状态机,以便在运行之间存储有关WPF用户控件(后来引用为UC)的信息
• 用户控件的类型可以随时间变化(添加/删除)
• 在第一次运行中,没有先前状态,用户与U​​C的子集交互并修改其状态,需要在应用重启时重新创建
• 当应用程序正常关闭时,将拍摄此状态快照
• 也可以有多种UC类型的实例
• 在关机时,每个实例都会分配一个guid,并与类型信息和状态信息一起保存
• 所有这些guid也存储在一个集合中
• 在重新启动时,为每个guid,创建对象,存储ref/guid,恢复每个实例的状态,以便应用程序看起来与以前完全一样
• 用户可以添加或删除UC实例/类型,否则与系统交互
• 在关机时,状态再次被保存
• 此时的选择是删除/删除所有先前状态并将新状态信息插入持久层(sql db)
• 随着时间的观察/分析,事实证明很多实例保持一致/静态并且不会改变 - 所以它们的状态不需要再次删除/插入,因为状态信息现在非常大并且存储在非本地数据库上
• 所以只保留更改增量
• 要计算增量,需要跟踪参考生命周期
• 目前存储List<WeakReference>在启动时
• 在关机时,遍历此列表并在屏幕上显示实际UC,相应地添加/更新/删除密钥
• 将delta发送到持久性

希望上面说清楚.

所以现在的问题是 - 为什么不只是存储HashCode(仅用户控件)而不是WeakReference在通过列表迭代时消除空引用的测试

更新3 - 谢谢所有,最后将使用弱引用

Answer 1

您似乎假设哈希码是唯一的.散列码不起作用.有关更多详细信息,请参阅Eric Lippert 关于GetHashCode指南和规则的博客文章,但基本上您应该只为保持良好行为的类型做出假设 - 即如果两个对象具有不同的哈希码,则它们肯定是不相等的.如果它们具有相同的哈希码,则它们可能相等,但可能不相同.

编辑:如上所述,您也不应该在执行运行之间保留哈希码.面对重启,无法保证他们会保持稳定.目前还不是很清楚你正在做什么,但这听起来不是一个好主意.

编辑:好的,你现在已经注意到它不会持久,所以这是一个好的开始 - 但你仍然没有处理哈希码冲突的可能性.你为什么要打电话GetHashCode()？为什么不直接添加对字典的引用？

Answer 2

使用GetHashCode来平衡哈希表.这就是它的用途.不要将它用于其他非设计用途的目的; 那很危险