今天，我们来聊一道常见的考题，也出现在腾讯面试的三面环节，非常有意思：文件中有40亿个QQ号码，请设计算法对QQ号码去重，相同的QQ号码仅保留一个，内存限制1G。
这个题目的意思应该很清楚了，比较直白。为了便于大家理解，我来画个动图玩玩，希望大家喜欢。
能否做对这道题目，很大程度上就决定了能否拿下腾讯的offer，有一定的技巧性，一起来看下吧。
在原题中，实际有40亿个QQ号码，为了方便起见，在图解和叙述时，仅以4个QQ为例来说明。
另外，关注公号“终码一生”，回复关键词“资料”，获取视频教程和最新的面试资料！
1
方法一：排序
很自然地，最简单的方式是对所有的QQ号码进行排序，重复的QQ号码必然相邻，保留第一个，去掉后面重复的就行。
原始的QQ号为：
排序后的QQ号为：
去重就简单了：
可是，面试官要问你，去重一定要排序吗?显然，排序的时间复杂度太高了，无法通过腾讯面试。
2
方法二：hashmap
既然直接排序的时间复杂度太高，那就用hashmap吧，具体思路是把QQ号码记录到hashmap中：
代码语言：javascript复制mapFlag[123] = true
mapFlag[567] = true
mapFlag[123] = true
mapFlag[890] = true由于hashmap的去重性质，可知实际自动变成了：
代码语言：javascript复制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，比如：
代码语言：javascript复制bitmapFlag[123] = 1
bitmapFlag[567] = 1
bitmapFlag[123] = 1
bitmapFlag[890] = 1实际上就是：
代码语言：javascript复制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号码。
海量数据的问题，要具体问题具体分析，不要眉毛胡子一把抓。有些人完全不刷题，肯定不行。有些人刷题后不加思考，不会变通，也是不行的。好了，先说这么多。我们也会一步一个脚印，争取每篇文章讲清讲透一件事，也希望大家阅读后有所收获，心情愉快。
