【问题标题】:Memory-efficient way to store large List<Map<String,String>> where many map entries are identical存储许多映射条目相同的大型 List<Map<String,String>> 的内存有效方法
【发布时间】:2015-12-03 23:03:44
【问题描述】:

我正在寻找一种节省内存的方法来存储通常由大约 150000 行 x 200 列组成的表格数据。 单元格值是长度在 0-200 个字符范围内的字符串。

数据行最初是通过从较小的表中获取所有可能的行组合来生成的。因此,虽然所有行都是唯一的,但列包含相同值的许多副本。 数据不是只读的。某些列(通常最多 200 列中的 20 列)使用取决于其他列的值的值进行更新。具有计算值的新列(我预计也有大约 20 个)将被添加到表中。

现有的遗留代码严重依赖于存储在 ListMap&lt;String, String&gt;s 中的数据,这些数据将列名映射到单元格值。 但是当前的实现,ArrayList&lt;HashMap&lt;String,String&gt;&gt;,占用了很多 GB 的内存。

我尝试在插入HashMap 的键和值上调用String.intern()。这将内存占用量减半。但是保留所有相同的Map.Entrys 似乎仍然非常低效。

所以我想知道:您能否建议一种内存效率更高的数据结构以某种方式共享相同的列值,但这样我就可以保持外部List&lt;Map&lt;String, String&gt;&gt; 接口相同?

我们已经在类路径中有番石榴,所以使用番石榴中的集合就可以了。

【问题讨论】:

  • 用单字符字节数组替换字符串也可能会减少内存占用(在最佳情况下减少 50%)。字符串在 Java 中是相当浪费的。
  • @PhilippClaßen 谢谢,我没想到。在 String.intern() 之后,字符串现在只占用相对较少的内存。

标签: java data-structures out-of-memory guava


【解决方案1】:

我发现GS-Collections 更适合内存高效的地图/集。他们通过在幕后使用一些巧妙的数组技巧来解决存储地图条目对象的大量开销。

【讨论】:

  • 非常棒,谢谢!这又减少了 90% 的内存。
  • GS Collections 已迁移到 Eclipse Foundation,现在称为 Eclipse Collections - eclipse.org/collections
猜你喜欢
  • 2019-11-27
  • 2018-12-07
  • 1970-01-01
  • 2013-01-15
  • 1970-01-01
  • 1970-01-01
  • 2015-06-19
  • 1970-01-01
相关资源
最近更新 更多