插入的分摊运行时间和获取Java的HashMap

时间:2017-07-19 21:43:18

标签: java algorithm performance hashmap amortized-analysis

我在概念上理解插入和获取操作在Java的Hashmap(简化为哈希表)中具有O(1)的分摊运行时间这一事实。 请注意,在我的示例中,表是以最大容量创建的,这意味着只有当满足75%的加载因子时,才需要扩展一次。 Get也永远不会被调用无效目标。

摊销的运行时间通过O(总成本)/运营计数计算。

对于insert,将一个元素添加到与哈希表中的特定槽对应的桶中。由于最新值始终添加到存储桶的末尾,因此其值为:

  • 总费用=在桶末端找到桶+位置,所有O(1)时间
  • 操作次数=在桶尾找到桶+位置
  • 因此,摊销运行时间=(找到桶+位于结尾处 桶)/(在桶的末端找到桶+位置),或O(1)

这里让我困惑的唯一方面是,如果添加的元素将表放在其加载因子上,请调整其大小。 Java在这里执行了哪些步骤,为什么它仍然是O(1)摊还的运行时间?

对于get,查找存储桶的时间是不变的,找到匹配可能需要1个操作(目标是存储桶中的第一个值)到n个操作(所有条目都在同一个存储桶中,目标是在底部)。在这种情况下:

  • 总费用=查找存储桶+在存储桶中查找目标的步骤数, 所有1个时间单位
  • 操作次数=查找存储桶+在存储桶中查找目标的步骤数
  • 因此,摊销运行时间=(查找桶+在桶中查找目标的步骤数)/(查找桶+在桶中查找目标的步骤数)或O(1)

这是我尝试将摊销思维过程应用于这些操作,但由于我对这个概念很新,我不确定我的逻辑是否正确,并且希望得到一些反馈是否是我是对的还是b)我出错的地方。任何帮助表示赞赏。

0 个答案:

没有答案