【问题标题】:Hashtable rehash on remove删除时哈希表重新散列
【发布时间】:2012-08-26 07:09:46
【问题描述】:

有谁知道为什么 hashtable 的 java jdk 实现在删除时不重新哈希表?

如果空间使用率太低怎么办?这不是减小大小和重新散列的理由吗?

就像负载因子 0.75 触发 put 时重新散列一样,我们可以在表的密度上设置一个像 0.25 这样的下限(当然可以在此处对最佳值进行分析)并再次触发重新散列,前提是大小表的容量大于初始容量。

【问题讨论】:

  • 我不会使用 Hashtable,除非你不能使用 HashMap 或过去 14 年添加的新地图之一。顺便说一句,这些集合也不会在删除时调整大小。

标签: java resize hashtable


【解决方案1】:

重新散列是一项昂贵的操作,基于 java 散列的数据结构试图避免它。他们仅在查找性能不佳时才进行重新散列。这就是这种数据结构的目的:查找性能。

这是来自 HashMap java 文档的引用:

在设置其初始容量时应考虑map中预期的条目数及其负载因子,以尽量减少rehash操作的次数。如果初始容量大于最大条目数除以负载因子,则不会发生重新哈希操作。

如果要在一个 HashMap 实例中存储许多映射,创建具有足够大容量的实例将比让它根据需要执行自动重新散列以增长表来更有效地存储映射 .

除了这个论点之外,java 创建者可能认为,如果您的哈希表中有这么多元素,那么再次拥有它们的概率非常大,因此不需要重新哈希表两次。

【讨论】:

    【解决方案2】:

    您应该询问 Sun/Oracle 工程师,以了解为什么没有减小尺寸的阈值。

    这是我的两分钱:

    • 重新散列表格需要时间
    • 检查每个删除操作都需要时间

    另一方面:

    • 可能不会节省太多内存(表中的对象和节点会占用更多空间)
    • 可能没有多少场景会先创建(一些)非常大的哈希表,然后清空它们并渴望未使用的空间。
    • 您知道任何包含该行为(减小表大小)的流行实现

    在编程和生活中一样,有很多事情可以做。有些仅适用于非常特定的情况。有些根本不值得痛苦。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2012-12-25
      • 2020-11-04
      • 2011-12-15
      • 2016-01-23
      • 2016-01-29
      • 2012-02-28
      • 1970-01-01
      • 2018-05-30
      相关资源
      最近更新 更多