海量地图性能（java）

我正在从事一个项目，该项目要求我存储（可能）数百万个键值映射，并（可能）每秒进行100次查询。我可以对正在处理的数据进行一些检查，但这只会减少一点负载。此外，我将（可能）每秒进行100次放置/移除，因此我的问题是：是否有足够的地图来完成此任务？有没有办法优化地图？是否有更快的方法可以用于存储键值映射

一些补充资料； -关键是3d空间中的一个点，我觉得这意味着我可以使用阵列，但阵列必须是巨大的 -该值必须是对象

---

任何帮助都将不胜感激

信封背面的估计有助于了解这类事情。如果地图中有数百万个条目，比如说32M，一个键是一个3d点（因此3个整数->3*4B->12个字节）->12B*32M=324MB。你没有提到值的大小，但是假设你有一个大小相似的值，那么这个数字会翻一番。这是Java，所以假设一个64位的平台，带有压缩的OOPs，这是默认的，也是大多数人使用的，你需要为每个对象额外支付12B的对象头。所以：32M*2*24B=1536MB

现在，如果您使用HashMap，则每个条目都需要一个额外的HashMap.Node，在上面的平台上的Java8中，您看到的是每个节点32B（使用OpenJDK JOL查找对象大小）。这使我们达到2560MB。还要考虑HashMap数组的成本，有3200万个条目，您看到的是一个有640万个条目的表（因为数组大小是2的幂，您需要在条目之外有一些空闲），所以这是额外的256MB。让我们一起把它四舍五入到3GB

现在大多数服务器都有相当大的内存（10s到100s的GB），向JVM live set添加额外的3GB应该不会吓到你。你可能会觉得令人失望的是，开销超过了你的数据，但这不是你的情感幸福，而是一个意志是否有效的问题；-）p> 现在您已经加载了数据，您正在以每秒100次插入/删除的速率对其进行变异，比如说1024次，重用上述数量，我们可以将其加起来：1024*（24*2+32）=70KB。对于许多应用程序来说，每秒处理70KB的垃圾是一个很小的变化，您不必为此操心。把它放在上下文中，JVM现在将在10毫秒的时间内收集100多MB的年轻一代

---

因此，总而言之，如果您只需要加载数据并按照您描述的方式查询/修改数据，那么您可能会发现现代服务器可以轻松地与普通解决方案抗衡。我建议你尝试一下，也许是原型，用一些有代表性的数据集，看看它是如何工作的。如果您有问题，您总能找到更奇特/高效的解决方案。

强烈建议使用某种外部数据库（SQL或NoSQL）。每秒数百次的读写并不是那么多，但是如果您试图将其全部保存在一个JVM中，那么数百万个具有大量写操作的条目将导致很多GC问题。当JVM死亡时会发生什么？我不想谈论JVM死亡时会发生什么。。。（所有这些数据都被序列化并保存）。我将研究SQLHBase、memcached、redis等——根据到目前为止所描述的需求，几乎所有这些都应该可以正常工作。如果变异如此频繁，一个带有全局锁的简单HashMap可能会破坏性能。ConcurrentHashMap或类似的东西最有可能被调用。@jtahlborn OP没有提到任何关于并发访问的内容，所以我假设没有。。。即使对于标准RW锁，每秒1000次也不是问题。CHM在头顶上有一个很大的脚印，你最好使用悬崖点击无锁地图。