“Hash Code”这个概念第一次出现是在1953年1月的《Computing literature》中，H. P. Luhn  (1896-1964) 在一篇 IBM 的内部备忘录中提出了这个术语。当时 Luhn 是要解决这个问题：“给出组成一本教科书的一系列单词，要得出 100% 完整的（单词，出现页码集）对应关系，最好的算法和数据结构是什么？”

从 HashMap 的诞生讲到它的早期应用场景，我们从1950年代跳到1970年代

使用“同步”时实现高性能要求低竞争率。这是很常见的，而且在很多情况下这并不像听起来那么坏。然而，一旦你引入任何竞争（多个线程试图同时操作同一集合），性能就会受到影响。在最坏的情况下，如具有很高的锁争用，你可能会得到多个线程比单个线程（操作没有锁定或任何种类的争夺）的性能表现更差的结论。

Collections.synchronizedMap() 返回一个 MT-Safe HashMap.

这是一个通过粗粒度的锁来实现所有关键部分的mutate()和access()操作，这样可以让多个线程操作整个Map。这个结果在Zero  MT-concurrency中，意味着一个时刻仅有一个线程可以访问。另一个后果就是作为高锁争用（High Lock Contention）的粗粒度锁，锁住的途径是一种非常不受欢迎的已知条件。关于高锁争用（High Lock Contention）（请看在左边的图片，N个线程争用一个锁，但是迫于阻塞只好等待着，锁已经给了正在运行的线程）。

幸好这是完全同步的，不会真正的同步，隔离（isolation）=序列化（SERIALIZABLE）（总体上这是令人失望的）HashMap陷阱，我们期待的OpenJDK非堆存储（off-heap）JEP已经有一个 值得推荐的期待：硬件事务性内存（Hardware Transactional Memory (HTM)）。关于HTM，粗粒度的同步写操作在Java中将会再一次变得很酷！就让HTM通过代码上的零并发和在硬件的零并发来帮助我们，实现真正的并发并且100%的多线程安全。这很酷，对吧？

 

在jdk1.5的核心API中，终于发布了java程序员梦寐以求的java.util.concurrent.ConcurrentHashMap。虽然ConcurrentHashMap不能广泛替代HashMap（ConcurrentHashMap消耗更多的资源，在低竞争条件下可能不太适合。），但是它解决了其它类型的HashMap解决不了的问题：提供既有真正的多线程安全，又有真正的多线程并发的能力。让我们画一幅画来准确地描述ConcurrentHashMap为什么（原文是how）这么有用的（有效，有作用，不知道怎么翻译好了。原文：helpful）。

1.分离锁

2.每个独立的HashMap子集对应一个锁：N个hash桶（子集）对应N段(Segments)锁。（在图片右边，段(Segments) = 3

3.在设计出将一个高竞争的锁分解成多个不影响数据完整性的锁时，分离锁是非常有用的。

4.更好的并发，在处理"先检查判断状态，再操作"（"check-then-act"）的竞态条件问题时，concurrentHashMap是一个不需要同步的解决方案。

5.问题：你如何同时保护整个集合(collections)? 获取所有的锁(递归地)?

现在你可能要问了：随着ConcurrentHashMap和java.util.concurrent包的发布，java是一个高性能计算社区（High Performance Computing community）能够在上面创建解决方案来解决他们问题的终极编程平台吗？

不幸的是，很现实的一个回答还是“还没呢”。真的，那么还存在着什么问题呢？

ConcurrentHashMap存在着规模问题和保存中间态对象（medium-lived objects）问题。如果你有一小部分使用concurrentHashMap的关键的集合对象，很可能有些会很大。在某些情况下，在这些集合中存在着大量的中间态对象(medium-lived objects)。这些中间态对象(medium-lived objects)贡献了大部分的GC次数（时间,GC pause times），他们的消耗有可能是短暂对象（short-lived objects）的20倍。长时间存活对象(Long-lived objects)往往停留在终身区(tenured space)，短暂对象(short-lived objects)在young区死亡，但是中间态对象(medium-lived objects)会复制到所有的存活空间，并在终身区(trenured space)死亡，中间态对象(medium-lived objects)到处拷贝并在最后被清理产生的消耗十分巨大。最理想的是你能有一个没有GC影响的储存数据的集合。