收藏表数据库_选择您的收藏库

收藏表数据库

这真的是您应该烦恼的吗？ java.util.ArrayList和java.util.HashMap从根本上有问题吗？ 对于大多数源代码，答案是–不； 这些实现完全可以。 但是，一如既往，细节决定成败。 并存在情况下，当是内置到功能设置集合API不够充分，或者您找到标准的集合设置成开销太高了您的喜好。

在过去的几年中，我们不断地偶然发现同样的问题。 并且认为分享经验会很好–希望它可以节省一两天的时间。 通过避免另一种双向Map实现或理解为什么他的HashSet消耗的内存比预期多10倍来实现。

我们已将评论分为两个不同的集合库组。 首先，它们为标准Collections API提供了其他功能。 在这个小组中，我们有Guava和Apache Commons Collections这样的玩家。 另一组Collection库可以在某些方面发挥作用。 在这个小组中，我们看到诸如Trove，fastutil和Huge Collections之类的库。 我们从添加功能的库开始概述，然后进入面向性能的环境。

集合API

每个Java开发人员都应该熟悉的真正基本的API之一。 但是，至少每个月一次，我们会碰到一个真正有创造力或者只是不愿意熟悉Collections API的人编写的代码。

因此，如果当ArrayList更合适或者不了解TreeSet和TreeMap之间的区别时，您的任何一个同事也正在使用Vector，那么Janeve George就整个API进行了很好的概述 ，并解释了何时使用哪种类型的Collections。 。

引用我们今天所知道的Collections API的起源也很好。 Collections API中可用的大多数抽象，结构和功能最初是由Doug Lea在其collections包中设计的。

番石榴

Guava （以前称为Google馆藏）是一组在多个Google产品中使用的库。 该库的重要部分专用于馆藏。 例如，在需要时，您应该查看番石榴：

• 100％线程安全的集合–签出ImmutableCollections
• 轻松计算集合中特定元素的出现次数– MultiSet和SortedMultiSet可以节省您的一天。
• 想要实现未标记的有向图？ Multimap是您最好的朋友。
• 是否需要实现一个键和值都唯一且都应可用作搜索值的键的映射？ 番石榴的双向地图将帮助您。

…还有更多有趣且有用的实现，您可以从项目的主页中检出。

Apache Commons集合

Commons Collections由多个Apache项目使用，如果您需要其他功能，例如Commons Collections，它是一个不错的附加组件：

• FIFO / LIFO实现–查看“ 队列和缓冲区” 。
• 一个集合可以保留同一元素的多个副本？ 将它们放入袋中 实施。
• 一个Map，其中的元素按特定顺序排列，但未根据键的compareTo（）进行排序-解决方案以OrderedMap的形式提供。

为了使本文的字符数保持在30,000个以内，我将不介绍所有优点，但我可以验证Apache Commons Collections项目中还有很多不错的实用程序和工具。

宝藏

如果您保存在集合中的都是数字，那么Trove可能会帮助您提高性能并减少内存开销。 Trove是一组收集类，专门用于保存原语。 如果您还记得的话，与使用对象包装的对象相比，消耗的内存要少得多。

快速测试表明，在较大的collection上，Trove实现所需的堆至少比标准Java Collection实现少三倍。 如果您认为这是无关紧要的开销，那么在32位计算机上，包含100,000个整数的Map使用java.util.HashMap需要6.3MB的堆，而使用Trove则需要1.8MB的堆。 现在，从包含数以千万计的元素的集合来看，已经开始有意义。

与Trove相当的东西，即Apache Commons Primitives和Java的Primitive Collections似乎都被放弃了。 两种情况下的最新版本均始于2003年。

大量收藏

如果您要消除的痛点与旧版本中的大型集合导致的长时间GC暂停有关，则应查看Huge Collections 。 它们完全将内容保留在堆外，因此几乎完全不影响垃圾收集。 从下面的数据集可视化中您可以亲眼看到，作者正在发布用在GC上的数字，这些数字在数据结构上具有不同的大小：

高度可扩展的Java

需要锁定不重要的解决方案吗？ 是否需要在具有数十个或数百个内核的环境中使用数据结构？ 然后为您创建了高度可扩展的Java 。 感谢Cliff Click对此。

fastutil

需要工作与超过2 ^ 31个元素真正的大集合？ 查看fastutil –它为您提供了与那些野兽一起工作的数据结构。 从历史上看，这个问题并不是什么大问题。 为什么-因为我们没有这么大的数据结构。 而且在极少数情况下，我们确实有这种大小的结构，在API本身施加2 ^ 31的限制之前，我们会遇到RAM限制。 因此，在那种情况下，我们创建了一个包含100万个百万元素的单一集合，而我们切换到了分区。

其他

无论如何，本节最后的图书馆比（引起关注）的图书馆更糟糕。 只是这些是我们没有机会在实践中尝试的Collections。 至少直到本文发表为止。 但是，由于我们的读者，我们得到了一些提示，并在1月9 ^日的已发表文章中添加了该部分：

Javolution –使用Javolution集合的主要原因是它们具有时间确定性（最大执行时间非常接近最小执行时间），并且它们是RTSJ-Safe。 因此，如果您要编写硬性或软性实时应用程序，并且必须处理执行期限和CPU时间预算，那么请进行检查 。

高盛收藏 。 您可能喜欢或可能不喜欢投资银行业务，但是GS Collections背后的概念肯定很有趣。 该库为常用操作添加了许多便利方法，否则需要您编写Iterators和匿名类。 还声称GS集合还消耗更少的CPU周期和堆。 自2005年以来的图书馆显然已经使用了高盛的内部应用程序和我们渴望通过尝试一下自己 。 图书馆还随附了GS Collections Kata项目中包装好的实用培训材料。

摘要

正如我们文章中经常发生的那样，在您手头的95％的问题中，此处介绍的库除了使您的设置复杂之外，不会添加任何其他内容。 但是在极少数情况下，您需要其他功能或需要挤出最后一点性能时–熟悉环境是一件好事。 在自己编写半熟的解决方案之前，请做出明智的选择。

完全免责声明：在熟悉所有上述解决方案之后，由于与性能相关的各种原因，我们仍然最终构建了自己的解决方案。 但是，通常情况下，您并没有像–javaagent那样跟踪所有对象的创建和销毁，因此性能受到限制，并且可能会增加一些开销。 在这种情况下，您可以尝试现有的解决方案，而不是从头开始构建自己的解决方案，从而可能会更好。

参考：在Plumbr博客博客中，从我们的JCG合作伙伴 Vladimir Sor 选择您的收藏库 。

翻译自: https://www.javacodegeeks.com/2013/01/selecting-your-collections-library.html

收藏表数据库