HashMap类   
  　　HashMap和Hashtable类似，不同之处在于HashMap是非同步的，并且允许null，即null   value和null   key。，但是将HashMap视为Collection时（values()方法可返回Collection），其迭代子操作时间开销和HashMap的容量成比例。因此，如果迭代操作的性能相当重要的话，不要将HashMap的初始化容量设得过高，或者load   factor过低。   
   
  WeakHashMap类   
  　　WeakHashMap是一种改进的HashMap，它对key实行“弱引用”，如果一个key不再被外部所引用，那么该key可以被GC回收。



HashSet请参考对Set的描述   
   
          Set是一种不包含重复的元素的Collection，即任意的两个元素e1和e2都有e1.equals(e2)=false，Set最多有一个null元素。   
  　　Set的构造函数有一个约束条件，传入的Collection参数不能包含重复的元素。　　请注意：必须小心操作可变对象（Mutable   Object）。如果一个Set中的可变元素改变了自身状态导致Object.equals(Object)=true将导致一些问题。
两个通用Set实现是HashSet   和TreeSet。要决定用哪一个，那是非常简单明了的。   HashSet   要快得多   (对大多数操作是常数时间之于对数时间（constant   time   vs.   log   time）),   但不提供排序保证。如果你需要使用   SortedSet   中的操作，或者按顺序迭代对你来说是重要的，那么请使用   TreeSet。   否则，使用   HashSet。   在大多数时间都不使用   HashSet   ，对你来说是个公平的赌博。     
   
  　　关于   HashSet，有一件事应该牢记，即就条目数和容量之和来讲，迭代是线性的。因此，如果迭代性能很重要，那就应该慎重选择一个适当的初始容量。容量选得太大，既浪费空间，也浪费时间。   默认的初试容量是101,   一般来讲，它比你所需要的要多。可以使用   int   构造函数来指定初始容量。要分配   HashSet   的初始容量为17:     
   
  Set   s=   new   HashSet(17);     
   
  　　HashSets   另有一个称作   装载因数（load   factor）   的"调整参数（tuning   parameter）"   。如果你非常在乎你的   HashSet   的空间的使用，请阅读   HashSet   文本以获取详细信息。否则，就使用默认值吧。如果你接受默认装载因数，但你确实又想指定初始容量，那么，选一个大约是你期望你的   Set   将增长到的容量的两倍的数。如果你的猜测不着边，它也可以增长，或只是浪费一点空间。但都没有大问题。如果你知道有关正确尺寸的一个最佳值，用它吧；如果不知道，那就使用一个旧的值，或使用一个偶数值。它真的不是非常重要。这些事情只能使   HashSet   稍稍变好一点点。     

HASHSET：
        此类实现   Set   接口，由哈希表（实际上是一个   HashMap   实例）支持。它不保证集合的迭代顺序；特别是它不保证该顺序恒久不变。此类允许使用   null   元素。
        此类为基本操作提供了稳定性能，这些基本操作包括   add、remove、contains   和   size，假定哈希函数将这些元素正确地分布在桶中。对此集合进行迭代所需的时间与   HashSet   实例的大小（元素的数量）和底层   HashMap   实例（桶的数量）的“容量”的和成比例。因此，如果迭代性能很重要，则不要将初始容量设置得太高（或将加载因子设置得太低）。
        注意，此实现不是同步的。   如果多个线程同时访问一个集合，而其中至少一个线程修改了该集合，那么它必须   保持外部同步。这通常是通过对自然封装该集合的对象执行同步操作来完成的。如果不存在这样的对象，则应该使用   Collections.synchronizedSet   方法来“包装”集合。最好在创建时完成这一操作，以防止对   HashSet   实例进行意外的不同步访问：   
                    Set   s   =   Collections.synchronizedSet(new   HashSet(...));
        此类的   iterator   方法返回的迭代器是快速失败   的：在创建迭代器之后，如果对集合进行修改，除非通过迭代器自身的   remove   方法，否则在任何时间以任何方式对其进行修改，Iterator   都将抛出   ConcurrentModificationException。因此，面对并发的修改，迭代器很快就会完全失败，而不冒将来在某个不确定时间发生任意不确定行为的风险。   
        注意，迭代器的快速失败行为无法得到保证，因为一般来说，不可能对是否出现不同步并发修改做出任何硬性保证。快速失败迭代器在尽最大努力抛出   ConcurrentModificationException。因此，为提高这类迭代器的正确性而编写一个依赖于此异常的程序是错误做法：迭代器的快速失败行为应该仅用于检测程序错误。

HASHMAP：
        基于哈希表的   Map   接口的实现。此实现提供所有可选的映射操作，并允许使用   null   值和   null   键。（除了不同步和允许使用   null   之外，HashMap   类与   Hashtable   大致相同。）此类不保证映射的顺序，特别是它不保证该顺序恒久不变。   
        此实现假定哈希函数将元素正确分布在各桶之间，可为基本操作（get   和   put）提供稳定的性能。迭代集合视图所需的时间与   HashMap   实例的“容量”（桶的数量）及其大小（键-值映射关系数）的和成比例。所以，如果迭代性能很重要，则不要将初始容量设置得太高（或将加载因子设置得太低）。   
        HashMap   的实例有两个参数影响其性能：初始容量   和加载因子。容量   是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。加载因子   是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时，通过调用   rehash   方法将容量翻倍。   
        通常，默认加载因子   (.75)   在时间和空间成本上寻求一种折衷。加载因子过高虽然减少了空间开销，但同时也增加了查询成本（在大多数   HashMap   类的操作中，包括   get   和   put   操作，都反映了这一点）。在设置初始容量时应该考虑到映射中所需的条目数及其加载因子，以便最大限度地降低   rehash   操作次数。如果初始容量大于最大条目数除以加载因子，则不会发生   rehash   操作。   
        如果很多映射关系要存储在   HashMap   实例中，则相对于按需执行自动的   rehash   操作以增大表的容量来说，使用足够大的初始容量创建它将使得映射关系能更有效地存储。   
        注意，此实现不是同步的。如果多个线程同时访问此映射，而其中至少一个线程从结构上修改了该映射，则它必须   保持外部同步。（结构上的修改是指添加或删除一个或多个映射关系的操作；仅改变与实例已经包含的键关联的值不是结构上的修改。）这一般通过对自然封装该映射的对象进行同步操作来完成。如果不存在这样的对象，则应该使用   Collections.synchronizedMap   方法来“包装”该映射。最好在创建时完成这一操作，以防止对映射进行意外的不同步访问，如下所示：
            Map   m   =   Collections.synchronizedMap(new   HashMap(...));
        由所有此类的“集合视图方法”所返回的迭代器都是快速失败   的：在迭代器创建之后，如果从结构上对映射进行修改，除非通过迭代器自身的   remove   或   add   方法，其他任何时间任何方式的修改，迭代器都将抛出   ConcurrentModificationException。因此，面对并发的修改，迭代器很快就会完全失败，而不冒在将来不确定的时间任意发生不确定行为的风险。   
        注意，迭代器的快速失败行为不能得到保证，一般来说，存在不同步的并发修改时，不可能作出任何坚决的保证。快速失败迭代器尽最大努力抛出   ConcurrentModificationException。因此，编写依赖于此异常程序的方式是错误的，正确做法是：迭代器的快速失败行为应该仅用于检测程序错误。

此段摘自网络....