jdk7默認gc算法

在定期檢查JDK中是否存在一種或另一種標準算法時，我決定進行這種索引。 有趣的是，為什么其中包含一些著名的數據結構或算法，而其他卻沒有？ 此調查的格式僅涉及JDK的算法和數據結構的關鍵特性和功能，所有詳細信息和完整描述-您可以在javadoc或jdk源代碼中輕松找到。 讓我們從簡單開始到復雜！

JDK的數據結構

疊放

jdk中有一個堆棧 ，它是從堆棧中出現的-類Stack ，但不建議使用它，它很復雜又很奇怪：它繼承自Vector ，因此基于Dynamic Array并已同步。 為什么一個簡單的棧需要這一切，為什么它不只是一個接口-目前尚不清楚（討論過很多次： 1 ， 2 ），但似乎只是一個架構的錯誤，同樣與載體本身。 順便說一句，JDK作者自己建議使用Deque代替。

Deque – 雙端隊列的接口（api）（O中的LIFO + FIFO（1）），其中包括堆棧操作（push，pop，isEmpty，size），并且到目前為止在jdk中可用（1.6+） 。 當然，將這些堆棧操作放在接口Stack中是更合乎邏輯的，例如讓Deque繼承它，但是由于Stack已經存在，并且向后兼容性是Java的“圣杯” –他們必須犧牲常規設計。 Deque的實現是ArrayDeque和LinkedList ，它們也是常規隊列的實現者–因此我們將在后面討論。

隊列

接下來，讓我們看一下隊列數據類型 。 這里的一切都很好，設計得很好。 隊列 – FIFO隊列的接口（api），以恒定時間O（1）添加到開頭并從結尾刪除。

主要實現有： ArrayDeque ，基于動態可擴展數組的循環緩沖區 （填充時加倍）和LinkedList （ 經典的雙向鏈接列表） （大小不受限制）。 令人驚訝的是，第一個不支持隨機訪問 （使用索引添加/刪除/獲取），第二個卻支持O（n）時間，并通過鏈表進行迭代。 這些類還實現了上面提到的Deque，因此它們支持從末尾移除并在固定時間內添加到頂部。

接下來，從jdk 1.5+開始，添加了PriorityQueue ，這實際上違反了約定，因為隊列元素不是從結尾檢索的（并且也不添加到頭部），而是根據它們的優先級檢索的。 PriorityQueue基于可擴展的二進制堆 ，其頂部最小（根據其比較器），并且在填充時提高了1.5倍。 關鍵特征分別是：元素的添加/刪除在O（log N）中，而對最小值（head）的引用在O（1）中。

其他類型的隊列專為多線程使用而設計，它們是： BlockingQueue ， TransferQueue ， ConcurrentLinkedQueue和ConcurrentLinkedDeque 。

BlockingQueue （ ArrayBlockingQueue ， LinkedBlockingQueue ， PriorityBlockingQueue ）的實現是其原始版本的一種同步版本，即幾乎每個操作都是串行執行的（具有獨占鎖定）。 對于DelayQueue也是如此：也是同步的，并且在內部使用PriorityQueue 。

其他實現： SynchronousQueue ， TransferQueue （ LinkedTransferQueue ）， ConcurrentLinkedQueue ， ConcurrentLinkedDeque –基于不同的方法：它們使用基于鏈表和CAS指令的非阻塞隊列算法，這些算法在多處理器環境中可以很好地并行化。 詳細描述在源代碼中。

此類算法的理論是一個非常龐大且現代的主題，因此尚未很好地標準化和結構化，它們不在本文的討論范圍之內。

優先隊列

就像從jdk 1.5+開始所說的那樣，有一個通用的PriorityQueue根據元素比較器工作。 而且，jdk中還有堆的另一種實現。 這是很好的舊Timer ，它是內部類– TaskQueue（頂部的延遲最小的任務）。 當然，這是一個私有類，除了在Timer內部，不能使用。

清單

如您所知，有順序和/或隨機訪問類型列表。 在Java中，它是List ，主要有2種實現：首先-是ArrayList ，支持隨機訪問 ，基于動態可擴展數組 （填充時增加一半），但是在刪除所有元素后不會縮小，您需要調用a特殊方法（ trimToSize ）。

第二個-再次是LinkedList，它是一個雙鏈表順序訪問大小，僅受jvm的內存限制。 盡管也存在隨機訪問（索引）的方法–如前所述，它們需要O（n）時間。

因此，java集合中沒有最簡單的鏈表實現，盡管這是一個好主意（鏈接的開銷減少了2倍），并且沒有簡單的堆棧。

要在多線程環境中使用列表，有幾個選項： CopyOnWriteArrayList （更改操作– O（n）），包裝器（ synchonizedList ）以及過時的Vector 。

符號表

它們在JDK中顯示為二進制樹和哈希表。 二叉樹 –它是TreeMap （或TreeSet ）， SortedMap （也是SortedSet）的實現，它基于經典的紅黑樹 ，即是平衡的，并且對于O（log N）保證了其基本操作，并且不限大小。 jdk中不存在其他類型的樹。

哈希表是HashMap （也是HashSet ），它可能是Java中最常用的結構，它基于可動態擴展的哈希表，該哈希表與鏈表分別鏈接 ，具有所有功能：性能取決于哈希函數的質量，因此最壞的情況是O（N）。 當大小達到預定的loadFactor時， HashMap的大小將增加一倍。 值得注意的是，為了保護壞的哈希函數，使用了雙哈希，并且對hashCode（）的調用結果采用了棘手的位算法。

JDK中也有帶有開放地址（線性探測）的哈希表實現。 其中之一是IdentityHashMap ，當鍵和值都存儲在彼此相鄰的同一數組中時，它會使用經典線性探測的優化版本，以實現更好的數據緩存（javadoc：?大型表的局部性比使用單獨的數組?）

第二種開放尋址實現是非常特定的：它僅用于存儲ThreadLocal元素（ ThreadLocalMap中的內部隱藏類），當然不可用。

還有多線程版本： ConcurrentHashMap中 ，包裝synchronizedMap ， 哈希表和ConcurrentSkipListMap 。 包裝器-自然只是阻止了常規HashMap Hashtable的版本-同一件事（它是舊有的，不建議使用）， ConcurrentHashMap-鎖條版本，減少了關鍵的鎖部分（最好閱讀JCiP ，這里是（ 摘錄 ） ConcurrentSkipListMap –是哈希表的非阻塞命名算法的改編版（有關詳細信息，請參見源代碼）。

集合（不包含重復項）-它是用Java 設置的，并且通過HashMap實現，因此所有被稱為哈希表的對象-對HashSet有效。

圖表

圖結構和算法未在jdk中表示。 因此，您只能為此使用第三方庫。

弦樂

java中通常有一個字符串實現：基于unicode字符數組。 值得一提的是，從1.7_17版本開始–子字符串的性能為O（n），因為已復制了子字符串。

有趣的是， 此實現使用了一種簡單的（強力）子字符串搜索算法，該算法在最壞的情況下以O（N * M）運行，并且沒有一些有效的算法（在有限狀態機上構建：Knuth-Morris-Pratt等） 。

原因有以下幾種：字母UTF字符大（?65K），因此存儲狀態機的開銷很大，而暴力破解算法就位（不使用額外的內存）。 其次，在平均輸入字符串上–該算法在統計上與其他算法相比并沒有很多。

與排序相同：存在有效的基數排序字符串algs（LSD，MSD等），但在jdk中，有一個用于字符串的標準對象排序 ，如果運行，則以O（M * N * log N）運行大部分線相差不大（M –線長）。 原因是相同的：快速計數字符串算法需要額外的UTF字母大小的數組，這使得它們在平均輸入上非常無效。

JDK算法

排序

由于jdk7發生了許多有關各種選項的更改，因此討論了很多次，關于此主題的信息和文章很多，您可以輕松地搜索它。

簡而言之，這是jdk中排序實現的實際列表： TimSort –默認情況下對對象進行排序； mergesort –還用于對象；舊版本（通過系統屬性啟用）； Dual-Pivot Quick sort –用于基元；然后按計數排序用于字節/字符數組，最后插入排序用于任何情況下使用的小數組。

集合內容使用Collections.sort（List…）進行排序，仍然可以通過將集合復制到數組中，對其進行排序，然后相應地覆蓋集合內容來完成。 因此，盡管沒有開銷，對集合進行排序仍然是不可能的，盡管我認為擁有就地排序的鏈表是一個好主意。 Java中的字符串排序也使用對象版本完成，原因已經提到。

正在搜尋

對于原語和對象的所有數組以及隨機訪問列表實現（例如ArrayList等），都存在傳統的二進制搜索 。 此外，JDK中還有一個二進制搜索鏈接列表的版本！ 令人驚訝的是：JDK沒有對鏈表進行排序，但是對它們進行二進制搜索！ 盡管沒有太大意義，因為這種版本的性能為O（N）。

常用表達

為此提供了Pattern和Matcher類。 Java使用基于帶回溯的非確定性有限狀態機（ NFA ）的傳統實現。 因此，在退化的輸入上，在最壞的情況下它給出了指數復雜度 O（m ^ N），例如，在Java中運行此regexp并嘗試添加/刪除“ a”符號：“ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.aa ）* b”）

另外，還有所謂的有序交替-此功能可在找到第一個匹配項后停止搜索，但不會顯示最具體（最長）的搜索結果（ 例如 ）。

哈希函數，校驗和

jdk中有hashCode實現的六個版本，并且Park-Miller_random_number_generator是默認版本，其他很簡單，例如常量或對象內存地址，并且不使用算法，可以在c ++ jdk源代碼中找到它們。 MessageDigest類中還有行業標準的哈希算法（SHA-*，MD5和變體）。

對于校驗和，有Adler-32 （ javadoc ）和CRC32 （ javadoc ）算法的實現。

壓縮

jdk中有一個標準的壓縮deflate（ Deflater ）算法的實現，并且zip / gzip jdk utils使用它。 它們都在java.util.zip包中 。

摘要

如您所見，經典數據結構并未完全用Java呈現，但與此同時，幾乎所有jdk中的所有數據結構都可以使用很多線程安全版本。 缺少的是一個懸而未決的問題。 例如，您可以爭論jdk是否需要一些Union-Find，但是在社交網絡時代完全缺少該語言的圖形結構和算法會非常令人驚訝，并且實際上會產生很多錯誤和問題。

參考：來自我們的JCG合作伙伴 Mikhail Baturov 的JDK 7的算法和數據結構，這是另一個俄羅斯編程人員.blog博客。

翻譯自: https://www.javacodegeeks.com/2013/07/algorithms-and-data-structures-of-jdk-7.html

jdk7默認gc算法

總結

以上是生活随笔為你收集整理的jdk7默认gc算法_JDK 7的算法和数据结构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。