Java 用于存储大量可由稀疏标识符检索的对象的适当数据结构

我想我正在寻找一个稀疏数组实现，但我真的需要它在内存使用方面是高效的，我的数据的一个特点是实现可以利用的，就是索引被填充，如果索引

I

的值存在，索引

i-1

和

i+1

也可能存在值，同样，如果

i

的值不存在，则

i-1

和

i+1

也可能不存在值

我在Java中工作，我需要索引类型为

long

，而不是更常见的

int

，如果这有区别的话。我有大约5000万个需要存储的对象。我已经研究了Trove4J的

TLongObjectHashMap

，不幸的是，仅哈希表就需要大约1.6GB的容量，我确实需要对此进行改进

---

有人能告诉我一些可以优化顺序分配标识符的长期运行的东西吗？我可以接受insert/get的对数性能，所以可能是基于树的性能？

也许您可以使用数据库而不是数组？像h2sql这样的内存嵌入式数据库

b树的内存开销非常小，因此我将尝试这些方法。

数据库的内存占用并不比专用数据结构小（尤其是数据库本身使用该结构时）！我还没有对其进行基准测试，但我怀疑序列化/反序列化开销会给我需要使用此数据执行的计算增加很大的开销（每个项目将随机访问，并且可能在过程中多次访问），这可能会增加数小时甚至数天的时间来完成操作。也就是说，我认为这是最后一招。您知道h2sql是否对大小超过4GB的数据库感到满意吗？我已经看过了，还没有看到任何对这个问题有用的BTree内存实现。你是否有一个特别的想法，或者你只是作为一个一般的方法提出这个建议？只是作为一个一般的方法。这里提到了一些实现：（不要使用红黑树，它会占用更多内存）。由于您有8字节的密钥，我建议您选择16-32tree（这样它可以容纳一行二级缓存）。我不熟悉Trove4J，哈希表的1.6gib来自哪里？对于80%的负载系数和64位引用，一个开放寻址哈希表应该适合915 MiB（5000万*1.2*（64+64）位）。如果显式存储所有键和引用（似乎是良好性能所必需的），理论上的最小信息量为5000万*（64+64）位=762 MiB。需要进行哪些操作？什么是运行时复杂性？