我正在开发游戏，为了安全起见，任何用户（程序员）只允许将ID存储到对象而不是指针，并且必须使用此ID来获取指向对象的指针以便不得不单独使用它。
让我们使用最糟糕的情况：每个ID都在使用中。它是64位所以你去：18446744073709551616要搜索的ID。许多数据存储在数据库中，我们的程序查找要么返回指针，要么返回空指针。空指针意味着程序必须访问数据库才能加载对象，之后它将有一个指针。
思路： 所以我在这里知道的唯一真正的技巧是二元搜索。因此，在最坏的情况下，这意味着每次ID查找都会进行64次比较。
我的另一个想法是创建一个静态空间分区，一个树，每个分支分成2个分支的权力，但只有一个合理的深度。在ID上使用按位运算符而不是模数运算符，以在每个级别上找出它所属的分支。树中的每个可能的分支始终存在，但是在某种程度上它们会停止并且仍然需要二进制搜索，因为确切的值数仍然是未知的。
你有什么想法？
答案 0 :(得分：3)
这是哈希映射的经典案例。首先，要了解在任何时候您实际可以有多少ID。 2 ^ 64是无意义的，因为即使数据结构只是为了保存这些ID和指向对象的指针已经至少268'435'456 TB。现在，使用64位ID并没有什么问题，但要弄清楚你在任何时候有多少个对象，选择一个合理的数字，例如5'000，并使用比对象数量多10倍的哈希映射。如果您的负载因子足够低并且您的散列函数足够好，您将获得摊销的O（1）访问时间。
答案 1 :(得分：2)
即使活动对象的数量会大得多，比如100万，您仍然可以使用相对较小的哈希映射，例如大小为10000的映射。映射的每个元素都指向一个ID的链接列表。使用简单的线性searrch搜索这些列表。如果很好地选择了散列函数，则ID将在散列映射中的10000个条目上均匀分布（或接近）。因此，哈希表的每个条目将包含大约100个ID。线性搜索这样的列表平均需要50次比较。
在我的一个应用程序中，符号数量约为1000.我只使用简单的线性搜索。性能分析表明，90％的CPU时间花在了表查找中。接下来，我制作了一个只有32个条目的哈希表 - ＆gt;表查找的CPU负载降至4％以下。问题解决了。扩大哈希表对速度没有明显的影响（小于4％）所以我把它保留为32的大小。
结论：您可以使用小于元素数量的哈希表。这需要平均比较次数（ID总数/散列表大小/ 2）选择足够大的散列表大小，以便将表查找的CPU时间减少到总CPU时间的一小部分。
答案 2 :(得分：1)