bitmap与布隆过滤器bitmap和布隆过滤器

大家好，如果您还对bitmap与布隆过滤器不太了解，没有关系，今天就由本站为大家分享bitmap与布隆过滤器的知识，包括bitmap和布隆过滤器的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！

本文目录

bitmap和布隆过滤器的区别细嚼慢咽布隆过滤器(Bloom Filter)BitMap原理与实现5、垃圾回收机制bitmap和布隆过滤器的区别bitmap更适合用于数字比较。

比如比较两个数组是否有重叠，我们把第一个数组中的1,2,5,7,11分别映射到bitmap位置中

布隆过滤器适合非数字比较（有误判）

细嚼慢咽布隆过滤器(Bloom Filter)

在上篇【链接】中，我们借助Java的BitSet源码尝试着理解了下BitMap算法，但是有一个很致命的劣势没有解决，那就是很尴尬的数据碰撞问题。

啥意思呢，再次解释一下下，BitMap中我们只是很简单地初始化了一个Long数组，然后使用一个个小小的bit位来表示一个数据的存在与否，但是其中必然会面对哈希碰撞问题。

我们画张简图来回顾下BitMap算法。

如上图所示，hashfunction均为f1，数据A和D指向的位是1，所以肯定是存在的，而B和C指向的都是同一个位，所以哈希碰撞就是这样很容易地产生了。

即：位上无元素则表示该数据肯定不存在，位上有元素则只能表示该数据可能存在。

有弊端总有解决之道，此处正好引入本文主要介绍的一种算法：布隆过滤器，英文名为BloomFilter，下文简称BF算法。

同样，我们还是先画一张简图来直观地认识下BF算法。

由上图我们可以看出，此时的A、B、C、D四个数据各自经过f1和f2方法进行两次hash算法，然后

救援女同学小游戏攻略

小结：BF算法虽然在一定程度上减少了BitMap算法中的哈希碰撞，但是终言之，只是减少而已，没法完全避免，就像上文举的案例2一样。

通过上面的图，其实很容易看出，上图中hashfunction的数量是2，假如我们计算3次呢？或者4次甚至更多呢？诚然这可以更进一步避免数据的碰撞问题，但是太多的话却适得其反。

所以介绍优化之前我们先小结下BF算法的劣势，因为优化都是基于某些劣势来进行的：

所以，针对上面的两个点，我们逐个来突破下：

1、关于误判率

BF算法优劣的影响因素，其实很容易就可以联想到，一个是根据插入的数据总量（n）来计算出最合适的位数组的大小（m）和hash函数的个数（k），还有一个便是最优的误判率（使用P(error)表示）的选择问题。

比如：我们假设P为0.01，此时最优的m应大概是n的13倍，而k，应大概为8。

详细的证明过程见下文。

2、关于元素删除的需求

因为数据对应的位会牵动其它的数据，所以BF是不可以删除位数据的，那么如果有这样的需求呢？可以使用coutingBloomFilter来解决，大致思路就是使用一个counter数组来代替位数组。

什么意思呢？简言之就是在原来的BF算法的位上面，不再是用简单的0或1来表示了，而是存储该位上面的数据总量，比如有两个数据经过hashfunction计算都有指向同一个位，则将该位标记为2，代表有两个数据，当删除其中一个数据时，只需要将该位上面的2调整为1即可，如此便不再影响其它数据的正确性。

BF算法虽然有着一定的缺点（主要是误判率），但是它的优点更为突出，所以应用场景也是很广的。

比如我们在爬虫业务下，有很多的URL，我们可以通过BF算法来判断每个URL是否已经被我们的爬虫程序处理过。

再比如邮箱服务中垃圾邮件的过滤策略，由于垃圾邮件是海量的，我们不可能使用一个很完整的散列映射来标记每一个垃圾邮箱的地址，此处可以使用BF算法来标记，从而节约了容量。

另外，BF算法在很多开源框架中也都有相应的实现，例如：

1、误判概率的证明和计算

假设布隆过滤器中的hashfunction满足simpleuniformhashing假设：每个元素都等概率地hash到m个slot中的任何一个，与其它元素被hash到哪个slot无关。若m为bit数，则对某一特定bit位在一个元素由某特定hashfunction插入时没有被置位为1的概率为：

现在考虑query阶段，若对应某个待query元素的kbits全部置位为1，则可判定其在集合中。因此将某元素误判的概率为：

从上式中可以看出，当m增大或n减小时，都会使得误判率减小，这也符合直觉。现在计算对于给定的m和n，k为何值时可以使得误判率最低。设误

红茶小青柑功效与作用

下面求最值：

这说明了若想保持某固定误判率不变，则布隆过滤器的位数m与添加的元素数n应该是线性同步增加的。

2、设计和应用布隆过滤器的方法

应用时首先要先由用户决定添加的元素数n和期望的误差率P。这也是一个设计完整的布隆过滤器需要用户输入的仅有的两个参数，之后的所有参数将由系统计算，并由此建立布隆过滤器。

系统首先要计算需要的内存大小mbits:

这里需要特别注意的是，9.6bits/element不仅包含了被置为1的k位，还把包含了没有被置为1的一些位数。此时的

此概率为某bit位在插入n个元素后未被置位的概率。因此，想保持错误率低，布隆过滤器的空间使用率需为50%。

代码比较长，文章中暂不完整展示，更完整的代码demo详见【链接】。

下面列出了一小部分代码块，作用是根据插入的元素数量和过滤器容器的大小来计算实际的误报率：

BitMap原理与实现比较经典的问题是：在只能够使用2G的内存中，如何完成以下操作：

①：对10亿个不重复的整数进行排序。

②：找出10亿个数字中重复的数字。

无论是排序还是找重复的数字都需要将这10亿个数字加入到内存中在去进行操作，很明显，题目给出的2G内存限制说明了在这样的场景下是不能够将所有数都加入到内存中的

1000000000*4/（1024*1024*1024）=3.725G

那么这时候就需要用到BitMap结构了

bitMap使用一个bit为0/1作为map的value来标记一个数字是否存在,而map的key值正是这个数字本身。

相比于一般的数据结构需要用4个byte去存储数值本身，相当于是节省了4*8：1=32倍的内存空间

bitMap不一定要用bit数组,可以使用int,long等等的基本数据类型实现，因为其实质都是在bit位上存数据，用哪种类型只是决定了最终实现出来的BitMap的内置数组中单个元素存放数据的多少

    例如：java中的BitSet使用Long数组

BitMap的实现当然少不了位运算，先来明确几个常见位运算，这是实现BitMap的基础：

set(bitIndex):添加操作

    1.确定该数处于数组中的哪个元素的位上

    intwordIndex=bitIndex>>5;

因为我用的是int[]实现，所以这里右移5位（2^5=32）

    2.确定相对于该元素中的位置偏移

    intbitPosition=bitIndex&((1<<5)-1);

这里相当于是bitIndex%（1<<5）的取模运算，因为当取模运算的除数是2的次幂，所以可以使用以下的位运算来计算，提升效率（对比HashMap的容量为什么总是2的幂次方的问题，HashMap求下标时也是使用hash&(n-1)）

tips:位运算的优先级是低于+,-等等的，所以要加上括号,防止发生不可描述的错误

    3.将该位置1

    bits[wordIndex]|=1<<bitPosition;

相当于是将指定位置处的bit值置1，其他位置保持不变，也就是将以这个bitIndex为key的位置为1

tips:这里是参考了网上的各位大佬的文章,取余+按位或，又对比了下BitSet的源码：

    words[wordIndex]|=(1L<<bitIndex);

没有取余操作，直接|，这两个一样吗？答案当然是一样的

举个栗子：

    1<<148==1<<20    

    1L<<125==1L<<61

即对于int和long型数据，直接左移其位数相当于是附带了对其的取模操作

总结：使用Bit-map的思想，我们可以将存储空间进行压缩，而且可以对数字进行快速排序、去重和查询的操作。

BloomFliter是Bit-map思想的一种扩展，它可以在允许低错误率的场景下，大大地进行空间压缩，是一种拿错误率换取空间的数据结构

当一个元素加入布隆过滤器中的时候，会进行哪些操作：

当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行哪些操作：

然后，一定会出现这样一种情况：不同的字符串可能哈希出来的位置相同（可以适当增加位数组大小或者调整我们的哈希函数来降

股市熊市是什么意思

总结来说就是：布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。

BloomFilter的应用:常用于解决缓存穿透等场景。

5、垃圾回收机制JVM的垃圾回收机制主要涉及三个方面的问题：

1.JVM有哪些垃圾回收算法？各自有什么优势？

2.CMS垃圾回收器是如何工作的？有哪些阶段？

3.服务卡顿的元凶到底是什么？

Java不用程序来管理内存的回收，但这些内存是如何回收的？

其实，JVM有专门的线程在做这件事情。当内容空间达到一定条件时，会自动触发，这个过程就叫GC，负责GC的组件被称为垃圾回收器。JVM规范没有规定垃圾回收器怎么实现，它只需要保证不要把正在使用的对象回收掉就可以。在现在的服务器环境中，经常被使用的垃圾回收器有CMS和G1，但JVM还有其它几个常见的垃圾回收器。

GC的过程是先找到活跃的对象，然后把其他不活跃的对象判定为垃圾，然后删除，所以GC只与活跃的对象有关，和堆的大小无关。

接下来学习下分代垃圾回收的内存划分和GC过程，再有就是常见的垃圾回收器。

这篇比较重要，因为几乎所有的垃圾回收器都是在这些基本思想上演化出来的。

GC的第一步就是找出活跃的对象，根据GCRoots遍历所有的可达对象，这个过程就叫作标记。

如上图所示，圆圈代表对象，绿色的代表GCRoots，红色的代表可以追溯到的对象，标记后，有多个灰色的圆圈，代表都是可被回收的对象。

清除阶段就是把未被标记的对象回收掉。

这种方式有一个明显的问题，会产生碎片空间。

比如申请了1k、2k、3k、4k、5k的内存

由于某些原因，2k和4k的内存不再使用，交给垃圾回收器回收。

解决碎片问题，就需要进行内存整理。

有一个思路就是提送一个对等的内存空间，将存活的对象复制过去，然后清除员内存空间。

在程序设计时，一般遇到扩缩容或者碎片整理问题时，复制算法都是非常有效的。比如：HashMap的扩容使用的是同样的思路，Redis的rehash也是如此。

整个过程如下图

这种方式看似完美，解决了碎片问题，但是弊端也非常明显，它浪费了一半的内存空间来做这个事情，如果原本资源就有限，这就是一种无法容忍的浪费。

不用分配一个对等的空间也是可以完成内存的整理工作。

可以把内存想象成一个非常大的数组，根据随机的index删除了一些数据，那么对数组的清理不需要另外一个数组来进行支持的，使用程序就可以。

主要思路是移动所有的存活对象，且按照内存地址顺序依次排列，然后将末端内存地址以后的内存全部收回。

对象的引用关系一般是非常复杂的，从效率上来说，一般整理算法是要低于复制算法的。

JVM的垃圾回收器，都是对以上几种朴素算法的结合使用，简单看一下它们的特点：

效率一般，缺点是回造成内存碎片的问题。

复制算法是所有算法里面效率最高的，缺点是造成一定的空间浪费。

效率比前两者要差，但没有空间浪费，也消除了内存碎片问题。

所以没有最优的算法，只有最合适的算法。

JVM是计算节点，而不是存储节点。最理想的情况就是对象使用完成之后，它的生命周期立马就结束了，而那些被频繁访问的资源，我们希望它能够常驻在内存里。

对象大致可以分为两类：

1.大部分对象的生命周期都很短

2.其他对象则很可能会存活很长时间

现在的垃圾回收器都会在物理上或者逻辑上，把这两类对象进行分区。我们把死的快的对象所占的区域叫年轻代（YoungGeneration）。把其他活的长的对象所占的区域叫作老年代（OldGeneration），老年代在有时候会叫作TenuredGeneration。

年轻代使用的垃圾回收算法是复制算法，因为年轻代发生GC后，会有非常少的对象存活，复制这部分对象是非常高效的

年轻代的内部分区

如图所示，年轻代分为：一个伊甸园空间（Eden），两个幸存者空间（Survivor）。

当年轻代中的Eden区分配满的时候，就会触发年轻代的GC（MinorGC），具体过程如下

1.在Eden区执行了第一次GC之后，存活的对象会被移动到其中一个Suvivor分区（from）；

2.Eden区再次GC，这是会采用复制算法，将Eden和from区一起清理，存活的对象会被复制到to区；接下来只需要清空from区就可以了

在整个过程中总会有一个Survivor分区是空置的。Eden、from、to的默认比例是8:1:1,所以只会造成10%的空间浪费。

这个比例是由参数-XX:SurvivorRatio进行配置的（默认为8）。

补充下不常提到的TLAB。TLAB全称是ThreadLocalAllocationBuffer，JVM默认给每个线程开辟一个buffer区域，用来加速对象分配。这个buffer就放在Eden区中。

这个道理和Java语言中的ThreadLocal类似，避免了对公共区的操作，以及一些锁竞争。

老年代一般使用"标记-清除"、"标记-整理"算法。因为老年代的对象存活率一般是比较高的，空间又比较大，拷贝起来并不划算，不如采取就地收集的方式。

对象进入老年代的途径分类

如果对象够老，会通过"提升"进入老年代。关于对象老不老，是通过它的年龄来判断的。每发生一次MinorGC，存活下来的对象年龄都会加1,直到达到一定的阀值，就会提升到老年代，

这些对象如果变的不可达，直到老年代发生GC的时候才会被清理掉。

这个阀值可以通过参数-XX:+MaxTenuringThreshold进行配置，最大值是15，因为它是用4bit存储的（所以把这个值调的很大的文章，是没有什么根据的）。

每次存活的对象，都会放入其中一个幸存区，这个区域默认比例是10%，但无法保证每次存活的对象都小于10%，当Survivor空间不够，就需要依赖其它内存（老年代）进行分配担保。这个时候，对象也会直接在老年代上分配。

超出某个大小的对象直接在老年代分配，通过参数设置-XX:PretenureSizeThreshold进行配置的，默认为0，默认全部在Eden区进行分配。

有的垃圾回收算法，并不要求age必须达到15才能晋升到老年代，它会使用一些动态的计算方法。比如，如果幸存区中相同年龄对象大小的和，大于幸存区的一半，大于或者等于age的对象将会直接进入老年代。

这些动态判定一半不受外部控制

对象的引用关系时一个巨大的网状，有的对象在Eden区，有的可能在老年代，那么这种跨代的引用是如何处理的呢？由于MinorGC是单独发生的，如果一个老年代的对象引用了它，如何确保能够让年轻代的对象存活呢？

对于是、否的判断，我们通常都会用到Bitmap（位图）和布隆过滤器来加快搜索的速度，需要另外再学习下（如果不知道这两个概念的话）

JVM也是用了类似的方法。其实，老年代是被分成众多的卡页（CardPage）的（一般数量是2的次幂）

卡表（CardTable）就是用于标记卡页状态的一个集合，每个卡表对应一个卡页。

如果年轻代有对象分配，而且老年代有对象指向这个新对象，那么这个老年代对象所对应内存的卡页就会被标识为dirty，卡表只需要非常小的存储空间就可以保留这些状态，垃圾回收时，就可以先读这个卡表，进行快速的判断。

接下来学习HotSpot的几个垃圾回收器，每种回收器都有各自的特点。在平常的GC优化时，一定要清楚现在用的是那种垃圾回收器。

下图包含了年轻代和老年代的划分，方便接下来的学习参考

处理GC的只有一条线程，并且在垃圾回收的过程中暂停一切用户线程。

这是最简单的垃圾回收器，虽然简单，但十分高效，通常用在客户端应用上。因为客户端应用不会频繁创建很多对象，用户也不会感觉出明显的卡顿。相反，它使用的资源更少，也更轻量级。

ParNew是Serial的多线程版本，由多条GC线程并行地进行垃圾清理。清理过程依然要停止用户线程。追求低停顿时间，与Serial唯一区别就是使用了多线程进行垃圾回收，在多CPU环境下性能比Serial会有一定程度的提升；但线程切换需要额外的开销，因此在单CPU环境中表现不如Serial。

另一个多线程版本的垃圾回收器。但与ParNew是有区别的

1.ParallelScavenge:追求CPU吞吐量，能够在较短时间内完成指定任务，适合没有交互的后台计算，弱交互强计算。

2.ParNew:追求降低用户停顿时间，适合交互式应用，强交互弱计算。

与年轻代的Serial垃圾回收器对应，都是单线程版本，同样适合客户端使用。

年轻代Serial，使用复制算法。

老年代的OldSerial，使用标记-整理算法。

ParallelOld回收器是ParallelScavenge的老年代版本，追求CPU吞吐量。

CMS(ConcurrentMarkSweep)回收器是以获取最短GC停顿时间为目标的收集器，它在垃圾回收时使得用户线程和GC线程能够并发执行，因此在垃圾回收过程中用户也不会感到明显的卡顿。

长期看来，CMS垃圾回收器，是要被G1等垃圾回收器替换掉的，在Java8之后，使用它将会抛出一个警告！

除了上面几个垃圾回收器，我们还有G1、ZGC等更加高级的垃圾回收器，它们都有专门的配置参数来使其生效。

通过-XX：PrintCommandLineFlags参数，可以查看当前Java版本默认使用的垃圾回收器。在Java13中，默认的回收器就是G1。

以下是一些配置参数：

1.-XX:+UseSerialGC年轻代和年老代回收器

2.-XX:+UseParNewGC年轻代使用ParNew，老年代使用SerialOld。

3.-XX:+UseParallelOldGC年轻代和老年代哦都市用并行回收器。

4.-XX:+UseConcMarkSweepGC表示年轻代使用ParNew，老年代使用CMS。

5.-XX:+UseG1GC使用G1垃圾回收器

6.-XX:+UseZGC使用ZGC垃圾回收器

这些垃圾回收器的关系还是比较复杂的，请看下图

目前Java8还是主流使用版本，从Java8升级到高版本的Java体系是有一定成本的，所以CMS垃圾回收器还会持续一段时间

抛个问题，如果在垃圾回收的时候，又有新的对象进入怎么办？

为了保住程序不乱套，最好的办法就是暂停用户的一切线程，也就是在这段时间，是不能new对象的，只能等待，表象是在JVM上就是短暂的卡顿，什么都干不了，这个现象叫作StopTheWorld。

标记阶段，大多数是要STW的。如果不暂停用户进程，在标记对象的时候，有可能有其它用户线程会产生一些新的对象和引用，造成混乱。

现在的垃圾回收器，都会尽量去减少这个过程。但即使最先进的ZGC回收器，也会有短暂的STW过程。我们要做的就是在现有基础设施上，尽量减少GC停顿。

举例说明下

某个高并发服务的峰值流量是10万次/秒，后面有10台负载均衡的机器，那么每台机器平均下来需要1w/s。假如某台机器在这段时间内发生了STW，持续了一秒，那么至少需要10ms就可以返回的1万个请求，需要至少等待1秒。

在用户那里的表现就是系统发生了卡顿。如果我们的GC非常的频繁。这种卡顿就会特别的明显，严重影响用户体验。

虽然说Java为我们提供了非常棒的自动内存管理机制，但也不能滥用，因为它是有STW硬伤的。

介绍了堆的具体分区，年轻代和老年代。介绍了多个常用的垃圾回收器，不同的垃圾回收器有不同的特点。各种垃圾回收器都是为了解决头疼的STW问题，让GC时间更短，停顿更短，吞吐量更大。

接触了很多名词，总结如下

1.Mark

2.Sweep

3.Copy

4.Compact

1.Younggeneration

2.Survivor

3.Eden

4.OldGeneration|TenuredGeneration

5.GC

--1.MinorGC

--2.MajorGC

1.weakgenerationalhypothesis

2.分配担保

3.提升

4.卡片标记

5.STW

关于bitmap与布隆过滤器和bitmap和布隆过滤器的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。