SortedMap and TreeMap

Public Methods
abstract Comparator<? super K>	comparator() Returns the comparator used to compare keys in this sorted map. Returns the comparator associated with this ordered map, and null if the natural order of keys is used.
abstract K	firstKey() Returns the first key in this sorted map. Returns the current first (smallest) key in the ordered map.
abstract SortedMap<K, V>	headMap(K endKey) Returns a sorted map over a range of this sorted map with all keys that are less than the specified  endKey. Returns some elements of this ordered map, whose key value should be less than toKey.
abstract K	lastKey() Returns the last key in this sorted map. Returns the current last (maximum) key in the ordered map.
abstract SortedMap<K, V>	subMap(K startKey, K endKey) Returns a sorted map over a range of this sorted map with all keys greater than or equal to the specified  startKey and less than the specified  endKey. Returns a partial view of this ordered map with key values ​​ranging from fromKey (including) to toKey (excluding).
abstract SortedMap<K, V>	tailMap(K startKey) Returns a sorted map over a range of this sorted map with all keys that are greater than or equal to the specified  startKey. Returns a partial view of the ordered map whose key is greater than or equal to fromKey.

TreeMap(1.2)
  TreeMap yes SortedMap The red and black tree-based implementation of the interface. This class ensures that the mappings arrange keywords in ascending order, and may be sorted in the natural order of the key class according to the construction method used (see Comparable), or by the comparator provided at the time of creation.
This implementation provides guarantees for the containsKey, get, put and remove operations  log(n) Time overhead.
These algorithms are adaptations of the algorithms in Cormen, Leiserson and Rivest's "Introduction to Algorithms".
Note that if the ordered mapping is to correctly implement the Map interface, the order maintained by the ordered mapping (regardless of whether the comparator is explicitly provided) must be consistent with the equal sign.
(See the precisely defined Comparable or Comparator consistent with the equal sign.) This is also because the Map interface is defined according to the equal sign operation.
But the mapping uses its compareTo (or  compare) method to compare all keys, so from the point of view of ordered mapping,
This method believes that two equal bonds are equal. Even if the order is inconsistent with the equal sign, the behavior of ordered mapping is still well defined;
It's just that the normal agreements of the Map interface are not followed.
Note that this implementation is not synchronous. If multiple threads access a map simultaneously, and at least one of the threads structurally modify the map,
Then it must be kept externally synchronized. (Structural modification refers to the operation of adding or deleting one or more mapping relationships;
Change only the values ​​associated with existing keys are not structural modifications. ) This is generally done by synchronizing an object that naturally encapsulates the map.
If such an object does not exist, the method should be used to "wrape" the map.
It is best to do this at creation time to prevent unexpectedly out-of-sync access to the map, as shown below:
      Map m = (new TreeMap(...));
The iterators returned by all such "collection view methods" fail quickly: after the iterator is created,
If the mapping is modified from the structure, unless it is modified at any time or in any other way through the iterator's own remove or add method,
The iterators will throw a ConcurrentModificationException. Therefore, in the face of concurrent modifications, the iterator quickly fails completely.
Instead of risking arbitrarily occurring uncertain behavior at uncertain times in the future.
Note that the fast failure behavior of the iterator cannot be guaranteed, because generally speaking, it is impossible to make any hard guarantees on whether there are any out-of-synchronous concurrent modifications.
The fast-failed iterator will do its best to throw a ConcurrentModificationException.
Therefore, it is wrong to write a program that depends on this exception to improve the correctness of this type of iterator: the fast failure behavior of the iterator should be used only to detect bugs.
Note 1: This implementation is not synchronous. Not thread-safe.
Note 2: TreeMap is sorted in ascending order using keys. Sort by Comparable or Comparator.
Note 3: The iterators returned by all such "collection view methods" fail quickly.
Note 4: Like HashMap, if you insert a duplicate element, the subsequent element will overwrite the previous one.
Note 5: The key cannot be null, but the value can be null
Example 1:
import ;
import ;
import ;
import ;
import ;
public class  Test {
 /**
  * @param args
  */
  public static void   main (String[] args) {
  TreeMap<Integer,People> map=new TreeMap();
  People p1=new People("robin",1,28);
  People p2=new People("robin",2,29);
  People p3=new People("harry",3,30);
  (new Integer(100), p1);
  (new Integer(100), p2);
  (new Integer(1), p3);
  (new Integer(2), null);
  for(People p:())
  {
   (p);
  }
 }
}
class  People{
 String name;
 int id;
 int age;
  public  People(String name,int id)
 {
  this(name,id,0);
 }
  public  People(String name,int id,int age)
 {
  =name;
  =id;
  =age;
 }
  public  String toString()
 {
  return id+name+age;
 }
  public boolean  equals(Object o)
 {
  if(o==null)
   return false;
  if(!(o instanceof People))
   return false;
  People p=(People)o;
  boolean res=();
  if(res)
   ("name "+name+" is double");
  else
   (name+" vS "+);
  return res;
 }
  public int  hashCode()
 {
  return ();
 }
}
Output result:
3harry30
null
2robin29