AJPFX总结OpenJDK 和 HashMap大量数据处理时，避免垃圾回收延迟的技巧二

HashMap简史

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

H.P. Luhn (1896-1964)

Luhn 写道， “hashcode” 是基本的运算符。 Luhn 写道， “Associative Array” 是基本的运算数。 由此， ‘HashMap’ (也称为 HashTable) 就这样产生了。 注: HashMap 是由 1896 年出生的计算机科学家提出来的。HashMap 可是个老 家伙啦!

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

Niklaus Wirth 在他1976年编写的经典著作《算法 + 数据结构 = 程序》中，谈到对于所有的程序，都可以将“算法”视为基本的运算符，将“数据结构”视为基本的运算“数”。

从那时起，数据结构(HashMap，Heap等)发展缓慢。1987年有一个重大突破， Tarjan 提出了非常著名的 F-Heap；但除此之外，乏善可陈。要知道，HashMap 是1953年第一次提出的，已经过去60余年啦！

与此同时，算法方面 (Karmakar 1984, NegaMax 1989, AKS Primality 2002, Map-Reduce2006, Grover’s Quantum search - 2011) 则进展迅速，为计算的基础建设带来了崭新的、强大的运算符。

然而，现在到了2014，也许又轮到数据结构来取得重大进展了。从 OpenJDK 平台来看， 非堆 HashMap 就是一个正在发展的数据结构。

HashMap 的历史就介绍到这。下面我们来探索今天的 HashMap 吧。具体来说，我们先来看一看这个老家伙在 Java 中现存的 3 种实现。

java.util.HashMap (非线程安全)

对于任何真正的多线程并发用例，它会立即失败，而且是每次都会失败。所有用到它的代码必须使用 Java 内存模型(JMM)的内存屏障(memory barrier)策略(如 synchronized 或 volatile) 来保证顺序执行。

一个简单的失败样例如下： - synchronized 的写入 - 没加 synchronized 的读取 - 真正并发 (2 个 CPU/L1) 我们来看看为什么会失败...

假设线程1写入 HashMap，那么它做出的改动只会保存在 CPU 1的1级缓存中。然后线程2，在几秒钟后开始在 CPU 2上运行；它读取 HashMap，是从 CPU 2的1级缓存中读出来的——它看不到线程1做出的改动，因为在读和写的线程中都没有读、写间的内存屏障，虽然 Java 内存模型要求线程共享 HashMap 的情形下必须要有。即使线程1的写操作加了 synchronize 也会失败，这样虽然能把它做出的改动写入到主内存中，但线程2仍然看不到这些改动，因为线程2只会从 CPU 2的1级缓存中读取。所以在写操作上加 synchronized 只能避免写操作的冲突。要对于所有的线程都添加必要的内存屏障，你必须也要 synchronize 读操作。

thrSafeHM = Collections.synchronizedMap(hm) ; （粗粒度锁定）

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

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%的多线程安全。这很酷，对吧？

 

java.util.concurrent.ConcurrentHashMap (线程安全、智能锁，但并非完美)

在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影响的储存数据的集合。