腾讯一面:40亿QQ号,不超过1G内存,如何去重?

前言

大家好,我是田螺.

分享一道网上很火的腾讯面试题:40亿的QQ号,如何去重,1G的内存. 不过,有腾讯上班的朋友说,我们没出过这种面试题~ 哈哈~

哈哈,anyway,这道题还是很有意思的. 它是一个非常经典的海量数据去重问题,并且做了内存限制,只能1G.本文跟大家探讨一下.

1. 常规思路

我们日常开发中,如果谈到去重,最容易想到的就是放到HashSet,直接放到HashSet就好:

Set<Long> qqSet = new HashSet<>();
qqSet.add(qqNumber); // 自动去重

但是呢,是有个1G的内存限制的! 如果放到HashSet,那40亿的QQ数据,都是在内存中的,我们来算一下,40亿的QQ,要多大的内存:

如果每个QQ号是64位整数(8字节),那么40亿个QQ号的总存储量为:

40亿 * 8字节 = 320亿字节
转化位KB 32,000,000,000 字节/1024 = 31,250,000 KB
KB转化为MB 31,250,000 KB/ 1024 ≈ 30,517.578125 MB
MB转化为GB  30,517.578125 MB/ 1024 ≈ 29.8023223876953125 GB

那就是30GB左右,如果每个QQ号码是32位整数(4字节),则是15GB左右. 显然,都远超1GB的内存.

因此,直接放到HashSet并不可行.

因此,这道题我们需要换个思路,就是在内存有限的情况下,如何实现去重? 我们可以考虑一种更高效的数据结构来处理这个问题。

我们可以考虑BitMap(位图)来解决这个问题.

2. BitMap

2.1 BitMap 到底是什么

BitMap(位图)是一种非常高效的数据结构,特别适合处理大规模数据的去重和查询问题。它的基本思想是使用一个bit位来表示一个数字是否存在。

例如,如果我们有一个长度为10的BitMap,那么它可以表示数字0到9是否存在:

  • 如果BitMap的第0位是1,表示数字0存在;
  • 如果BitMap的第1位是1,表示数字1存在;
  • 如果BitMap的第2位是1,表示数字2存在;

以此类推~

数字9表示的BitMap如下:

如果用BitMap,比如我要记录的QQ号码分别是9、5、2、7, 那么BitMap表示为

显然只需要一个10位就可以表示,如果用传统方法来记录,一个整型4字节,4个QQ号码就是,44=16字节,然后一个字节8位,那就是 168=128位啦~. 可以发现用BitMap 可以大大节省存储空间.

机-会

技术大厂,前端-后端-测试,新一线和一二线城市等地均有机-会,感兴趣可以试试。待遇和稳定性都不错~

2.2 用BitMap给40亿QQ去重

2.2.1 使用BitMap,40亿的QQ是否超过1GB内存

既然BitMap 可以大大节省存储空间,我们用BitMap来给40亿QQ去重,看看会不会超1G的内存.

我们来一起估算一下, 因为要40亿的QQ,那我们申请一个足够大的BitMap,假设就是40亿的位,那内存大概就是:

4,000,000,000/8 = 500,000,000 
500,000,000/1024/1024/1024 ≈ 0.466GB

可以发现,只需要0.466GB的内存就足够啦~ 在内存这方面,是符合不超过1GB的限制的~

2.2.2 使用BitMap,给40亿QQ 去重流程

  1. 首先,初始化好40亿位的BitMap
  2. 其次,遍历这40亿的QQ,把每个QQ号码映射到BitMap中,给对应位置的bit,设置为1

比如,假设有个QQ号码为326443281,那么就在BitMap的对应位置,设置为1

  1. 遍历BitMap,收集所有设置为1的位对应的QQ号码,即为去重后的QQ号码。

2.3 BitMap去重的简单代码实现

给大家来个简单的代码模拟吧:

import java.util.*;

public class QQDeduplication {

    // 位图的大小为 4,294,967,296 bits,即 0.5 GB
    private static final long BITMAP_SIZE = 1L << 32; // 2^32
    private static final int BYTE_SIZE = 8; // 每个字节有8位

    private static List<Long> deduplicateQQNumbers(long[] qqNumbers) {
        // 创建位图,使用字节数组
        byte[] bitmap = new byte[(int) (BITMAP_SIZE / BYTE_SIZE)];

        // 更新位图
        for (long qqNumber : qqNumbers) {
            if (qqNumber >= 0 && qqNumber < BITMAP_SIZE) {
                // 计算字节索引和位索引
                int index = (int) (qqNumber / BYTE_SIZE);
                int bitPosition = (int) (qqNumber % BYTE_SIZE);
                // 设置对应的位
                bitmap[index] |= (1 << bitPosition);
            }
        }

        // 收集去重后的QQ号码
        List<Long> uniqueQQNumbers = new ArrayList<>();
        for (int i = 0; i < bitmap.length; i++) {
            for (int j = 0; j < BYTE_SIZE; j++) {
                if ((bitmap[i] & (1 << j)) != 0) {
                    long qqNumber = (long) i * BYTE_SIZE + j;
                    uniqueQQNumbers.add(qqNumber);
                }
            }
        }

        return uniqueQQNumbers;
    }
}

2.4 BitMap的优缺点

我们使用一种数据结构去解决问题,那肯定要知道它的优缺点对吧.

Bitmap的优点

  • 空间效率高

相比哈希表存储原始数据,Bitmap仅用1位/元素。对于密集数据(如连续QQ号),空间利用率极高。

  • 操作非常高效

插入和查询均为O(1)复杂度,位运算速度快,适合海量数据实时处理。

  • 去重逻辑简单

只需遍历数据,置位存在标记,无需复杂结构。

Bitmap的缺点

  • 存储空间依赖值域范围

若值域范围大但稀疏(如QQ号上限远大于实际数量),空间浪费严重。例如,若QQ号上限为1万亿,需125GB内存,难以承受。

  • 无法存储额外信息,只能记录有还是没有

仅记录是否存在,无法保存出现次数等元数据。

最后

有些伙伴认为,使用布隆过滤器也可以实现,40亿的QQ号,不超过1G的内存,进行去重.大家觉得呢? 欢迎评论区留言讨论哈. 希望大家都找到心仪的offer ~~

BitMap 的存储空间与值域强相关

BitMap 的存储空间需求直接取决于 值域的大小,而不是实际数据的数量。

值域:指数据可能的取值范围(如 QQ 号的最小值和最大值之间的范围)。

存储空间:BitMap 需要为值域中的每一个可能值分配一个 bit 位,无论该值是否实际存在。

——转载自:捡田螺的小男孩

#腾讯求职进展汇总#
全部评论
腾讯的同学说,他们没出过这道题,哈哈哈
点赞 回复 分享
发布于 2025-12-20 15:55 重庆
这种题我面虾皮的时候被问过,我是IP去重,当时硬是没有想到位图,气死了
点赞 回复 分享
发布于 2025-12-18 16:07 广东

相关推荐

2025-12-21 15:20
门头沟学院 Java
1.实习介绍2你们公司jdk版本用的是多少,为什么用这个版本4.能给我讲一下G1和传统比如CMS的区别是什么5.讲讲并发编程经验吧讲一下java当中怎么处理线程安全问题7.说一下jvm它为什么要这么去划分内存区域8Redis用过吧,聊一下缓存穿透是什么以及怎么解决9你刚刚提到两点,一个是布隆过滤器,布隆过滤器有什么坑,可能存在的问题是什么10.其实里面有个初始化的问题。布隆过滤器很难初始化比如说你有一亿的商品数据对不对?你要初始化,用过滤器,实际上很耗时的,这个该怎么来解决呢11.好,那我觉得还有第二个的话它只能追加,不能修改和删除。对吧,想一想有什么办法解决吗12.然后说回存null值的问题,他其实问题很多,比如增加业务流程的复杂度,因为你排查问题的时候,其实有可能不经意的就命中了一个缓存,对吧。另外的话就有可能导致缓存雪崩,因为它的key如果是一个变量,别人在攻击你的时候。就可能储存大量的这样的无效信息。第二个的话就是它其实不抗并发,第三个也有很多问题,你列举一下在用null的时候有没有发现过其他的问题?或者思考一下它还有可能存在哪些问题还有针对我上面提到的它有这么多这些问题为什么还要用它呢13你刚刚说对业务数据更新不友好,这个怎么不友好了,展开讲讲14聊聊业务项目吧,聊聊清结算吧给你整体介绍一下15实时有实时计价的是吧?就实时要返回是用到了mq是吧,有没有实时RPC部分呢,就不走消息异步的部分比如调用方需要实时的拿到这一笔这样的金额这种16.你们这个科目是什么,这个科目的话是按照什么样的配置和维度进行拆的。17.这些维度有优先级吗?或者是有层次的划分吗18既然有他们是共享的么,那我觉得这种的设计有一个问题,举个例子,你的短信的配置和信贷的配置实际上是一份规则配置,对吧?共享的话,最难解决的一个问题是分母问题,我不知道你能不能理解就是什么意思呢?你没有办法清楚的描述跑在你这个平台上的业务场景有多少个。也就比较难以进行资损防控,就比如说上游可能变了一个字段,对吧,你就匹配到另外一套规则了。因为有优先级,有很多的规则混合在一起了,然后另外一个场景也确实有,它不该,它可能本应该匹配a,但是它却匹配了B,对不对?这种问题的话一般是要怎么解决呢19.你说的是事前的部分,那它根本上要在架构上解决,你觉得应该怎么解决20.手撕:小于n的最大数
点赞 评论 收藏
分享
评论
4
16
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务