这真的是您应该烦恼的吗? 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来跟踪所有对象的创建和销毁,您并不一定会受到性能的限制,并且可能会产生更多开销。 在这种情况下,您可以尝试现有的解决方案,而不是从头开始构建自己的解决方案,从而可能会更好。
参考:从我们的JCG合作伙伴 Vlumimir Sor(位于Plumbr博客)中 选择您的收藏库 。
翻译自: https://www.javacodegeeks.com/2013/01/selecting-your-collections-library.html