LinkedHashMap和LinkedHashSet是JDK 1.4中引入的两个新的集合类。虽然已经过去５年了，但我敢打赌并不是很多人都用过（因为我就没有用过）。但这两个类在某些情况下还是非常有用的，过去没有用，现在没有用，都没有关系。但还是应该对这两个Collection框架的新成员有所了解，因为也许以后你会到，或者其实你现在就应该要用到。
LinkedHashMap/LinkedHashSet 顾名思义，就是在Hash的实现上添加了Linked的支持。对于HashMap/HashSet的每个节点上通过一个链表串联起来，这样就可以保证确定的顺序。对于希望有常量复杂度的高效存取性能要求，同时有要求排序的情况下，现在可以直接使用LinkedHashMap/Set了。
对于LinkedHashMap还有一点特别注意，LinkedHashMap支持两种排序：插入顺序、访问顺序。前者是指按照插入时的顺序排序，后者是指按照最旧使用到最近使用的顺序。即如果在一个LinkedHashMap中有5个节点，现在的顺序是e1 e2 e3 e4 e5. 如果是使用顺序的话，现在访问了一次e2 那么e2节点将移至链表的尾部。现在顺序变为：e1 e3 e4 e5 e2.
这会造成严重的性能问题吗？答案当然是否定的。因为在这儿的链表操作是常量级的。这也是LinkedHashMap/Set在这儿比TreeMap/Set性能更高的原因。
同样，LinkedHashMap/Set也不是thread-safe的。如果在多线程下访问，是需要进行外部同步，或者使用Java代码
Collections.synchronizedMap()的方法包装成一个thread-safe的Map/Set。
Collections.synchronizedMap()的方法包装成一个thread-safe的Map/Set。
特别需要注意的是，在使用“访问顺序”时，读取节点操作也是“结构变化”的操作。因为，这会改变元素遍历的顺序。所以，在使用LinkedHashMap的iterator()方法，遍历元素时，如果其它线程有读取操作，也要进行同步。否则，也会抛出同其它fail-fast一样的由于删除或增加操作而引起的CurrentModificationException的例外。
LinkedHashMapHashMap等
转：
前段时间做了个商务网站，我是用eclipse3.2+jdk6.0+tomcat5.5开发的，等到交付放到服务器的时候，却发现出现了一些始料未及的问题。有一些是对java类函数还没搞的很明白，还有一些是jdk版本的问题，找一两个例子说明下。
问题1：HashMap
这个类比较有用的就是将“键-值”一一对应起来，利用了put(K key V value) 函数。最开始我实现的目的是按载入的顺序放入HashMap，然后利用（HashMap）.values().iterator()转换为Iterator对象按载入的顺序输出。但最终的效果发现输出的值是乱序的，查了下资料才知道HashMap是随机输出的，要想实现按输入的顺序来输出需要用到HashMap的子类LinkedHashMap。于是，声明时候直接替换成new LinkedHashMap()，发现成功了。
还有利用put(K key V value)函数时，如果键K是int类型的数字，将在jdk1.4及以下版本中会报错，好像编译的时候无法自动匹配int类型的，解决办法就是：将这个Int型数据转换成String类型，比如String.valueOf(int pId)；在jdk5.0及以上版本里将不会出现这种问题。
问题2：String.indexOf() 和 String.contains()
这两个函数都可以用来判断一个字符串中是否包含一个字符或部分字符串。但前者是jdk1.4版本就出现了；后者属于jdk5.0的新特性，原先没注意到这个问题，后来只好更换函数了。
简要说明下这两个函数(参考jdk文档)：int indexOf(String str)：返回第一次出现的指定子字符串在此字符串中的索引，不包含将返回-1；boolean contains(CharSequence s)：当且仅当此字符串包含 char 值的指定序列
