Java中如何解析TreeMap

Java中如何解析TreeMap？針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

代碼如下。

/**
 * 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.
 * <p>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 <em>Introduction to Algorithms</em>.
 * <p>Note that the ordering maintained by a tree map, like any sorted map, and
 * whether or not an explicit comparator is provided, must be <em>consistent
 * with {@code equals}</em> if this sorted map is to correctly implement the
 * {@code Map} interface. (See {@code Comparable} or {@code Comparator} for a
 * precise definition of <em>consistent with equals</em>.) 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 <em>is</em> well-defined even if its ordering is
 * inconsistent with {@code equals}; it just fails to obey the general contract
 * of the {@code Map} interface.
 * <p><strong>Note that this implementation is not synchronized.</strong>
 * If multiple threads access a map concurrently, and at least one of the
 * threads modifies the map structurally, it <em>must</em> 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: <pre>
 *  SortedMap m = Collections.synchronizedSortedMap(new TreeMap(...));</pre>
 * <p>The iterators returned by the {@code iterator} method of the collections
 * returned by all of this class's "collection view methods" are
 * <em>fail-fast</em>: 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.
 * <p>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:  <em>the fail-fast behavior of iterators
 * should be used only to detect bugs.</em>
 * <p>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 <strong>not</strong> support the {@code Entry.setValue}
 * method. (Note however that it is possible to change mappings in the
 * associated map using {@code put}.)
 * <p>This class is a member of the
 * <a href="{@docRoot}/../technotes/guides/collections/index.html" rel="external nofollow" >
 * Java Collections Framework</a>.
 * @param <K> the type of keys maintained by this map
 * @param <V> 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
 **/

這是一個基于紅黑樹的可導航的實現。這個map基于key的可比較的自然順序，或者基于在map創建時提供的Comparator的順序來存儲元素。

這個實現提供可保證的log(n)的時間復雜度來完成containsKey，get，put和remove操作。

需要注意到這一點，不管是否顯式提供了排序器，如果這個排序map想要正確實現Map接口，tree map維護的順序必須和equals保持一致，就像任何排序map那樣。之所以會這樣，是因為Map接口是根據equals操作來定義的，但是排序map進行所有key的比較時使用的是他們的compareTo方法，所以，從排序map的觀點來看，被這個方法認為相等的兩個key，才是相等的。盡管如果它的順序和equals不一致，排序map的行為也是正常的，它只是沒有遵守Map接口的通常約定。

請注意這個實現是非同步的。如果多個線程并發訪問一個treemap，并且至少有一個線程修改結構，必須進行外部同步。這個通常是通過在包含這個map的對象上進行同步來實現的。如果沒有這樣的對象，那么這個map需要用Collections.synchronizedSortedMap方法包裝一下。最好是在創建map時就這樣做，以防止意外非同步訪問這個map。代碼如下SortedMap m = Collections.synchronizedSortedMap(new TreeMap(...));

所有這個類的集合視角方法返回的集合的iterator方法返回的迭代器都是fast-fail的：如果迭代器創建后的任何時間map發生了結構性改變，除了通過迭代器的刪除方法外，迭代器都會拋出同步修改異常。于是，面對同步修改時，迭代器會迅速干凈的失敗，而不是冒著在未來的不確定的時間發生不一致或無法確定的行為的風險。

這個類和它的視圖的方法返回的Map.Entry對代表了他們被創建時的快照。他們不支持Entry.setValue方法。

這個類是Java集合框架的一個成員。

關于Java中如何解析TreeMap問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。