concurrentHashMap的底层指导思想之前有提过,就是通过细化锁的粒度来优化并发情况下的锁冲突从而实现高性能的。这种思想在很多设计中都能看到,比如Innodb的行级锁概念。
jdk1.8之前,并发map通过引入segment来细化锁的粒度,就是把原本的数组分到多个不同的段里,每个段单独管理自己的数组,段与段之间不冲突,即使数组扩容也是段内部的数组扩容。
segment长度默认是16,可以构造时指定,后面不会变化,所以并发度主要还是看segment的个数了。数据越多并发冲突的概率越大
jdk1.8废弃了segment的概念,锁粒度更加的细化,直接给数组的链首或树根元素加锁。只要没有hash冲突就没有并发冲突。数据多了,数组会扩容,并发冲突的概率并没有变大