Java中如何解析TreeMap

Java中如何解析TreeMap？针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

10余年的镶黄网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。营销型网站的优势是能够根据用户设备显示端的尺寸不同，自动调整镶黄建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。成都创新互联从事“镶黄网站设计”,“镶黄网站推广”以来，每个客户项目都认真落实执行。

代码如下。

/**
 * 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
 **/

这是一个基于红黑树的可导航的实现。这个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问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。