链表或散列表？

如果你还没有发现代码是应用程序的缓慢部分，那么你不应该做任何事情。

如果速度慢，但是代码已经过测试，工作正常，而且还有其他一些较慢的领域，那么您可以先加快速度。

如果它有问题，那么你需要修复它，去散列表，因为它会比列表更快。 这假设数据遍历的顺序并不重要，如果你关心的是插入顺序是什么，那么坚持使用列表（你可以做一个哈希表的事情，并保持秩序，但这将使得代码非常tricker ）。

鉴于你只需要偶尔搜索一下这个列表，这是你代码中一个重要瓶颈的可能性很小。

另一个数据结构是一个“跳过列表”，基本上可以跳过列表的大部分。 这就要求对列表进行排序，但是，根据你在做什么，可能会使代码整体变慢。

是否使用散列表更为优化取决于您没有详细描述的用例。 但更重要的是，确保性能的瓶颈是在这部分代码中。 如果这段代码只在一段时间内被调用，而不是在关键路径中调用，那么就不用费心去修改代码。

你有没有测量过，并发现查找性能打击？ hash table或hash table应该是好的。

如果你需要遍历列表（不是搜索元素的一部分，而是显示它们），那么链表就是一个不错的选择。 如果只存储它们以便查找元素，那么散列表将大大优于链表（除了最糟糕的散列函数外）。

如果您的应用程序要求这两种类型的操作，则可以考虑保留这两种操作，并使用适用于特定任务的那一种。 内存开销会很小，因为你只需要在内存中保存每个元素的一个副本，并让数据结构存储指向这些对象的指针。

与您采取的任何优化步骤一样，确保您在进行任何更改之前测量您的代码以找到真正的瓶颈。

如果你关心表现，你绝对应该。 如果你正在迭代通过任何规则来查找某个元素，那么使用哈希表是值得的。 但是，如果这是一个罕见的情况，列表的普通用法不是搜索，那么没有理由担心。

如果你只遍历集合，我没有看到使用hashmap的优点。

几乎在所有情况下，我建议不要使用哈希。

有两个原因。 首先，散列的大小是固定的。

其次更重要的是 哈希算法。 你怎么知道你做对了？ 它如何与真实的数据而不是测试数据？

我建议一个平衡的B – 树。 总是O（log n），关于散列算法没有不确定性，没有大小限制。