腾讯三面：40亿个QQ号码如何去重？

今天，我们来聊一道常见的考题，也出现在腾讯面试的三面环节，非常有意思：文件中有40亿个QQ号码，请设计算法对QQ号码去重，相同的QQ号码仅保留一个，内存限制1G。

这个题目的意思应该很清楚了，比较直白。为了便于大家理解，我来画个动图玩玩，希望大家喜欢。

能否做对这道题目，很大程度上就决定了能否拿下腾讯的offer，有一定的技巧性，一起来看下吧。

在原题中，实际有40亿个QQ号码，为了方便起见，在图解和叙述时，仅以4个QQ为例来说明。

另外，关注公号“终码一生”，回复关键词“资料”，获取视频教程和最新的面试资料！

1

方法一：排序

很自然地，最简单的方式是对所有的QQ号码进行排序，重复的QQ号码必然相邻，保留第一个，去掉后面重复的就行。

原始的QQ号为：

排序后的QQ号为：

去重就简单了：

可是，面试官要问你，去重一定要排序吗?显然，排序的时间复杂度太高了，无法通过腾讯面试。

2

方法二：hashmap

既然直接排序的时间复杂度太高，那就用hashmap吧，具体思路是把QQ号码记录到hashmap中：

mapFlag[123] = true 
mapFlag[567] = true 
mapFlag[123] = true 
mapFlag[890] = true

由于hashmap的去重性质，可知实际自动变成了：

mapFlag[123] = true 
mapFlag[567] = true 
mapFlag[890] = true

很显然，只有123，567，890存在，所以这也就是去重后的结果。

可是，面试官又要问你了：实际要存40亿QQ号码，1G的内存够分配这么多空间吗?显然不行，无法通过腾讯面试。

3

方法三：文件切割

显然，这是海量数据问题。看过很多面经的求职者，自然想到文件切割的方式，避免内存过大。

可是，绞尽脑汁思考，要么使用文件间的归并排序，要么使用桶排序，反正最终是能排序的。

既然排序好了，那就能实现去重了，貌似就万事大吉了。我只能坦白地说，高兴得有点早哦。

接着，面试官又要问你：这么多的文件操作，效率自然不高啊。显然，无法通过腾讯面试。

4

方法四：bitmap

来看绝招!我们可以对hashmap进行优化，采用bitmap这种数据结构，可以顺利地同时解决时间问题和空间问题。

在很多实际项目中，bitmap经常用到。我看了不少组件的源码，发现很多地方都有bitmap实现，bitmap图解如下：

这是一个unsigned char类型，可以看到，共有8位，取值范围是[0, 255]，如上这个unsigned char的值是255，它能标识0~7这些数字都存在。

同理，如下这个unsigned char类型的值是254，它对应的含义是：1~7这些数字存在，而数字0不存在：

由此可见，一个unsigned char类型的数据，可以标识0~7这8个整数的存在与否。以此类推：

• 一个unsigned int类型数据可以标识0~31这32个整数的存在与否。
• 两个unsigned int类型数据可以标识0~63这64个整数的存在与否。

显然，可以推导出来：512MB大小足够标识所有QQ号码的存在与否，请注意：QQ号码的理论最大值为2^32 - 1，大概是43亿左右。

接下来的问题就很简单了：用512MB的unsigned int数组来记录文件中QQ号码的存在与否，形成一个bitmap，比如：

bitmapFlag[123] = 1 
bitmapFlag[567] = 1 
bitmapFlag[123] = 1 
bitmapFlag[890] = 1

实际上就是：

bitmapFlag[123] = 1 
bitmapFlag[567] = 1 
bitmapFlag[890] = 1

然后从小到大遍历所有正整数(4字节)，当bitmapFlag值为1时，就表明该数是存在的。

而且，从上面的过程可以看到，自动实现了去重。显然，这种方式可以通过腾讯的面试。

1、SSM框架简介

SSM框架是Spring MVC ，Spring和Mybatis框架的整合，是标准的MVC模式，将整个系统划分为View层，Controller层，Service层，DAO层四层，使用Spring MVC负责请求的转发和视图管理，Spring实现业务对象管理，Mybatis作为数据对象的持久化引擎。

2、SSM框架各层介绍

2.1、持久层（Mybatis）：Dao层（mapper）

DAO层：DAO层主要是做数据持久层的工作，负责与数据库进行联络的一些任务都封装在此。

DAO层的设计首先是设计DAO的接口。

然后在Spring的配置文件中定义此接口的实现类。

然后就可在模块中调用此接口来进行数据业务的处理，而不用关心此接口的具体实现类是哪个类，显得结构非常清晰。

DAO层的数据源配置，以及有关数据库连接的参数都在Spring的配置文件中进行配置。

2.2、业务层（Spring）：Service层

Service层：Service层主要负责业务模块的逻辑应用设计。

首先设计接口，再设计其实现的类。

接着再在Spring的配置文件中配置其实现的关联。这样我们就可以在应用中调用Service接口来进行业务处理。

Service层的业务实现，具体要调用到已定义的DAO层的接口。

封装Service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性，程序显得非常简洁。

2.3、表现层（springMVC）：Controller层（Handler层）

Controller层：Controller层负责具体的业务模块流程的控制。

在此层里面要调用Service层的接口来控制业务流程。

控制的配置也同样是在Spring的配置文件里面进行，针对具体的业务流程，会有不同的控制器，我们具体的设计过程中可以将流程进行抽象归纳，设计出可以重复利用的子单元流程模块，这样不仅使程序结构变得清晰，也大大减少了代码量。

2.4、视图层：View层

View层：View层与控制层结合比较紧密，需要二者结合起来协同工发。View层主要负责前台jsp页面的表示。

3、SSM框架各层关系

DAO层、Service层这两个层次都可以单独开发，互相的耦合度很低，完全可以独立进行，这样的一种模式在开发大项目的过程中尤其有优势。

Controller，View层因为耦合度比较高，因而要结合在一起开发，但是也可以看作一个整体独立于前两个层进行开发。这样，在层与层之前我们只需要知道接口的定义，调用接口即可完成所需要的逻辑单元应用，一切显得非常清晰简单。

Service层是建立在DAO层之上的，建立了DAO层后才可以建立Service层，而Service层又是在Controller层之下的，因而Service层应该既调用DAO层的接口，又要提供接口给Controller层的类来进行调用，它刚好处于一个中间层的位置。每个模型都有一个Service接口，每个接口分别封装各自的业务处理方法。

4、SSM原理及流程

客户端发送请求到DispacherServlet（分发器）

由DispacherServlet控制器查询HanderMapping，找到处理请求的Controller

Controller调用Service业务逻辑层处理后返回结果

一、什么是哈希表

在讨论哈希表之前，我们先大概了解下其他数据结构在新增，查找等基础操作执行性能

数组：采用一段连续的存储单元来存储数据。对于指定下标的查找，时间复杂度为O(1)；通过给定值进行查找，需要遍历数组，逐一比对给定关键字和数组元素，时间复杂度为O(n)，当然，对于有序数组，则可采用二分查找，插值查找，斐波那契查找等方式，可将查找复杂度提高为O(logn)；对于一般的插入删除操作，涉及到数组元素的移动，其平均复杂度也为O(n)

线性链表：对于链表的新增，删除等操作（在找到指定操作位置后），仅需处理结点间的引用即可，时间复杂度为O(1)，而查找操作需要遍历链表逐一进行比对，复杂度为O(n)

二叉树：对一棵相对平衡的有序二叉树，对其进行插入，查找，删除等操作，平均复杂度均为O(logn)。

哈希表：相比上述几种数据结构，在哈希表中进行添加，删除，查找等操作，性能十分之高，不考虑哈希冲突的情况下（后面会探讨下哈希冲突的情况），仅需一次定位即可完成，时间复杂度为O(1)，接下来我们就来看看哈希表是如何实现达到惊艳的常数阶O(1)的。

我们知道，数据结构的物理存储结构只有两种：顺序存储结构和链式存储结构（像栈，队列，树，图等是从逻辑结构去抽象的，映射到内存中，也这两种物理组织形式），而在上面我们提到过，在数组中根据下标查找某个元素，一次定位就可以达到，哈希表利用了这种特性，哈希表的主干就是数组。

比如我们要新增或查找某个元素，我们通过把当前元素的关键字 通过某个函数映射到数组中的某个位置，通过数组下标一次定位就可完成操作。

查找操作同理，先通过哈希函数计算出实际存储地址，然后从数组中对应地址取出即可。

哈希冲突

然而万事无完美，如果两个不同的元素，通过哈希函数得出的实际存储地址相同怎么办？也就是说，当我们对某个元素进行哈希运算，得到一个存储地址，然后要进行插入的时候，发现已经被其他元素占用了，其实这就是所谓的哈希冲突，也叫哈希碰撞。前面我们提到过，哈希函数的设计至关重要，好的哈希函数会尽可能地保证 计算简单和散列地址分布均匀,但是，我们需要清楚的是，数组是一块连续的固定长度的内存空间，再好的哈希函数也不能保证得到的存储地址绝对不发生冲突。那么哈希冲突如何解决呢？哈希冲突的解决方案有多种:开放定址法（发生冲突，继续寻找下一块未被占用的存储地址），再散列函数法，链地址法，而HashMap即是采用了链地址法，也就是数组+链表的方式。

二、HashMap的实现原理

HashMap的主干是一个Entry数组。Entry是HashMap的基本组成单元，每一个Entry包含一个key-value键值对。（其实所谓Map其实就是保存了两个对象之间的映射关系的一种集合）

简单来说，HashMap由数组+链表组成的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的，如果定位到的数组位置不含链表（当前entry的next指向null）,那么查找，添加等操作很快，仅需一次寻址即可；如果定位到的数组包含链表，对于添加操作，其时间复杂度为O(n)，首先遍历链表，存在即覆盖，否则新增；对于查找操作来讲，仍需遍历链表，然后通过key对象的equals方法逐一比对查找。所以，性能考虑，HashMap中的链表出现越少，性能才会越好。

另外，关注公号“终码一生”，回复关键词“资料”，获取视频教程和最新的面试资料！

5

扩展

练习一

文件中有40亿个互不相同的QQ号码，请设计算法对QQ号码进行排序，内存限制1G。

很显然，直接用bitmap, 标记这40亿个QQ号码的存在性，然后从小到大遍历正整数，当bitmapFlag的值为1时，就输出该值，输出后的正整数序列就是排序后的结果。

请注意，这里必须限制40亿个QQ号码互不相同。通过bitmap记录，客观上就自动完成了排序功能。

练习二

文件中有40亿个互不相同的QQ号码，求这些QQ号码的中位数，内存限制1G。

我知道，一些刷题经验丰富的人，最开始想到的肯定是用堆或者文件切割，这明显是犯了本本主义错误。直接用bitmap排序，当场搞定中位数。

练习三

文件中有40亿个互不相同的QQ号码，求这些QQ号码的top-K，内存限制1G。

我知道，很多人背诵过top-K问题，信心满满，想到用小顶堆或者文件切割，这明显又是犯了本本主义错误。直接用bitmap排序，当场搞定top-K问题。

练习四

文件中有80亿个QQ号码，试判断其中是否存在相同的QQ号码，内存限制1G。

我知道，一些吸取了经验教训的人肯定说，直接bitmap啊。然而，又一次错了。根据容斥原理可知：

因为QQ号码的个数是43亿左右(理论值2^32 - 1)，所以80亿个QQ号码必然存在相同的QQ号码。

海量数据的问题，要具体问题具体分析，不要眉毛胡子一把抓。有些人完全不刷题，肯定不行。有些人刷题后不加思考，不会变通，也是不行的。好了，先说这么多。我们也会一步一个脚印，争取每篇文章讲清讲透一件事，也希望大家阅读后有所收获，心情愉快。