java - 当值的大小变化很大时，ChronicleMap 会导致 JVM 崩溃

Question

到目前为止，我们已经成功地使用 ChronicleMap 来完成我们想要使用它做的大多数事情，并且大多数数据集都工作得很好。我们的一个用例是将其用作多重 map ，涵盖了这样做的大部分问题。在本例中，我们专门将其用作 Map<String,Set<Integer>>。然而，我们遇到了一些有趣的 JVM 崩溃，并且很难找到确定性模式来避免它们。

因此，在我们将所有 Set<Integer> 放入 ChronicleMap 之前，我们已将其完全存储在 JVM 中，因此我们立即写入以减少碎片。由于我们将其完全存储在内存中，因此我们可以确定 Set<Integer> 的最大和平均大小，并且可以使用 ChronicleMap 轻松适本地调整 ChronicleMapBuilder.averageValueSize 的大小。在大多数情况下，这工作得很好。

但是，在某些情况下，当 Set<Integer> 的大小偏离平均值太远时，JVM 会崩溃。例如，平均大小可能是 400，但我们可以有包含 20,000 个整数的异常值集。我们仍然可以使用一组 400 个整数的平均序列化大小来调整映射的大小，并且它开始填充 ChronicleMap ，直到达到非常大的列表。

所以问题是:我如何计算出与平均值的偏差有多大？我希望平均值确实是平均值，但似乎存在一些高于该平均值的最大值，导致 JVM 死机。

我们设计了一种算法将大集合拆分为较小的集合(例如，如果 key 是 AAA，那么现在有 key AAA:1、AAA:2、... AAA:n)。分割集的大小是平均大小的 10 倍。换句话说，如果平均大小为 500，但我们有一个包含 20,000 个元素的集合，我们会将其分成四个 5,000 (500 * 10) 元素集。

这在大多数情况下都有效，但后来我们遇到了另一个奇怪的情况，甚至这种拆分还不够。我将系数减小到平均大小的 5 倍，现在它又可以工作了……但是我怎么知道它足够小呢？我认为了解问题的根源或如何准确确定问题的原因是最好的方法，但可惜的是，我不知道为什么 ChronicleMap 在这里陷入困境。

另外，FWIW，我使用的是旧版本 2.1.17。如果这是在较新版本中修复的错误，我想了解有关该错误的一些详细信息，以及我们是否可以通过自己的方式避免它(例如拆分集合)，但仍继续使用 2.1.17(我们稍后会升级；只是不想再惹麻烦)。

Answer 1

如果不重现该错误，我无法 100% 确定，但我知道为什么在这种情况下会发生 JVM 崩溃。如果我是对的，如果您的条目大小超过 ChronicleMap 的 64 * chunkSize，就会发生这种情况。 block 大小可以直接配置，但如果您仅配置平均键和值大小，则默认为 2 的幂，即在averageEntrySize/8 和averageEntrySize/4 之间，其中平均条目大小是averageKeySize 和averageValueSize 的总和，加上一些内部开销。因此，在您的情况下，如果您有平均值 - 400 或 500 个整数(每个 4 字节)+ 小键的集合，我认为 chunkSize 计算为 256 字节，因此您的条目应该小于 256 * 64 = 16384 字节。

同样，如果我对这个错误的假设是正确的，那么 Chronicle Map 3 不应该有这个错误，并且应该允许任意大于平均大小或 block 大小的条目。