收藏表數(shù)據(jù)庫

這真的是您應該煩惱的嗎？ java.util.ArrayList和java.util.HashMap從根本上有問題嗎？ 對于大多數(shù)源代碼，答案是–不； 這些實現(xiàn)完全可以。 但是，一如既往，細節(jié)決定成敗。 并存在情況下，當是內(nèi)置到功能設置集合API不夠充分，或者您找到標準的集合設置成開銷太高了您的喜好。

在過去的幾年中，我們不斷地偶然發(fā)現(xiàn)同樣的問題。 并且認為分享經(jīng)驗會很好–希望它可以節(jié)省一兩天的時間。 通過避免另一種雙向Map實現(xiàn)或理解為什么他的HashSet消耗的內(nèi)存比預期多10倍來實現(xiàn)。

我們已將評論分為兩個不同的集合庫組。 首先，它們?yōu)闃藴蔆ollections API提供了其他功能。 在這個小組中，我們有Guava和Apache Commons Collections這樣的玩家。 另一組Collection庫可以在某些方面發(fā)揮作用。 在這個小組中，我們看到諸如Trove，fastutil和Huge Collections之類的庫。 我們從添加功能的庫開始概述，然后進入面向性能的環(huán)境。

集合API

每個Java開發(fā)人員都應該熟悉的真正基本的API之一。 但是，至少每個月一次，我們會碰到一個真正有創(chuàng)造力或者只是不愿意熟悉Collections API的人編寫的代碼。

因此，如果當ArrayList更合適或者不了解TreeSet和TreeMap之間的區(qū)別時，您的任何一個同事也正在使用Vector，那么Janeve George就整個API進行了很好的概述 ，并解釋了何時使用哪種類型的Collections。 。

引用我們今天所知道的Collections API的起源也很好。 Collections API中可用的大多數(shù)抽象，結(jié)構(gòu)和功能最初是由Doug Lea在其collections包中設計的。

番石榴

Guava （以前稱為Google館藏）是一組在多個Google產(chǎn)品中使用的庫。 該庫的重要部分專用于館藏。 例如，在需要時，您應該查看番石榴：

• 100％線程安全的集合–簽出ImmutableCollections
• 輕松計算集合中特定元素的出現(xiàn)次數(shù)– MultiSet和SortedMultiSet可以節(jié)省您的一天。
• 想要實現(xiàn)未標記的有向圖？ Multimap是您最好的朋友。
• 是否需要實現(xiàn)一個鍵和值都唯一且都應可用作搜索值的鍵的映射？ 番石榴的雙向地圖將幫助您。

…還有更多有趣且有用的實現(xiàn)，您可以從項目的主頁中檢出。

Apache Commons集合

Commons Collections由多個Apache項目使用，如果您需要其他功能，例如Commons Collections，它是一個不錯的附加組件：

• FIFO / LIFO實現(xiàn)–查看“ 隊列和緩沖區(qū)” 。
• 一個集合可以保留同一元素的多個副本？ 將它們放入袋中 實施。
• 一個Map，其中的元素按特定順序排列，但未根據(jù)鍵的compareTo（）進行排序-解決方案以OrderedMap的形式提供。

為了使本文的字符數(shù)保持在30,000個以內(nèi)，我將不介紹所有優(yōu)點，但我可以驗證Apache Commons Collections項目中還有很多不錯的實用程序和工具。

寶藏

如果您保存在集合中的都是數(shù)字，那么Trove可能會幫助您提高性能并減少內(nèi)存開銷。 Trove是一組收集類，專門用于保存原語。 如果您還記得的話，與使用對象包裝的對象相比，消耗的內(nèi)存要少得多。

快速測試表明，在較大的collection上，Trove實現(xiàn)所需的堆至少比標準Java Collection實現(xiàn)少三倍。 如果您認為這是無關緊要的開銷，那么在32位計算機上，包含100,000個整數(shù)的Map使用java.util.HashMap需要6.3MB的堆，而使用Trove則需要1.8MB的堆。 現(xiàn)在，從包含數(shù)以千萬計的元素的集合來看，已經(jīng)開始有意義。

與Trove相當?shù)臇|西，即Apache Commons Primitives和Java的Primitive Collections似乎都被放棄了。 兩種情況下的最新版本均始于2003年。

大量收藏

如果您要消除的痛點與舊版本中的大型集合導致的長時間GC暫停有關，則應查看Huge Collections 。 它們完全將內(nèi)容保留在堆外，因此幾乎完全不影響垃圾收集。 從下面的數(shù)據(jù)集可視化中您可以親眼看到，作者正在發(fā)布用在GC上的數(shù)字，這些數(shù)字在數(shù)據(jù)結(jié)構(gòu)上具有不同的大小：

高度可擴展的Java

需要鎖定不重要的解決方案嗎？ 是否需要在具有數(shù)十個或數(shù)百個內(nèi)核的環(huán)境中使用數(shù)據(jù)結(jié)構(gòu)？ 然后為您創(chuàng)建了高度可擴展的Java 。 感謝Cliff Click對此。

fastutil

需要工作與超過2 ^ 31個元素真正的大集合？ 查看fastutil –它為您提供了與那些野獸一起工作的數(shù)據(jù)結(jié)構(gòu)。 從歷史上看，這個問題并不是什么大問題。 為什么-因為我們沒有這么大的數(shù)據(jù)結(jié)構(gòu)。 而且在極少數(shù)情況下，我們確實有這種大小的結(jié)構(gòu)，在API本身施加2 ^ 31的限制之前，我們會遇到RAM限制。 因此，在那種情況下，我們創(chuàng)建了一個包含100萬個百萬元素的單一集合，而我們切換到了分區(qū)。

其他

無論如何，本節(jié)最后的圖書館比（引起關注）的圖書館更糟糕。 只是這些是我們沒有機會在實踐中嘗試的Collections。 至少直到本文發(fā)表為止。 但是，由于我們的讀者，我們得到了一些提示，并在1月9 ^日的已發(fā)表文章中添加了該部分：

Javolution –使用Javolution集合的主要原因是它們具有時間確定性（最大執(zhí)行時間非常接近最小執(zhí)行時間），并且它們是RTSJ-Safe。 因此，如果您要編寫硬性或軟性實時應用程序，并且必須處理執(zhí)行期限和CPU時間預算，那么請進行檢查 。

高盛收藏 。 您可能喜歡或可能不喜歡投資銀行業(yè)務，但是GS Collections背后的概念肯定很有趣。 該庫為常用操作添加了許多便利方法，否則需要您編寫Iterators和匿名類。 還聲稱GS集合還消耗更少的CPU周期和堆。 自2005年以來的圖書館顯然已經(jīng)使用了高盛的內(nèi)部應用程序和我們渴望通過嘗試一下自己 。 圖書館還隨附了GS Collections Kata項目中包裝好的實用培訓材料。

摘要

正如我們文章中經(jīng)常發(fā)生的那樣，在您手頭的95％的問題中，此處介紹的庫除了使您的設置復雜之外，不會添加任何其他內(nèi)容。 但是在極少數(shù)情況下，您需要其他功能或需要擠出最后一點性能時–熟悉環(huán)境是一件好事。 在自己編寫半熟的解決方案之前，請做出明智的選擇。

完全免責聲明：在熟悉所有上述解決方案之后，由于與性能相關的各種原因，我們?nèi)匀蛔罱K構(gòu)建了自己的解決方案。 但是，通常情況下，您并沒有像–javaagent那樣跟蹤所有對象的創(chuàng)建和銷毀，因此性能受到限制，并且可能會增加一些開銷。 在這種情況下，您可以嘗試現(xiàn)有的解決方案，而不是從頭開始構(gòu)建自己的解決方案，從而可能會更好。

參考：在Plumbr博客博客中，從我們的JCG合作伙伴 Vladimir Sor 選擇您的收藏庫 。

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

收藏表數(shù)據(jù)庫

總結(jié)

以上是生活随笔為你收集整理的收藏表数据库_选择您的收藏库的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。