Set集合为什么是有序的?是怎么样实现的?

[sun_left]

小弟最近在研究Java Collections Framework,看到Set集合讲解时,说Set集合是不能重复的,而且是有序的,测试代码如下:

public class SetTest{
	public static void main(String [] args){
		TreeSet<String> ts = new TreeSet<String>();
		ts.add("bbb");
		ts.add("fff");
		ts.add("aaa");
		ts.add("rrr");
                ts.add("aaa");
		Iterator it = ts.iterator();
		while(it.hasNext()){
			System.out.println(it.next().toString());
		}
	}
}

结果是:
aaa
bbb
fff
rrr

问题如题.

[Slumber]

TreeSet底层应该是由TreeMap来实现的，它里面的对象通过compare方法的结果来决定其顺序。

[老紫竹]

TreeSet 就是有序的结合啊！ String 默认的Compare 是根据字母排序的，如果是自己的对象，需要实现对应的Comparable接口

[zdjray]

文档里有说明
注意第二句

A NavigableSet implementation based on a TreeMap. The elements are ordered using their natural ordering, or by a Comparator provided at set creation time, depending on which constructor is used.

[胡矣]

以下来自JDK 5.0

public class TreeSet<E>extends AbstractSet<E>implements SortedSet<E>, Cloneable, Serializable此类实现 Set 接口，该接口由 TreeMap 实例支持。此类保证排序后的 set 按照升序排列元素，根据使用的构造方法不同，可能会按照元素的自然顺序 进行排序（参见 Comparable），或按照在创建 set 时所提供的比较器进行排序。

此实现为基本操作（add、remove 和 contains）提供了可保证的 log(n) 时间开销。

注意，如果要正确实现 Set 接口，则 set 所维护的顺序（是否提供了显式比较器）必须为与等号一致（请参阅与等号一致 精确定义的 Comparable 或 Comparator）。这是因为 Set 接口根据 equals 操作进行定义，但 TreeSet 实例将使用其 compareTo（或 compare）方法执行所有的键比较，因此，从 set 的角度出发，该方法认为相等的两个键就是相等的。即使 set 的顺序与等号不一致，其行为也是 定义良好的；它只是违背了 Set 接口的常规协定。

注意，此实现不是同步的。如果多个线程同时访问一个 set，而其中至少一个线程修改了该 set，那么它必须 保持外部同步。通常通过对某个自然封装该 set 的对象进行同步来实现此操作。如果不存在此类对象，则 set 就应该使用 Collections.synchronizedSet 方法进行“包装”。此操作最好在创建时进行，以防止对 set 的意外非同步访问：

     SortedSet s = Collections.synchronizedSortedSet(new TreeSet(...));
 此类的 iterator 方法返回的迭代器是快速失败的：如果在迭代器创建后的任意时间修改 set（通过迭代器本身 remove 方法之外的任何其他方式），迭代器将抛出 ConcurrentModificationException。因此，在并发修改时，迭代器将快速而彻底地失败，而不会在以后的不确定时间有出现任意、无法确定行为的危险。 

注意，无法保证迭代器的快速失败行为，因为通常来说，不可能在非同步并发修改的情况下提供任何硬性保证。快速失败的迭代器将尽量抛出 ConcurrentModificationException。因此，为了获得其准确性而编写依赖此异常的程序的做法是错误的：迭代器的快速失败行为应当仅用于检测 bug。

此类是 Java Collections Framework 的成员。 

[胡矣]

上面的格式太差了,重来一次.


public class TreeSet<E>extends AbstractSet<E>implements SortedSet<E>, Cloneable, Serializable此类实现 Set 接口，该接口由 TreeMap 实例支持。此类保证排序后的 set 按照升序排列元素，根据使用的构造方法不同，可能会按照元素的自然顺序 进行排序（参见 Comparable），或按照在创建 set 时所提供的比较器进行排序。

此实现为基本操作（add、remove 和 contains）提供了可保证的 log(n) 时间开销。

注意，如果要正确实现 Set 接口，则 set 所维护的顺序（是否提供了显式比较器）必须为与等号一致（请参阅与等号一致 精确定义的 Comparable 或 Comparator）。这是因为 Set 接口根据 equals 操作进行定义，但 TreeSet 实例将使用其 compareTo（或 compare）方法执行所有的键比较，因此，从 set 的角度出发，该方法认为相等的两个键就是相等的。即使 set 的顺序与等号不一致，其行为也是 定义良好的；它只是违背了 Set 接口的常规协定。

注意，此实现不是同步的。如果多个线程同时访问一个 set，而其中至少一个线程修改了该 set，那么它必须 保持外部同步。通常通过对某个自然封装该 set 的对象进行同步来实现此操作。如果不存在此类对象，则 set 就应该使用 Collections.synchronizedSet 方法进行“包装”。此操作最好在创建时进行，以防止对 set 的意外非同步访问：

SortedSet s = Collections.synchronizedSortedSet(new TreeSet(...));
此类的 iterator 方法返回的迭代器是快速失败的：如果在迭代器创建后的任意时间修改 set（通过迭代器本身 remove 方法之外的任何其他方式），迭代器将抛出 ConcurrentModificationException。因此，在并发修改时，迭代器将快速而彻底地失败，而不会在以后的不确定时间有出现任意、无法确定行为的危险。

注意，无法保证迭代器的快速失败行为，因为通常来说，不可能在非同步并发修改的情况下提供任何硬性保证。快速失败的迭代器将尽量抛出 ConcurrentModificationException。因此，为了获得其准确性而编写依赖此异常的程序的做法是错误的：迭代器的快速失败行为应当仅用于检测 bug。

此类是 Java Collections Framework 的成员。

[龙行天下2015]

Set 对象本身是没有顺序的，Set首先保证元素的唯一性
LinkedHashSet 和 TreeSet具有顺序。

[gthacker]

关注