java.util.LinkedHashSet
查询速度的原因底层使用了散列，但是看起来它使用了链表来维护元素的插入顺序)，这和hashset实现方式是不同的，因为在它所有的插入过程中都保持了一个双向链表的属性。链表定义了迭代顺序，即为我们向集合set中插入元素的顺序。注意如果一个元素被重复插入到集合中并不会改变集合的插入顺序。(如果元素e被添加到集合s中，会调用s.add(e)方法，但是s.contains(e)会在s.add(e)方法之前调用并返回true)。
增加实现的代价。这可以用作生成一个set集合的副本，该set集合不论其原始集合是怎样实现的，它都会和原始集合一样，元素的顺序是不会改变的，例如：
功能已经将容器中的元素存储位置分配好，所以它的基本操作(add，remove，contains)运行时间为常量时间。其性能比hashset稍微低一点，因为添加了维持链表特性的代价：迭代都需要一定比例的时间去计算set集合的大小，无论其容量大小是多少。hashset迭代代价比较高，其容量是需要一定时间比例的。
功能：初始化容量和载入属性。在hashset方面，是精确定义的。然而，需要注意的是为实例初始化一个大容量的代价要比为hashset所付出的代价要小，因为此类的迭代次数不会被容量所影响。
修改了set容器，而这从外在看来一定是要同步的。这通常同步一些包含此set集合的对象来实现的。如果没有这样的对象存在，那么这个集合set应该被方法“包”一下。这最好在创建时候就执行，以预防发生一些意外的事件：
次数是实效很迅速的：在迭代创建后的如果集合set发生修改，除了通过迭代器自身的remove方法外的其它任何方法，迭代会抛出异常修改元素而言，迭代会迅速且全部失效，而不是冒险去出现一些在未来某时不确定的行为。
fail-fast特性不能保证，正如在非同步化修改中做保证也是不可能的。fail-fast迭代次数会在被动的尽力的基础上抛出ConcurrentModificationException异常。因此，写一个依赖此异常来判定其正确性的程序的想法是错误的：迭代器里的fail-fast
方法概要
