ConcurrentHashMap面试

ConcurrentHashMap是一个在并发环境情况下线程安全的容器，为了保证线程安全，在jdk1.7和jdk1.8的实现方式是不一样：

在1.7中，ConcurrentHashMap采用的分段加锁，锁使用的是可重入锁（renntrantlock），整体的数据结构就是一个数据数组的每一个元素是一个hashmap，当然hashmap1.8相对于1.7也做了升级，主要就是插入链表的元素从头插入改为尾部插入，链表元素个数大于8个则转为红黑树。回到1.7的ConcurrentHashMap，某一个线程在插入或删除一个元素的情况，只会对hash之后定位的某一段加锁，其他线程继续可以访问其他的段，在get某个元素的情况下，没有加锁，使用的挖了特volitle关键字实现了变量修改后对其他线程的可见性（使其他线程缓存的值无效需重新到主存中读取）。

在做size统计的时候，会先不加锁，然后发现其他线程对数据结果有修改，则使用lock加锁统计。

put元素的时候，会尝试加lock锁，达到尝试次数后强锁失败，阻塞的加lock，加锁成功后进行put,

，在jdk1.8中，ConcurrentHashMap并没有使用分段加锁方式，底层存储结构和 1.8 的 HashMap 是一样的，都是数组+链表+红黑树。不同的就是，多了一些并发的处理，直接在hashmap的每一个桶上面使用Synchronized实现线程安全，在1.6之后对自选锁做了优化，第一个优化是：使用适应性自旋锁代替自旋锁，之前的方式是循环自选的方式去尝试获取锁而不直接进入阻塞状态，1.6之后会根据上一个线程获取锁的时间来决定自选时间和次数，来决定这一次的自选时间和次数，如果是一个线程自选时间较长就直接进入阻塞，第二个优化是：引入锁消除，就是jvm会把不会出现线程安全的地方但加了锁的代码消除加锁，减少线程切换消耗，第三个优化是：锁粗化，同一个线程会频繁获取同一个锁，出现这种情况时，会自动帮我们提升锁的粒度，减少竞争锁的次数。

在jdk1.6之后，synchronized有一个锁升级的概念之前是直接阻塞，从最开始的偏向锁到轻量级锁到重量级锁依次进行升级：首先是偏向锁：在共享对象的对象头记录下当前的线程id（使用cas的方式 cas成功），下次如果还是这个id就不用加锁直接进入，如果有其他线程cas的来竞争，就升级为轻量级锁，轻量级锁：当前线程会保存锁对象（共享资源）的markword信息，并且把当前线程的lockrecod记录到锁对象的头里面（cas自旋的方式），解锁，把线程里面记录的锁对象信息写回加锁的对象中（cas方式），在解锁之前如果其他线程也来加锁，先cas自选，自旋时间到了之后如果还未获取锁，升级锁为重量级锁采用阻塞方式获取锁。

put方法是如果当前tongu桶没有数据，就cas的方式加入头结点，保证只有一个线程成功，如果有不为空，则加Synchronized进行put,如果元素个数大于8则变为红黑树。