将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来平衡哈希表 。 这就是它的用途。 不要将它用于其他非设计用途的目的; 那很危险

Answer 3

快速简便的修复似乎是

var dict = new Dictionary<InstanceType, Guid>();
dict.Add(instance, myGUID());

当然，如果还没有正确实现InstanceType.Equals。 （或实现IEQuatable<InstanceType> ）

Answer 4

我能想到的可能问题：

• 散列码冲突可以为您提供重复的字典键
• 不同对象的哈希算法可以为两个功能不同的对象提供相同的哈希码; 你不会知道你正在使用哪个对象
• 这种实现容易模糊（如上所述）; 您可能需要存储有关对象的更多信息，而不仅仅是它们的哈希码。

注 - Jon更优雅地说（ 见上文 ）

Answer 5

由于这是针对WPF控件的，为什么不将Guid添加为依赖项预测呢？ 您似乎已经在迭代用户控件，以获取其哈希码，因此这可能是一个更简单的方法。

如果你想捕获一个控件被删除以及它有哪个Guid，那么订阅关闭/删除事件的一些管理器对象只是存储Guid和其他一些细节将是一个好主意。 然后，如果需要，您还可以更轻松地捕获更多详细信息以进行分析。