Java中如何解析TreeMap？針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

10余年的鑲黃網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開(kāi)發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。營(yíng)銷(xiāo)型網(wǎng)站的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整鑲黃建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)從事“鑲黃網(wǎng)站設(shè)計(jì)”,“鑲黃網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

代碼如下。

/**
 * A Red-Black tree based {@link NavigableMap} implementation.
 * The map is sorted according to the {@linkplain Comparable natural
 * ordering} of its keys, or by a {@link Comparator} provided at map
 * creation time, depending on which constructor is used.
 * 
This implementation provides guaranteed log(n) time cost for the
 * {@code containsKey}, {@code get}, {@code put} and {@code remove}
 * operations. Algorithms are adaptations of those in Cormen, Leiserson, and
 * Rivest's Introduction to Algorithms.
 * 
Note that the ordering maintained by a tree map, like any sorted map, and
 * whether or not an explicit comparator is provided, must be consistent
 * with {@code equals} if this sorted map is to correctly implement the
 * {@code Map} interface. (See {@code Comparable} or {@code Comparator} for a
 * precise definition of consistent with equals.) This is so because
 * the {@code Map} interface is defined in terms of the {@code equals}
 * operation, but a sorted map performs all key comparisons using its {@code
 * compareTo} (or {@code compare}) method, so two keys that are deemed equal by
 * this method are, from the standpoint of the sorted map, equal. The behavior
 * of a sorted map is well-defined even if its ordering is
 * inconsistent with {@code equals}; it just fails to obey the general contract
 * of the {@code Map} interface.
 * 
Note that this implementation is not synchronized.
 * If multiple threads access a map concurrently, and at least one of the
 * threads modifies the map structurally, it must be synchronized
 * externally. (A structural modification is any operation that adds or
 * deletes one or more mappings; merely changing the value associated
 * with an existing key is not a structural modification.) This is
 * typically accomplished by synchronizing on some object that naturally
 * encapsulates the map.
 * If no such object exists, the map should be "wrapped" using the
 * {@link Collections#synchronizedSortedMap Collections.synchronizedSortedMap}
 * method. This is best done at creation time, to prevent accidental
 * unsynchronized access to the map: 
 *  SortedMap m = Collections.synchronizedSortedMap(new TreeMap(...));
 * 
The iterators returned by the {@code iterator} method of the collections
 * returned by all of this class's "collection view methods" are
 * fail-fast: if the map is structurally modified at any time after
 * the iterator is created, in any way except through the iterator's own
 * {@code remove} method, the iterator will throw a {@link
 * ConcurrentModificationException}. Thus, in the face of concurrent
 * modification, the iterator fails quickly and cleanly, rather than risking
 * arbitrary, non-deterministic behavior at an undetermined time in the future.
 * 
Note that the fail-fast behavior of an iterator cannot be guaranteed
 * as it is, generally speaking, impossible to make any hard guarantees in the
 * presence of unsynchronized concurrent modification. Fail-fast iterators
 * throw {@code ConcurrentModificationException} on a best-effort basis.
 * Therefore, it would be wrong to write a program that depended on this
 * exception for its correctness:  the fail-fast behavior of iterators
 * should be used only to detect bugs.
 * 
All {@code Map.Entry} pairs returned by methods in this class
 * and its views represent snapshots of mappings at the time they were
 * produced. They do not support the {@code Entry.setValue}
 * method. (Note however that it is possible to change mappings in the
 * associated map using {@code put}.)
 * 
This class is a member of the
 * 
 * Java Collections Framework.
 * @param  the type of keys maintained by this map
 * @param  the type of mapped values
 * @author Josh Bloch and Doug Lea
 * @see Map
 * @see HashMap
 * @see Hashtable
 * @see Comparable
 * @see Comparator
 * @see Collection
 * @since 1.2
 **/

這是一個(gè)基于紅黑樹(shù)的可導(dǎo)航的實(shí)現(xiàn)。這個(gè)map基于key的可比較的自然順序，或者基于在map創(chuàng)建時(shí)提供的Comparator的順序來(lái)存儲(chǔ)元素。

這個(gè)實(shí)現(xiàn)提供可保證的log(n)的時(shí)間復(fù)雜度來(lái)完成containsKey，get，put和remove操作。

需要注意到這一點(diǎn)，不管是否顯式提供了排序器，如果這個(gè)排序map想要正確實(shí)現(xiàn)Map接口，tree map維護(hù)的順序必須和equals保持一致，就像任何排序map那樣。之所以會(huì)這樣，是因?yàn)镸ap接口是根據(jù)equals操作來(lái)定義的，但是排序map進(jìn)行所有key的比較時(shí)使用的是他們的compareTo方法，所以，從排序map的觀點(diǎn)來(lái)看，被這個(gè)方法認(rèn)為相等的兩個(gè)key，才是相等的。盡管如果它的順序和equals不一致，排序map的行為也是正常的，它只是沒(méi)有遵守Map接口的通常約定。

請(qǐng)注意這個(gè)實(shí)現(xiàn)是非同步的。如果多個(gè)線程并發(fā)訪問(wèn)一個(gè)treemap，并且至少有一個(gè)線程修改結(jié)構(gòu)，必須進(jìn)行外部同步。這個(gè)通常是通過(guò)在包含這個(gè)map的對(duì)象上進(jìn)行同步來(lái)實(shí)現(xiàn)的。如果沒(méi)有這樣的對(duì)象，那么這個(gè)map需要用Collections.synchronizedSortedMap方法包裝一下。最好是在創(chuàng)建map時(shí)就這樣做，以防止意外非同步訪問(wèn)這個(gè)map。代碼如下SortedMap m = Collections.synchronizedSortedMap(new TreeMap(...));

所有這個(gè)類(lèi)的集合視角方法返回的集合的iterator方法返回的迭代器都是fast-fail的：如果迭代器創(chuàng)建后的任何時(shí)間map發(fā)生了結(jié)構(gòu)性改變，除了通過(guò)迭代器的刪除方法外，迭代器都會(huì)拋出同步修改異常。于是，面對(duì)同步修改時(shí)，迭代器會(huì)迅速干凈的失敗，而不是冒著在未來(lái)的不確定的時(shí)間發(fā)生不一致或無(wú)法確定的行為的風(fēng)險(xiǎn)。

這個(gè)類(lèi)和它的視圖的方法返回的Map.Entry對(duì)代表了他們被創(chuàng)建時(shí)的快照。他們不支持Entry.setValue方法。

這個(gè)類(lèi)是Java集合框架的一個(gè)成員。

關(guān)于Java中如何解析TreeMap問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。