在平时开发过程中为了提高性能或业务解耦，会引入多线程，同时在开发web应用的时候，每个web容器在处理用户请求的时候会把用户的请求放到线程里面去执行，这就意味着即使我们不主动的去使用多线程，在实际运行的过程中，我们的程序还是处在一个多线程的环境。如果不做任何的同步控制，我们的代码在多线程环境下是不安全的。
由此及彼，我们看看HashMap的源码，观察一下它是否是线程安全的。
观察我们最常用的get和put方法，它们并没有做同步的控制，所以HashMap在多线程环境中是线程不安全的。
在jdk里，java为我们提供了一个线程安全的Map，就是所谓的HashTable。我们可以观察一下HashTable的源码，可以发现它的get和put方法都使用了内置锁进行同步控制，HashTable在所有真正和数据交互的方法上面都加了Synchronized。
那么既然有了一个线程安全的Map，为什么Jdk的并发包中还会有一个ConcurrentHashMap呢？
从HashTable的源码中我们了解到，不管是读（get）还是写（put）,所有的这些方法都使用了synchronized关键字修饰，那么在多线程环境下，这样的效率是非常低下的，而ConcurrentHashMap针对这个问题而提出的。
ConcurrentHashMap是如何在保证性能的情况下来实现线程的安全呢？这就要了解ConcurrentHashMap的内部实现了
ConcurrentHashMap内部实现
HashMap中都有所谓Hash的说法，那么Hash到底是什么意思呢？
假如现在有1000个元素，我们要把这1000个元素放到100个桶里面，这个过程就是所谓的Hash过程，我们可以通过取余来决定哪个元素放在哪个桶，如下图我们给100个桶标上下标，从1~100。元素1%100 = 1，所以元素1就放在第1个桶。这就是Hash的基本思想。按照上面的取余过程，1和101都会放在第1个桶中，对于HashMap来说，会把1和101以链表的形式挂载第1个桶上，每个桶都有单独的一个锁（ConcurrentHashMap中分段锁的概念）。
分段锁在jdk1.7和jdk1.8的实现有所不同。
在jdk1.7及以前的实现里，把上面说的100个桶分为N个段，每个段里面有自己独立的一个锁。而jdk1.8及以后则是每个桶有自己独立的锁。总的来说就是jdk1.8之后的锁的粒度更细一些。
