本文主要内容是分析JDK中的BitMap实现之java.util.BitSet的源码实现,基于JDK11编写,其他版本的JDK不一定合适。
文中的图比特低位实际应该是在右边,但是为了提高阅读体验,笔者把低位改在左边了。
什么是BitMap
BitMap,直译为位图,是一种数据结构,代表了有限域中的稠集(Dense Set),每一个元素至少出现一次,没有其他的数据和元素相关联。在索引,数据压缩等方面有广泛应用(来源于维基百科词条)。计算机中1 byte = 8 bit,一个比特(bit,称为比特或者位)可以表示1或者0两种值,通过一个比特去标记某个元素的值,而KEY或者INDEX就是该元素,构成一张映射关系图。因为采用了Bit作为底层存储数据的单位,所以可以极大地节省存储空间。
在Java中,一个int类型的整数占4字节,16比特,int的最大值也就是20多亿(具体是2147483647)。假设现在有一个需求,在20亿整数中判断某个整数m是否存在,要求使用内存必须小于或者等于4GB。如果每个整数都使用int存储,那么存放20亿个整数,需要20亿 * 4byte /1024/1024/1024约等于7.45GB,显然无法满足需求。如果使用BitMap,只需要20亿 bit内存,也就是20亿/8/1024/1024/1024约等于0.233GB。在数据量极大的情况下,数据集具备有限状态,可以考虑使用BitMap存储和进行后续计算等处理。现在假设用byte数组去做BitMap的底层存储结构,初始化一个容量为16的BitMap实例,示例如下:
可见当前的byte数组有两个元素bitmap[0](虚拟下标为[0,7])和bitmap[1](虚拟下标为[8,15])。这里假定使用上面构造的这个BitMap实例去存储客户ID和客户性别关系(比特为1代表男性,比特为0代表女性),把ID等于3的男性客户和ID等于10的女性客户添加到BitMap中:
由于1 byte = 8 bit,通过客户ID除以8就可以定位到需要存放的byte数组索引,再通过客户ID基于8取模,就可以得到需要存放的byte数组中具体的bit的索引:
ID等于3的男性客户
逻辑索引 = 3
byte数组索引 = 3 / 8 = 0
bit索引 = 3 % 8 = 3
=> 也就是需要存放在byte[0]的下标为3的比特上,该比特设置为1
ID等于10的女性客户
逻辑索引 = 10
byte数组索引 = 10 / 8 = 1
bit索引 = 10 % 8 = 2
=> 也就是需要存放在byte[1]的下标为2的比特上,该比特设置为0
复制代码
然后分别判断客户ID为3或者10的客户性别:
如果此时再添加一个客户ID为17的男性用户,由于旧的BitMap只能存放16个比特,所以需要扩容,判断byte数组中只需新增一个byte元素(byte[2])即可:
原则上,底层的byte数组可以不停地扩容,当byte数组长度达到Integer.MAX_VALUE,BitMap的容量达到最大值。
BitSet简单使用
java.util.BitSet虽然名字上称为Set,但实际上它就是JDK中内置的BitMap实现,1这个类算是一个十分古老的类,从注释上看是JDK1.0引入的,不过大部分方法是JDK1.4之后新添加或者更新的。以前一小节的例子基于BitSet做一个Demo:
public class BitSetApp {
public static void main(String[] args) {
BitSet bitmap = new BitSet(16);
bitmap.set(3, Boolean.TRUE);
bitmap.set(11, Boolean.FALSE);
System.out.println("Index 3 of bitmap => " + bitmap.get(3));
System.out.println("Index 11 of bitmap => " + bitmap.get(11));
bitmap.set(17, Boolean.TRUE);
// 这里不会触发扩容,因为BitSet中底层存储数组是long[]
System.out.println("Index 17 of bitmap => " + bitmap.get(17));
}
}
// 输出结果
Index 3 of bitmap => true
Index 11 of bitmap => false
Index 17 of bitmap => true
复制代码
API使用比较简单,为了满足其他场景,BitSet还提供了几个实用的静态工厂方法用于构造实例,范围设置和清除比特值和一些集合运算等,这里不举例,后面分析源码的时候会详细展开。
BitSet源码分析
前文提到,BitMap如果使用byte数组存储,当新添加元素的逻辑下标超过了初始化的byte数组的最大逻辑下标就必须进行扩容。为了尽可能减少扩容的次数,除了需要按实际情况定义初始化的底层存储结构,还应该选用能够"承载"更多比特的数据类型数组,因此在BitSet中底层的存储结构选用了long数组,一个long整数占64比特,位长是一个byte整数的8倍,在需要处理的数据范围比较大的场景下可以有效减少扩容的次数。后文为了简化分析过程,在模拟底层long数组变化时候会使用尽可能少的元素去模拟。BitSet顶部有一些关于其设计上的注释,这里简单罗列概括成几点:
BitSet是可增长比特向量的一个实现,设计上每个比特都是一个布尔值,比特的逻辑索引是非负整数
BitSet的所有比特的初始化值为false(整数0)
BitSet的size属性与其实现有关,length属性(比特表的逻辑长度)与实现无关
BitSet在设计上是非线程安全,多线程环境下需要额外的同步处理
按照以往分析源码的习惯,先看BitSet的所有核心成员属性:
public class BitSet implements Cloneable, java.io.Serializable {
// words是long数组,一个long整数为64bit,2^6 = 64,这里选取6作为words的寻址参数,可以基于逻辑下标快速定位到具体的words中的元素索引
private static final int ADDRESS_BITS_PER_WORD = 6;
// words中每个元素的比特数,十进制值是64
private static final int BITS_PER_WORD = 1 << ADDRESS_BITS_PER_WORD;
// bit下标掩码,十进制值是63
private static final int BIT_INDEX_MASK = BITS_PER_WORD - 1;
// 掩码,十进制值-1,也就是64个比特全是1,用于部分word掩码的左移或者右移
private static final long WORD_MASK = 0xffffffffffffffffL;
/**
* 序列化相关,略过
*/
private static final ObjectStreamField[] serialPersistentFields = {
new ObjectStreamField("bits", long[].class),
};
/**
* 底层的比特存储结构,long数组,同时也是序列化字段"bits"的对应值
*/
private long[] words;
/**
* 已经使用的words数组中的元素个数,注释翻译:在当前BitSet的逻辑长度中的word(words的元素)个数,瞬时值
*/
private transient int wordsInUse = 0;
/**
* 标记words数组的长度是否用户
*/
private transient boolean sizeIsSticky = false;
// JDK 1.0.2使用的序列化版本号
private static final long serialVersionUID = 7997698588986878753L;
// 暂时