处理大型 HashMap 的内存高效方法

Question

我有一个项目正在处理正在写入 Excel 文件的大量数据。我将这些数据以Map<List<String>, Integer> 的形式存储在一个静态HashMap 中，其中列表的大小只有3。然而，Map 中的条目数可以在0 到11,300 之间。

这个项目的流程是：

• 用条目加载地图

• 迭代地图并做一些事情

• 为下一组条目清除地图

我最近发现的关于 HashMap 的一点是，当超出设定的大小时它会如何重新调整大小。因此，我的地图不仅会不断地以惊人的长度重新调整大小，而且当我清除最大的条目集时，它很可能有大约 20,000 个空条目。

所以我正在尝试对这件事进行微优化，但我陷入了如何做到这一点的两难境地。我的两个想法是：

1. 将初始 HashMap 的默认值设置为允许它最多只调整一次大小的值

2. 使用每个新条目的预期平均大小重新初始化 HashMap，以限制重新调整大小并允许垃圾收集器进行一些清理

我的直觉告诉我选项 2 可能是最合理的选项，但这仍然可以证明根据下一个条目集重新调整大小。但是选项一极大地限制了一次操作的重新调整大小，但随后给我留下了数以千计的空条目。

我提出的两种解决方案中的一种是否比另一种更好，两者在内存改进方面没有太大差异，还是我监督过其他一些解决方案（不涉及更改数据结构）？

编辑：仅在某些情况下，我想这样做是因为偶尔项目会耗尽堆内存，我正在尝试确定这个巨大的地图现在或可能产生的影响有多大。

EDIT2：为了澄清，地图本身的大小是较大的值。密钥大小（即列表）只有 3。

Answer 1

这里的问题和接受的回复非常错误，我不得不回复。

我有一个正在处理大量数据的项目 写入excel文件。我将这些数据存储在一个静态 HashMap 中 form Map, Integer>，其中列表的大小只有 3. Map 中的条目数可以在任何地方 从 0 到 11,300。

请不要误会我的意思，但这是很小！！！甚至不用费心优化这样的东西！我赶紧做了个测试，在hashmap中填充“11300”个元素不到十几毫秒。

我最近发现的关于 HashMap 的一点是，当设置大小被破坏时，它是如何重新调整大小的。因此，不仅我的地图不断地以惊人的长度重新调整大小，而且当我清除最大的一组
条目。

...只是为了清楚。空条目几乎不占用空间，这些只是空指针。在 64 位机器上每个插槽 8 个字节，或在 32 位机器上每个插槽 4 个字节。我们这里最多讨论的是几千字节。

使用每个新条目集预期的平均大小重新初始化 HashMap > 以限制重新调整大小并允许垃圾收集器进行一些清理。

这不是条目的平均“大小”，而是预期的平均条目数量。

编辑：仅在某些情况下，我想这样做是因为 偶尔项目用完堆内存，我正在尝试 确定这张巨幅地图的影响有多大。

不太可能是地图。使用分析器！您可以毫不费力地存储数百万个元素。

---

接受的答案是错误的

您可以在初始化时更改这些值，因此大小为 11300 并且 factorLoad 为 1，这意味着地图的大小不会增加，直到 你的最大值已经达到，在你的情况下，据我所知， 永远不会。

这不是一个好的建议。使用与预期插入的项目数相同的容量和“一”的负载因子，您肯定会遇到大量的哈希冲突。这将是一场性能灾难。

---

结论

如果你不知道东西是如何工作的，不要尝试微优化。

Answer 2

我做了一些研究，最终访问了这个页面：How does a HashMap work in Java

倒数第二个标题与调整开销有关，说明 HashMap 的默认值是 size 的 16 和 factorLoad 的 0.75。

您可以在初始化时更改这些值，因此 11300 的 size 和 1 的 factorLoad，这意味着地图在达到最大值之前不会增加大小，在您的情况下，正如我明白了，永远不会。

我做了一个快速实验，使用以下代码：

public static void main(String[] args) throws Exception {
    Map<String, Integer> map = new HashMap<>(11000000, 1);
    //        Map<String, Integer> map = new HashMap<>();
    for (int i = 0; i < 11000000; i++) {
        map.put(i + "", i);
    }
    System.out.println(map.size());
    Thread.sleep(9000);
}

交换两个Map 初始化，然后检查它在Task Manager 中消耗的内存。

在设置了初始大小和 factorLoad 后，它使用了~1.45GB 的内存。 如果没有设置值，它将使用~1.87GB 的内存。

每次都重新初始化Map，而不是清除它以换取可能更小的Map 来代替它会更慢，但您可能会暂时获得更多内存。

你也可以两者都做。重新初始化以设置初始大小和factorLoad 属性，如果您知道每个循环的List 对象的数量。

该文章还表明，Java 8 HashMap 虽然可能更快，但也可能比 Java 7 具有更多的内存开销。可能值得尝试在两个版本中编译程序，看看哪个版本提供了改进的内存解决方案。如果没有别的，会很有趣。