下列java对象是何意思？ hashTable ArrayListCollectionCollectionsComparatorList请问谁有java中文参考啊！ 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 嗯，容器，插入删除比数组方便多了，可以直接定位的你自己搜下java api去下载 摘自中文APIHashTable此类实现一个哈希表，该哈希表将键映射到相应的值。任何非 null 对象都可以用作键或值。为了成功地在哈希表中存储和获取对象，用作键的对象必须实现 hashCode 方法和 equals 方法。Hashtable 的实例有两个参数影响其性能：初始容量 和加载因子。容量 是哈希表中桶 的数量，初始容量 就是哈希表创建时的容量。注意，哈希表的状态为 open：在发生“哈希冲突”的情况下，单个桶会存储多个条目，这些条目必须按顺序搜索。加载因子 是对哈希表在其容量自动增加之前可以达到多满的一个尺度。初始容量和加载因子这两个参数只是对该实现的提示。关于何时以及是否调用 rehash 方法的具体细节则依赖于该实现。通常，默认加载因子(.75)在时间和空间成本上寻求一种折衷。加载因子过高虽然减少了空间开销，但同时也增加了查找某个条目的时间（在大多数 Hashtable 操作中，包括 get 和 put 操作，都反映了这一点）。初始容量主要控制空间消耗与执行 rehash 操作所需要的时间损耗之间的平衡。如果初始容量大于 Hashtable 所包含的最大条目数除以加载因子，则永远 不会发生 rehash 操作。但是，将初始容量设置太高可能会浪费空间。如果很多条目要存储在一个 Hashtable 中，那么与根据需要执行自动 rehashing 操作来增大表的容量的做法相比，使用足够大的初始容量创建哈希表或许可以更有效地插入条目。下面这个示例创建了一个数字的哈希表。它将数字的名称用作键： Hashtable<String, Integer> numbers = new Hashtable<String, Integer>(); numbers.put("one", 1); numbers.put("two", 2); numbers.put("three", 3);要获取一个数字，可以使用以下代码： Integer n = numbers.get("two"); if (n != null) { System.out.println("two = " + n); } }由所有类的“collection 视图方法”返回的 collection 的 iterator 方法返回的迭代器都是快速失败 的：在创建 Iterator 之后，如果从结构上对 Hashtable 进行修改，除非通过 Iterator 自身的 remove 方法，否则在任何时间以任何方式对其进行修改，Iterator 都将抛出ConcurrentModificationException。因此，面对并发的修改，Iterator 很快就会完全失败，而不冒在将来某个不确定的时间发生任意不确定行为的风险。由 Hashtable 的键和元素方法返回的 Enumeration 不 是快速失败的。 注意，迭代器的快速失败行为无法得到保证，因为一般来说，不可能对是否出现不同步并发修改做出任何硬性保证。快速失败迭代器会尽最大努力抛出 ConcurrentModificationException。因此，为提高这类迭代器的正确性而编写一个依赖于此异常的程序是错误做法：迭代器的快速失败行为应该仅用于检测程序错误。 从Java 2 平台 v1.2起，此类就被改进以实现 Map 接口，使它成为 Java Collections Framework 中的一个成员。不像新的 collection 实现，Hashtable 是同步的ArrayList List 接口的大小可变数组的实现。实现了所有可选列表操作，并允许包括 null 在内的所有元素。除了实现 List 接口外，此类还提供一些方法来操作内部用来存储列表的数组的大小。（此类大致上等同于 Vector 类，除了此类是不同步的。）size、isEmpty、get、set、iterator 和 listIterator 操作都以固定时间运行。add 操作以分摊的固定时间 运行，也就是说，添加 n 个元素需要 O(n) 时间。其他所有操作都以线性时间运行（大体上讲）。与用于 LinkedList 实现的常数因子相比，此实现的常数因子较低。每个 ArrayList 实例都有一个容量。该容量是指用来存储列表元素的数组的大小。它总是至少等于列表的大小。随着向 ArrayList 中不断添加元素，其容量也自动增长。并未指定增长策略的细节，因为这不只是添加元素会带来分摊固定时间开销那样简单。在添加大量元素前，应用程序可以使用 ensureCapacity 操作来增加 ArrayList 实例的容量。这可以减少递增式再分配的数量。注意，此实现不是同步的。如果多个线程同时访问一个 ArrayList 实例，而其中至少一个线程从结构上修改了列表，那么它必须 保持外部同步。（结构上的修改是指任何添加或删除一个或多个元素的操作，或者显式调整底层数组的大小；仅仅设置元素的值不是结构上的修改。）这一般通过对自然封装该列表的对象进行同步操作来完成。如果不存在这样的对象，则应该使用 Collections.synchronizedList 方法将该列表“包装”起来。这最好在创建时完成，以防止意外对列表进行不同步的访问： List list = Collections.synchronizedList(new ArrayList(...)); 此类的 iterator 和 listIterator 方法返回的迭代器是快速失败的：在创建迭代器之后，除非通过迭代器自身的 remove 或 add 方法从结构上对列表进行修改，否则在任何时间以任何方式对列表进行修改，迭代器都会抛出 ConcurrentModificationException。因此，面对并发的修改，迭代器很快就会完全失败，而不是冒着在将来某个不确定时间发生任意不确定行为的风险。注意，迭代器的快速失败行为无法得到保证，因为一般来说，不可能对是否出现不同步并发修改做出任何硬性保证。快速失败迭代器会尽最大努力抛出 ConcurrentModificationException。因此，为提高这类迭代器的正确性而编写一个依赖于此异常的程序是错误的做法：迭代器的快速失败行为应该仅用于检测 bugCollectioncollection，并在需要最大普遍性的地方操作这些 collection。 包 (bag) 或多集合 (multiset)（可能包含重复元素的无序 collection）应该直接实现此接口。 所有通用的 Collection 实现类（通常通过它的一个子接口间接实现 Collection）应该提供两个“标准”构造方法：一个是 void（无参数）构造方法，用于创建空 collection；另一个是带有 Collection 类型单参数的构造方法，用于创建一个具有与其参数相同元素新的 collection。实际上，后者允许用户复制任何 collection，以生成所需实现类型的一个等效 collection。尽管无法强制执行此约定（因为接口不能包含构造方法），但是 Java 平台库中所有通用的 Collection 实现都遵从它。 此接口中包含的“破坏性”方法，是指可修改其所操作的 collection 的那些方法，如果此 collection 不支持该操作，则指定这些方法抛出 UnsupportedOperationException。如果是这样，那么在调用对该 collection 无效时，这些方法可能，但并不一定抛出 UnsupportedOperationException。例如，如果要添加的 collection 为空且不可修改，则对该 collection 调用 addAll(Collection) 方法时，可能但并不一定抛出异常。 一些 collection 实现对它们可能包含的元素有所限制。例如，某些实现禁止 null 元素，而某些实现则对元素的类型有限制。试图添加不合格的元素将抛出一个未经检查的异常，通常是 NullPointerException 或 ClassCastException。试图查询是否存在不合格的元素可能抛出一个异常，或者只是简单地返回 false；某些实现将表现出前一种行为，而某些实现则表现后一种。较为常见的是，试图对某个不合格的元素执行操作且该操作的完成不会导致将不合格的元素插入 collection 中，将可能抛出一个异常，也可能操作成功，这取决于实现本身。这样的异常在此接口的规范中标记为“可选”。 由每个 collection 来确定其自身的同步策略。在没有实现的强烈保证的情况下，调用由另一进程正在更改的 collection 的方法可能会出现不确定行为；这包括直接调用，将 collection 传递给可能执行调用的方法，以及使用现有迭代器检查 collection。 Collections Framework 接口中的很多方法是根据 equals 方法定义的。例如，contains(Object o) 方法的规范声明：“当且仅当此 collection 包含至少一个满足 (o==null ? e==null :o.equals(e)) 的元素 e 时，返回 true。”不 应将此规范理解为它暗指调用具有非空参数 o 的 Collection.contains 方法会导致为任意的 e 元素调用 o.equals(e) 方法。可随意对各种实现执行优化，只要避免调用 equals 即可，例如，通过首先比较两个元素的哈希码。（Object.hashCode() 规范保证哈希码不相等的两个对象不会相等）。较为常见的是，各种 Collections Framework 接口的实现可随意利用底层 Object 方法的指定行为，而不管实现程序认为它是否合适。Collections此类完全由在 collection 上进行操作或返回 collection 的静态方法组成。它包含在 collection 上操作的多态算法，即“包装器”，包装器返回由指定 collection 支持的新 collection，以及少数其他内容。 如果为此类的方法所提供的 collection 或类对象为 null，则这些方法都将抛出 NullPointerException。 此类中所含多态算法的文档通常包括对实现 的简短描述。应该将这类描述视为实现注意事项，而不是规范 的一部分。实现者应该可以随意使用其他算法替代，只要遵循规范本身即可。（例如，sort 使用的算法不一定是合并排序算法，但它必须是稳定的。） 此类中包含的“破坏性”算法，即可修改其所操作的 collection 的算法，该算法被指定在 collection 不支持适当的可变基元（比如 set 方法）时抛出 UnsupportedOperationException。如果调用不会对 collection 产生任何影响，那么这些算法可能（但不要求）抛出此异常。例如，在已经排序的、不可修改列表上调用 sort 方法可能会（也可能不会）抛出 UnsupportedOperationException。Comparator强行对某个对象 collection 进行整体排序 的比较函数。可以将 Comparator 传递给 sort 方法（如 Collections.sort 或 Arrays.sort），从而允许在排序顺序上实现精确控制。还可以使用 Comparator 来控制某些数据结构（如有序 set或有序映射）的顺序，或者为那些没有自然顺序的对象 collection 提供排序。当且仅当对于一组元素 S 中的每个 e1 和 e2 而言，c.compare(e1, e2)==0 与 e1.equals(e2) 具有相等的布尔值时，Comparator c 强行对 S 进行的排序才叫做与 equals 一致 的排序。当使用具有与 equals 不一致的强行排序能力的 Comparator 对有序 set（或有序映射）进行排序时，应该小心谨慎。假定一个带显式 Comparator c 的有序 set（或有序映射）与从 set S 中抽取出来的元素（或键）一起使用。如果 c 强行对 S 进行的排序是与 equals 不一致的，那么有序 set（或有序映射）将是行为“怪异的”。尤其是有序 set（或有序映射）将违背根据 equals 所定义的 set（或映射）的常规协定。例如，假定使用 Comparator c 将满足 (a.equals(b) && c.compare(a, b) != 0) 的两个元素 a 和 b 添加到一个空 TreeSet 中，则第二个 add 操作将返回 true（树 set 的大小将会增加），因为从树 set 的角度来看，a 和 b 是不相等的，即使这与 Set.add 方法的规范相反。注：通常来说，让 Comparator 也实现 java.io.Serializable 是一个好主意，因为它们在可序列化的数据结构（像 TreeSet、TreeMap）中可用作排序方法。为了成功地序列化数据结构，Comparator（如果已提供）必须实现 Serializable。在算术上，定义给定 Comparator c 对给定对象 set S 实施强行排序 的关系式 为： {(x, y) such that c.compare(x, y) <= 0}.此整体排序的商 (quotient) 为： {(x, y) such that c.compare(x, y) == 0}. 它直接遵循 compare 的协定，商是 S 上的等价关系，强行排序是 S 上的整体排序。当我们说 c 强行对 S 的排序是与 equals 一致 的时，意思是说排序的商是对象的 equals(Object) 方法所定义的等价关系： {(x, y) such that x.equals(y)}. 此接口是 Java Collections Framework 的成员。 Collection 是集合框架的父接口Collections是集合的工具类，里面提供了一些static方法 可以直接调用List是一些有序集合的父接口 继承与CollectionHashTable是一个线程安全的集合 它和Vector在jdk5.0以后基本已经淘汰Comparator是比较器类，可以自己实现其中的compare方法来进行对象的比较 一般在构造HashSet的时候要传入一个构造器或实现comparable接口 看看 util下面的 这些个 类 或是接口就明白了，sun设计 工具类的核心啊 我的资源里有这个API文档，自己去下吧 现在sun官方已经有中文的J2SE6.0 API了，可以去下 完整的j2se api document是没有中文版的。 你查一下API就知道了！了解Collection，其余就都了解了 http://topic.csdn.net/u/20080514/14/dd017262-69e6-4065-b457-7a545785a063.html 上个英文版的下载地址：https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewFilteredProducts-SingleVariationTypeFilter 我有中文的API 给分 哈哈 推荐你看下这个视频：http://www.verycd.com/topics/93279/其中的第7章 容器 有详细的讲解。 还是中文版API好啊 昨晚刚整理了一份BLOG，新章节的，估计可以帮你派上用场：Java中的集合、枚举、泛型【上】http://blog.csdn.net/silentbalanceyh/archive/2009/09/24/4586611.aspx你可以参考一下，希望对你有帮助 救命啊!!!!!!!! 大哥 jdbc里怎样调用一个带参数的存储过程 CheckboxGroup怎么获取标签? Java程序的编译问题 正则表达式如何匹配“<a>字符串</a>”？ 请问如何将另外一个工程加到一个工程里来 如何在FRAME里加HTML文件啊？？ 请问这个错误是怎么回事：关于线程（Debug） tomcat后台管理程序中配置的数据源在jsp里如何调用? 怎样从一副jpeg图片中生成一副缩略图 这段代码小弟不明，请指点！ java线程数据获问题 关于JTextArea在一个循环中，如何使用鼠标事件监听的问题
你自己搜下java api去下载
此类实现一个哈希表，该哈希表将键映射到相应的值。任何非 null 对象都可以用作键或值。为了成功地在哈希表中存储和获取对象，用作键的对象必须实现 hashCode 方法和 equals 方法。Hashtable 的实例有两个参数影响其性能：初始容量 和加载因子。容量 是哈希表中桶 的数量，初始容量 就是哈希表创建时的容量。注意，哈希表的状态为 open：在发生“哈希冲突”的情况下，单个桶会存储多个条目，这些条目必须按顺序搜索。加载因子 是对哈希表在其容量自动增加之前可以达到多满的一个尺度。初始容量和加载因子这两个参数只是对该实现的提示。关于何时以及是否调用 rehash 方法的具体细节则依赖于该实现。通常，默认加载因子(.75)在时间和空间成本上寻求一种折衷。加载因子过高虽然减少了空间开销，但同时也增加了查找某个条目的时间（在大多数 Hashtable 操作中，包括 get 和 put 操作，都反映了这一点）。初始容量主要控制空间消耗与执行 rehash 操作所需要的时间损耗之间的平衡。如果初始容量大于 Hashtable 所包含的最大条目数除以加载因子，则永远 不会发生 rehash 操作。但是，将初始容量设置太高可能会浪费空间。如果很多条目要存储在一个 Hashtable 中，那么与根据需要执行自动 rehashing 操作来增大表的容量的做法相比，使用足够大的初始容量创建哈希表或许可以更有效地插入条目。下面这个示例创建了一个数字的哈希表。它将数字的名称用作键： Hashtable<String, Integer> numbers
= new Hashtable<String, Integer>();
numbers.put("one", 1);
numbers.put("two", 2);
numbers.put("three", 3);要获取一个数字，可以使用以下代码： Integer n = numbers.get("two");
if (n != null) {
System.out.println("two = " + n);
}
}由所有类的“collection 视图方法”返回的 collection 的 iterator 方法返回的迭代器都是快速失败 的：在创建 Iterator 之后，如果从结构上对 Hashtable 进行修改，除非通过 Iterator 自身的 remove 方法，否则在任何时间以任何方式对其进行修改，Iterator 都将抛出ConcurrentModificationException。因此，面对并发的修改，Iterator 很快就会完全失败，而不冒在将来某个不确定的时间发生任意不确定行为的风险。由 Hashtable 的键和元素方法返回的 Enumeration 不 是快速失败的。 注意，迭代器的快速失败行为无法得到保证，因为一般来说，不可能对是否出现不同步并发修改做出任何硬性保证。快速失败迭代器会尽最大努力抛出 ConcurrentModificationException。因此，为提高这类迭代器的正确性而编写一个依赖于此异常的程序是错误做法：迭代器的快速失败行为应该仅用于检测程序错误。 从Java 2 平台 v1.2起，此类就被改进以实现 Map 接口，使它成为 Java Collections Framework 中的一个成员。不像新的 collection 实现，Hashtable 是同步的
ArrayList
List 接口的大小可变数组的实现。实现了所有可选列表操作，并允许包括 null 在内的所有元素。除了实现 List 接口外，此类还提供一些方法来操作内部用来存储列表的数组的大小。（此类大致上等同于 Vector 类，除了此类是不同步的。）size、isEmpty、get、set、iterator 和 listIterator 操作都以固定时间运行。add 操作以分摊的固定时间 运行，也就是说，添加 n 个元素需要 O(n) 时间。其他所有操作都以线性时间运行（大体上讲）。与用于 LinkedList 实现的常数因子相比，此实现的常数因子较低。每个 ArrayList 实例都有一个容量。该容量是指用来存储列表元素的数组的大小。它总是至少等于列表的大小。随着向 ArrayList 中不断添加元素，其容量也自动增长。并未指定增长策略的细节，因为这不只是添加元素会带来分摊固定时间开销那样简单。在添加大量元素前，应用程序可以使用 ensureCapacity 操作来增加 ArrayList 实例的容量。这可以减少递增式再分配的数量。注意，此实现不是同步的。如果多个线程同时访问一个 ArrayList 实例，而其中至少一个线程从结构上修改了列表，那么它必须 保持外部同步。（结构上的修改是指任何添加或删除一个或多个元素的操作，或者显式调整底层数组的大小；仅仅设置元素的值不是结构上的修改。）这一般通过对自然封装该列表的对象进行同步操作来完成。如果不存在这样的对象，则应该使用 Collections.synchronizedList 方法将该列表“包装”起来。这最好在创建时完成，以防止意外对列表进行不同步的访问： List list = Collections.synchronizedList(new ArrayList(...)); 此类的 iterator 和 listIterator 方法返回的迭代器是快速失败的：在创建迭代器之后，除非通过迭代器自身的 remove 或 add 方法从结构上对列表进行修改，否则在任何时间以任何方式对列表进行修改，迭代器都会抛出 ConcurrentModificationException。因此，面对并发的修改，迭代器很快就会完全失败，而不是冒着在将来某个不确定时间发生任意不确定行为的风险。注意，迭代器的快速失败行为无法得到保证，因为一般来说，不可能对是否出现不同步并发修改做出任何硬性保证。快速失败迭代器会尽最大努力抛出 ConcurrentModificationException。因此，为提高这类迭代器的正确性而编写一个依赖于此异常的程序是错误的做法：迭代器的快速失败行为应该仅用于检测 bug
Collection
collection，并在需要最大普遍性的地方操作这些 collection。 包 (bag) 或多集合 (multiset)（可能包含重复元素的无序 collection）应该直接实现此接口。 所有通用的 Collection 实现类（通常通过它的一个子接口间接实现 Collection）应该提供两个“标准”构造方法：一个是 void（无参数）构造方法，用于创建空 collection；另一个是带有 Collection 类型单参数的构造方法，用于创建一个具有与其参数相同元素新的 collection。实际上，后者允许用户复制任何 collection，以生成所需实现类型的一个等效 collection。尽管无法强制执行此约定（因为接口不能包含构造方法），但是 Java 平台库中所有通用的 Collection 实现都遵从它。 此接口中包含的“破坏性”方法，是指可修改其所操作的 collection 的那些方法，如果此 collection 不支持该操作，则指定这些方法抛出 UnsupportedOperationException。如果是这样，那么在调用对该 collection 无效时，这些方法可能，但并不一定抛出 UnsupportedOperationException。例如，如果要添加的 collection 为空且不可修改，则对该 collection 调用 addAll(Collection) 方法时，可能但并不一定抛出异常。 一些 collection 实现对它们可能包含的元素有所限制。例如，某些实现禁止 null 元素，而某些实现则对元素的类型有限制。试图添加不合格的元素将抛出一个未经检查的异常，通常是 NullPointerException 或 ClassCastException。试图查询是否存在不合格的元素可能抛出一个异常，或者只是简单地返回 false；某些实现将表现出前一种行为，而某些实现则表现后一种。较为常见的是，试图对某个不合格的元素执行操作且该操作的完成不会导致将不合格的元素插入 collection 中，将可能抛出一个异常，也可能操作成功，这取决于实现本身。这样的异常在此接口的规范中标记为“可选”。 由每个 collection 来确定其自身的同步策略。在没有实现的强烈保证的情况下，调用由另一进程正在更改的 collection 的方法可能会出现不确定行为；这包括直接调用，将 collection 传递给可能执行调用的方法，以及使用现有迭代器检查 collection。 Collections Framework 接口中的很多方法是根据 equals 方法定义的。例如，contains(Object o) 方法的规范声明：“当且仅当此 collection 包含至少一个满足 (o==null ? e==null :o.equals(e)) 的元素 e 时，返回 true。”不 应将此规范理解为它暗指调用具有非空参数 o 的 Collection.contains 方法会导致为任意的 e 元素调用 o.equals(e) 方法。可随意对各种实现执行优化，只要避免调用 equals 即可，例如，通过首先比较两个元素的哈希码。（Object.hashCode() 规范保证哈希码不相等的两个对象不会相等）。较为常见的是，各种 Collections Framework 接口的实现可随意利用底层 Object 方法的指定行为，而不管实现程序认为它是否合适。
Collections
此类完全由在 collection 上进行操作或返回 collection 的静态方法组成。它包含在 collection 上操作的多态算法，即“包装器”，包装器返回由指定 collection 支持的新 collection，以及少数其他内容。 如果为此类的方法所提供的 collection 或类对象为 null，则这些方法都将抛出 NullPointerException。 此类中所含多态算法的文档通常包括对实现 的简短描述。应该将这类描述视为实现注意事项，而不是规范 的一部分。实现者应该可以随意使用其他算法替代，只要遵循规范本身即可。（例如，sort 使用的算法不一定是合并排序算法，但它必须是稳定的。） 此类中包含的“破坏性”算法，即可修改其所操作的 collection 的算法，该算法被指定在 collection 不支持适当的可变基元（比如 set 方法）时抛出 UnsupportedOperationException。如果调用不会对 collection 产生任何影响，那么这些算法可能（但不要求）抛出此异常。例如，在已经排序的、不可修改列表上调用 sort 方法可能会（也可能不会）抛出 UnsupportedOperationException。
Comparator
强行对某个对象 collection 进行整体排序 的比较函数。可以将 Comparator 传递给 sort 方法（如 Collections.sort 或 Arrays.sort），从而允许在排序顺序上实现精确控制。还可以使用 Comparator 来控制某些数据结构（如有序 set或有序映射）的顺序，或者为那些没有自然顺序的对象 collection 提供排序。当且仅当对于一组元素 S 中的每个 e1 和 e2 而言，c.compare(e1, e2)==0 与 e1.equals(e2) 具有相等的布尔值时，Comparator c 强行对 S 进行的排序才叫做与 equals 一致 的排序。当使用具有与 equals 不一致的强行排序能力的 Comparator 对有序 set（或有序映射）进行排序时，应该小心谨慎。假定一个带显式 Comparator c 的有序 set（或有序映射）与从 set S 中抽取出来的元素（或键）一起使用。如果 c 强行对 S 进行的排序是与 equals 不一致的，那么有序 set（或有序映射）将是行为“怪异的”。尤其是有序 set（或有序映射）将违背根据 equals 所定义的 set（或映射）的常规协定。例如，假定使用 Comparator c 将满足 (a.equals(b) && c.compare(a, b) != 0) 的两个元素 a 和 b 添加到一个空 TreeSet 中，则第二个 add 操作将返回 true（树 set 的大小将会增加），因为从树 set 的角度来看，a 和 b 是不相等的，即使这与 Set.add 方法的规范相反。注：通常来说，让 Comparator 也实现 java.io.Serializable 是一个好主意，因为它们在可序列化的数据结构（像 TreeSet、TreeMap）中可用作排序方法。为了成功地序列化数据结构，Comparator（如果已提供）必须实现 Serializable。在算术上，定义给定 Comparator c 对给定对象 set S 实施强行排序 的关系式 为： {(x, y) such that c.compare(x, y) <= 0}.
此整体排序的商 (quotient) 为：
{(x, y) such that c.compare(x, y) == 0}.
它直接遵循 compare 的协定，商是 S 上的等价关系，强行排序是 S 上的整体排序。当我们说 c 强行对 S 的排序是与 equals 一致 的时，意思是说排序的商是对象的 equals(Object) 方法所定义的等价关系：
{(x, y) such that x.equals(y)}. 此接口是 Java Collections Framework 的成员。
Collections是集合的工具类，里面提供了一些static方法 可以直接调用
List是一些有序集合的父接口 继承与Collection
HashTable是一个线程安全的集合 它和Vector在jdk5.0以后基本已经淘汰
Comparator是比较器类，可以自己实现其中的compare方法来进行对象的比较 一般在构造HashSet的时候要传入一个构造器或实现comparable接口
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewFilteredProducts-SingleVariationTypeFilter
其中的第7章 容器 有详细的讲解。
Java中的集合、枚举、泛型【上】
http://blog.csdn.net/silentbalanceyh/archive/2009/09/24/4586611.aspx
你可以参考一下，希望对你有帮助