ConcurrentHashMap的源码分析-resizeStamp

这块逻辑要理解起来，也有一点复杂。

resizeStamp用来生成一个和扩容有关的扩容戳，具体有什么作用呢？我们基于它的实现来做一个分析

static final int resizeStamp(int n) { 
	return Integer.numberOfLeadingZeros(n) | (1 << (RESIZE_STAMP_BITS - 1)); 
} 

Integer.numberOfLeadingZeros 这个方法是返回无符号整数n最高位非0位前面的0的个数

比如10的二进制是 0000 0000 0000 0000 0000 0000 0000 1010

那么这个方法返回的值就是28 

根据resizeStamp的运算逻辑，我们来推演一下，假如n=16，那么resizeStamp(16)=32796转化为二进制是

[0000 0000 0000 0000 1000 0000 0001 1100]

接着再来看,当第一个线程尝试进行扩容的时候，会执行下面这段代码 

U.compareAndSwapInt(this, SIZECTL, sc, (rs << RESIZE_STAMP_SHIFT) + 2) 

rs左移16位，相当于原本的二进制低位变成了高位1000 0000 0001 1100 0000 0000 0000 0000 

然后再+2 =1000 0000 0001 1100 0000 0000 0000 0000+10=1000 0000 0001 1100 0000 0000 0000 0010

高16位代表扩容的标记、低16位代表并行扩容的线程数 高RESIZE_STAMP_BITS位 低RESIZE_STAMP_SHIFT位 扩容标记 并行扩容线程数

这样来存储有什么好处呢？ 

1. 首先在CHM中是支持并发扩容的，也就是说如果当前的数组需要进行扩容操作，可以由多个线程来共同负责，这块后续会单独讲

2. 可以保证每次扩容都生成唯一的生成戳，每次新的扩容，都有一个不同的n，这个生成戳就是根据n来计算出来的一个数字，n不同，这个数字也不同

第一个线程尝试扩容的时候，为什么是+2 

因为1表示初始化，2表示一个线程在执行扩容，而且对sizeCtl的操作都是基于位运算的，所以不会关心它本身的数值是多少，只关心它在二进制上的数值，而sc+1会在低16位上加1。