商汤2019年秋招面经总结

介绍：

该博客对商汤2019年秋招开发岗所见大部分面经进行了整理。对大多数题目进行了答案的查找。当然没有做到尽善尽美，所以有些问题还是需要读者自行查找体会。

目录

算法

SQL&&NOSQL

网络

设计模式

python

linux&&并发

 内存管理

C++

git

---

算法

各种排序，重点快排，堆排（复杂度、稳定性）

两个很大的身份证集，找出重复的身份证（属于大数据集求交集）

哈希表的实现

给出很多关系对，求出关系链数（不知道是啥）

两个链表的第一个公共节点（剑指offer原题）

二分查找（比较基础，当数据集有序或者时间复杂度为log时应该考虑二分查找）

手写实现求两个集合A, B 的差集，和都要给出

一个普通list  翻转一下。不需要写代码，思路说出来就行。除了依靠第三方变量还有改指针

实现一个二叉树的插入节点和删除节点。

数组最大子串累加和，动态规划经典题目，

求一个数组中累加和在一个区间的种数

top k剑指offer原题

深度搜索广度搜索

查找一个无序数组中的中位数，要最优时间复杂度。

最长无重复字符子串，要最优时间复杂度。

背包

LRU缓存

总结：（算法不难，剑指offer，常见算法以及leetcode中medium及以下难度）

 

SQL&&NOSQL

SQL 和 noSQL 的区别，nosql场景 sql场景

Redis 的应用，场景

Kafka 的原理与特点

redis过期策略是怎么实现的呢

mysql存储引擎，更适合做哪种应用

哪些情况下索引会失效

建立索引需要注意哪些情况

数据库集群之间怎么保持同步

若不一致会有什么问题（扯了CAP）

网络

TCP和UDP

常用的状态响应码

soket阻塞模式 阻塞和非阻塞的优缺点

new发生了什么和this对象的指向类别

http1.0 和 http2.0 的区别

https 的详细过程，从握手到SSL协议，为什么https并没有得到大规模应用

http 三次握手及细节，和https握手

如果用UDP，应该在应用层做什么

设计UDP应用层重传策略

cookie和sessionStorage、localStorage的区别

下面的都看看吧，一般网络方面就是这些了

（http请求全过程

https://blog.csdn.net/yezitoo/article/details/78193794

常见面试题

https://blog.csdn.net/weiyuefei/article/details/50413543

https://blog.csdn.net/chencheng126/article/details/44407901

https://blog.csdn.net/u014800094/article/details/60591852

DNS

https://www.cnblogs.com/morethink/p/8120327.html

https://blog.csdn.net/yipiankongbai/article/details/24025633

https://www.cnblogs.com/xymqx/p/4442465.html

TCP首部TCP伪首部

get和post区别

 

（8）、从输入网址到显示网页，过程

http://blog.csdn.net/donggx/article/details/71402871?locationNum=1&fps=1

http://blog.csdn.net/xiangriikui/article/details/52207153

TCP和UDP边界性区别

HTTP和HTTPS的区别https://www.zhihu.com/question/19577317

（9）、http的格式

HTTP请求方法

tcp三次握手四次挥手（及原因）详解

HTTP请求、响应报文格式

https://www.jianshu.com/p/8fe93a14754c

（10）、http有状态吗

与HTTP无状态请求相对的有状态请求的例子? - 知乎 https://www.zhihu.com/question/29731567

http协议无状态中的 "状态" 到底指的是什么？！ https://www.cnblogs.com/bellkosmos/p/5237146.html

https://blog.csdn.net/chollima/article/details/38864701

（11）、cookie是什么？

https://jingyan.baidu.com/article/4f7d5712a67b671a2019278f.html

（12）、session是什么？

http://blog.csdn.net/sixteen_cicle/article/details/52355332

http://blog.csdn.net/hjc1984117/article/details/53995816

和cookie的区别https://www.zhihu.com/question/19786827

（13）tcp和udp区别

http://blog.csdn.net/li_ning_/article/details/52117463

设计模式

单例模式注意线程安全

所有的设计模式，C++实现

MVC模式是怎么交互的

手写一个工厂类方法，并在它的基础上给出装饰者模式

实现在一个方法A的调用之前都会先调用方法B, 不允许更改接口和调用方式（钩子和职责链）

手写一个观察者模式，然后再说一下怎么实现发布订阅模式（不能依赖任何第三方框架或已有的实现）

python

Python有哪些数据类型。分别写出。 list与tuple的区别

python： 1.深拷贝和浅拷贝，copy（）函数是深拷贝还是浅拷贝 2.python生成器

linux&&并发

进程线程

http://blog.csdn.net/yaosiming2011/article/details/44280797

https://blog.csdn.net/zhou753099943/article/details/51771220

https://blog.csdn.net/yanxiaolx/article/details/51763372

https://blog.csdn.net/dazhong159/article/details/7896070

让你设计一个cache如何设计（算法里的LRU？）

介绍多线程的实现方式

如何设计缓存策略

 内存管理

讲一下虚拟地址如何映射成物理地址，TLB了解么，分页机制说一下，页面大小是多少。（内存管理）

虚拟内存

6、什么是虚拟内存？

解析：是将进程部分装入内存中，从而能实现一个很大的程序能在一个比它小的内存中运行，它的主要实现是靠程序的换进换出来实现的，因为内存中0~3G是用户使用，3~4G才是内存使用，通过映射来实现来进行逻辑地址到物理地址的映射

 

7、虚拟地址、逻辑地址、线性地址、物理地址的区别？

解析： 分段机制把一个逻辑地址转换为线性地址；接着，分页机制把一个线性地址转换为物理地址。

（1）虚拟地址：虚拟内存映射出来的地址

（2）逻辑地址：程序的段加偏移量形成的，C/C++程序中取地址求出来的地址就是逻辑地址

（3）线性地址：是逻辑地址到物理地址的中间层，只有启动分页机制的时候才有线性地址，如果没有分页机制，那么线性地址就是物理地址

（4）物理地址：是内存中实实在在存在的硬件地址，

逻辑地址（启动分段）--》线性地址（启动分页）--》物理地址

内存存在的问题：

1．进程地址空间不能隔离

　　由于程序直接访问的是物理内存，这个时候程序所使用的内存空间不是隔离的。举个例子，就像上面说的A的地址空间是0-10M这个范围内，但是如果A中有一段代码是操作10M-128M这段地址空间内的数据，那么程序B和程序C就很可能会崩溃（每个程序都可以访问系统的整个地址空间）。这样很多恶意程序或者是木马程序可以轻而易举地破快其他的程序，系统的安全性也就得不到保障了，这对用户来说也是不能容忍的。

　　2. 内存使用的效率低

　　如上面提到的，如果我们要像让程序A、B、C同时运行，那么唯一的方法就是使用虚拟内存技术将一些程序暂时不用的数据写到磁盘上，在需要的时候再从磁盘读回内存。这里程序C要运行，将A交换到磁盘上去显然是不行的，因为程序是需要连续的地址空间的，程序C需要20M的内存，而A只有10M的空间，所以需要将程序B交换到磁盘上去，而B足足有100M，可以看到为了运行程序C我们需要将100M的数据从内存写到磁盘，然后在程序B需要运行的时候再从磁盘读到内存，我们知道IO操作比较耗时，所以这个过程效率将会十分低下。

　　3. 程序运行的地址不能确定

　　程序每次需要运行时，都需要在内存中分配一块足够大的空闲区域，而问题是这个空闲的位置是不能确定的，这会带来一些重定位的问题，重定位的问题确定就是程序中引用的变量和函数的地址

内存管理无非就是想办法解决上面三个问题，如何使进程的地址空间隔离，如何提高内存的使用效率，如何解决程序运行时的重定位问题

虚拟内存

现在的内存管理方法就是在程序和物理内存之间引入了虚拟内存这个概念。虚拟内存位于程序和物理内存之间，程序只能看见虚拟内存，再也不能直接访问物理内存。每个程序都有自己独立的进程地址空间，这样就做到了进程隔离。这里的进程地址空间是指虚拟地址。顾名思义，既然是虚拟地址，也就是虚的，不是现实存在的地址空间。

　既然我们在程序和物理地址空间之间增加了虚拟地址，那么就要解决怎么从虚拟地址映射到物理地址，因为程序最终肯定是运行在物理内存中的，主要有分段和分页两种技术。

　分段(Segmentation)：这种方法是人们最开始使用的一种方法，基本思路是将程序所需要的内存地址空间大小的虚拟空间映射到某个物理地址空间。

　　段映射机制

　　每个程序都有其独立的虚拟的独立的进程地址空间，可以看到程序A和B的虚拟地址空间都是从0x00000000开始的。我们将两块大小相同的虚拟地址空间和实际物理地址空间一一映射，即虚拟地址空间中的每个字节对应于实际地址空间中的每个字节，这个映射过程由软件来设置映射的机制，实际的转换由硬件来完成。

　　这种分段的机制解决了文章一开始提到的3个问题中的进程地址空间隔离和程序地址重定位的问题。程序A和程序B有自己独立的虚拟地址空间，而且该虚拟地址空间被映射到了互相不重叠的物理地址空间，如果程序A访问虚拟地址空间的地址不在0x00000000-0x00A00000这个范围内，那么内核就会拒绝这个请求，所以它解决了隔离地址空间的问题。我们应用程序A只需要关心其虚拟地址空间0x00000000-0x00A00000，而其被映射到哪个物理地址我们无需关心，所以程序永远按照这个虚拟地址空间来放置变量，代码，不需要重新定位。

　　无论如何分段机制解决了上面两个问题，是一个很大的进步，但是对于内存效率问题仍然无能为力。因为这种内存映射机制仍然是以程序为单位，当内存不足时仍然需要将整个程序交换到磁盘，这样内存使用的效率仍然很低。那么，怎么才算高效率的内存使用呢。事实上，根据程序的局部性运行原理，一个程序在运行的过程当中，在某个时间段内，只有一小部分数据会被经常用到。所以我们需要更加小粒度的内存分割和映射方法，此时是否会想到Linux中的Buddy算法和slab内存分配机制呢，哈哈。另一种将虚拟地址转换为物理地址的方法分页机制应运而生了。

　　分页机制：

　　分页机制就是把内存地址空间分为若干个很小的固定大小的页，每一页的大小由内存决定，就像Linux中ext文件系统将磁盘分成若干个Block一样，这样做是分别是为了提高内存和磁盘的利用率。试想一下，如果将磁盘空间分成N等份，每一份的大小(一个Block)是1M，如果我想存储在磁盘上的文件是1K字节，那么其余的999字节是不是浪费了。所以需要更加细粒度的磁盘分割方式，我们可以将Block设置得小一点，这当然是根据所存放文件的大小来综合考虑的，好像有点跑题了，我只是想说，内存中的分页机制跟ext文件系统中的磁盘分割机制非常相似。

　　Linux中一般页的大小是4KB，我们把进程的地址空间按页分割，把常用的数据和代码页装载到内存中，不常用的代码和数据保存在磁盘中，我们还是以一个例子来说明,如下图：

进程虚拟地址空间、物理地址空间和磁盘之间的页映射关系

　　我们可以看到进程1和进程2的虚拟地址空间都被映射到了不连续的物理地址空间内(这个意义很大，如果有一天我们的连续物理地址空间不够，但是不连续的地址空间很多，如果没有这种技术，我们的程序就没有办法运行)，甚至他们共用了一部分物理地址空间，这就是共享内存。

　　进程1的虚拟页VP2和VP3被交换到了磁盘中，在程序需要这两页的时候，Linux内核会产生一个缺页异常，然后异常管理程序会将其读到内存中。

　　这就是分页机制的原理，当然Linux中的分页机制的实现还是比较复杂的，通过了页全局目录，页上级目录，页中级目录，页表等几级的分页机制来实现的，但是基本的工作原理是不会变的。

　　分页机制的实现需要硬件的实现，这个硬件名字叫做MMU(Memory Management Unit)，他就是专门负责从虚拟地址到物理地址转换的，也就是从虚拟页找到物理页。

因为linux内核中内存管理中：所有的段的基地址均为0，即每个段的逻辑地址与线性地址保持一致（即逻辑地址的偏移量值与线性线性的地址值相同），而完成利用了分页机制。

虚拟地址又叫线性地址。linux没有采用分段机制，所以逻辑地址和虚拟地址（线性地址）（在用户态，内核态逻辑地址专指下文说的线性偏移前的地址）是一个概念。物理地址自不必提。内核的虚拟地址和物理地址，大部分只差一个线性偏移量。用户空间的虚拟地址和物理地址则采用了多级页表进行映射，但仍称之为线性地址。

[地址映射](图：左中)

linux内核使用页式内存管理，应用程序给出的内存地址是虚拟地址，它需要经过若干级页表一级一级的变换，才变成真正的物理地址。

想一下，地址映射还是一件很恐怖的事情。当访问一个由虚拟地址表示的内存空间时，需要先经过若干次的内存访问，得到每一级页表中用于转换的页表项（页表是存放在内存里面的），才能完成映射。也就是说，要实现一次内存访问，实际上内存被访问了N+1次（N=页表级数），并且还需要做N次加法运算。

所以，地址映射必须要有硬件支持，mmu（内存管理单元）就是这个硬件。并且需要有cache来保存页表，这个cache就是TLB（Translation lookaside buffer）。

尽管如此，地址映射还是有着不小的开销。假设cache的访存速度是内存的10倍，命中率是40%，页表有三级，那么平均一次虚拟地址访问大概就消耗了两次物理内存访问的时间。

于是，一些嵌入式硬件上可能会放弃使用mmu，这样的硬件能够运行VxWorks（一个很高效的嵌入式实时操作系统）、linux（linux也有禁用mmu的编译选项）、等系统。

但是使用mmu的优势也是很大的，最主要的是出于安全性考虑。各个进程都是相互独立的虚拟地址空间，互不干扰。而放弃地址映射之后，所有程序将运行在同一个地址空间。于是，在没有mmu的机器上，一个进程越界访存，可能引起其他进程莫名其妙的错误，甚至导致内核崩溃。

在地址映射这个问题上，内核只提供页表，实际的转换是由硬件去完成的。那么内核如何生成这些页表呢？这就有两方面的内容，虚拟地址空间的管理和物理内存的管理。（实际上只有用户态的地址映射才需要管理，内核态的地址映射是写死的。）

 

[虚拟地址管理](图：左下)

每个进程对应一个task结构，它指向一个mm结构，这就是该进程的内存管理器。（对于线程来说，每个线程也都有一个task结构，但是它们都指向同一个mm，所以地址空间是共享的。）

mm->pgd指向容纳页表的内存，每个进程有自已的mm，每个mm有自己的页表。于是，进程调度时，页表被切换（一般会有一个CPU寄存器来保存页表的地址，比如X86下的CR3，页表切换就是改变该寄存器的值）。所以，各个进程的地址空间互不影响（因为页表都不一样了，当然无法访问到别人的地址空间上。但是共享内存除外，这是故意让不同的页表能够访问到相同的物理地址上）。

用户程序对内存的操作（分配、回收、映射、等）都是对mm的操作，具体来说是对mm上的vma（虚拟内存空间）的操作。这些vma代表着进程空间的各个区域，比如堆、栈、代码区、数据区、各种映射区、等等。

用户程序对内存的操作并不会直接影响到页表，更不会直接影响到物理内存的分配。比如malloc成功，仅仅是改变了某个vma，页表不会变，物理内存的分配也不会变。

假设用户分配了内存，然后访问这块内存。由于页表里面并没有记录相关的映射，CPU产生一次缺页异常。内核捕捉异常，检查产生异常的地址是不是存在于一个合法的vma中。如果不是，则给进程一个"段错误"，让其崩溃；如果是，则分配一个物理页，并为之建立映射。

 

[物理内存管理](图：右上)

那么物理内存是如何分配的呢？

首先，linux支持NUMA（非均质存储结构），物理内存管理的第一个层次就是介质的管理。pg_data_t结构就描述了介质。一般而言，我们的内存管理介质只有内存，并且它是均匀的，所以可以简单地认为系统中只有一个pg_data_t对象。

每一种介质下面有若干个zone。一般是三个，DMA、NORMAL和HIGH。

DMA：因为有些硬件系统的DMA总线比系统总线窄，所以只有一部分地址空间能够用作DMA，这部分地址被管理在DMA区域（这属于是高级货了）；

HIGH：高端内存。在32位系统中，地址空间是4G，其中内核规定3~4G的范围是内核空间，0~3G是用户空间（每个用户进程都有这么大的虚拟空间）（图：中下）。前面提到过内核的地址映射是写死的，就是指这3~4G的对应的页表是写死的，它映射到了物理地址的0~1G上。（实际上没有映射1G，只映射了896M。剩下的空间留下来映射大于1G的物理地址，而这一部分显然不是写死的）。所以，大于896M的物理地址是没有写死的页表来对应的，内核不能直接访问它们（必须要建立映射），称它们为高端内存（当然，如果机器内存不足896M，就不存在高端内存。如果是64位机器，也不存在高端内存，因为地址空间很大很大，属于内核的空间也不止1G了）；

NORMAL：不属于DMA或HIGH的内存就叫NORMAL。

在zone之上的zone_list代表了分配策略，即内存分配时的zone优先级。一种内存分配往往不是只能在一个zone里进行分配的，比如分配一个页给内核使用时，最优先是从NORMAL里面分配，不行的话就分配DMA里面的好了（HIGH就不行，因为还没建立映射），这就是一种分配策略。

每个内存介质维护了一个mem_map，为介质中的每一个物理页面建立了一个page结构与之对应，以便管理物理内存。

每个zone记录着它在mem_map上的起始位置。并且通过free_area串连着这个zone上空闲的page。物理内存的分配就是从这里来的，从 free_area上把page摘下，就算是分配了。（内核的内存分配与用户进程不同，用户使用内存会被内核监督，使用不当就"段错误"；而内核则无人监督，只能靠自觉，不是自己从free_area摘下的page就不要乱用。）

 

[建立地址映射]

内核需要物理内存时，很多情况是整页分配的，这在上面的mem_map中摘一个page下来就好了。比如前面说到的内核捕捉缺页异常，然后需要分配一个page以建立映射。

说到这里，会有一个疑问，内核在分配page、建立地址映射的过程中，使用的是虚拟地址还是物理地址呢？首先，内核代码所访问的地址都是虚拟地址，因为CPU指令接收的就是虚拟地址（地址映射对于CPU指令是透明的）。但是，建立地址映射时，内核在页表里面填写的内容却是物理地址，因为地址映射的目标就是要得到物理地址。

那么，内核怎么得到这个物理地址呢？其实，上面也提到了，mem_map中的page就是根据物理内存来建立的，每一个page就对应了一个物理页。

于是我们可以说，虚拟地址的映射是靠这里page结构来完成的，是它们给出了最终的物理地址。然而，page结构显然是通过虚拟地址来管理的（前面已经说过，CPU指令接收的就是虚拟地址）。那么，page结构实现了别人的虚拟地址映射，谁又来实现page结构自己的虚拟地址映射呢？没人能够实现。

这就引出了前面提到的一个问题，内核空间的页表项是写死的。在内核初始化时，内核的地址空间就已经把地址映射写死了。page结构显然存在于内核空间，所以它的地址映射问题已经通过“写死”解决了。

由于内核空间的页表项是写死的，又引出另一个问题，NORMAL（或DMA）区域的内存可能被同时映射到内核空间和用户空间。被映射到内核空间是显然的，因为这个映射已经写死了。而这些页面也可能被映射到用户空间的，在前面提到的缺页异常的场景里面就有这样的可能。映射到用户空间的页面应该优先从HIGH区域获取，因为这些内存被内核访问起来很不方便，拿给用户空间再合适不过了。但是HIGH区域可能会耗尽，或者可能因为设备上物理内存不足导致系统里面根本就没有HIGH区域，所以，将NORMAL区域映射给用户空间是必然存在的。

但是NORMAL区域的内存被同时映射到内核空间和用户空间并没有问题，因为如果某个页面正在被内核使用，对应的page应该已经从free_area被摘下，于是缺页异常处理代码中不会再将该页映射到用户空间。反过来也一样，被映射到用户空间的page自然已经从free_area被摘下，内核不会再去使用这个页面。

 

[内核空间管理](图：右下)

除了对内存整页的使用，有些时候，内核也需要像用户程序使用malloc一样，分配一块任意大小的空间。这个功能是由slab系统来实现的。

slab相当于为内核中常用的一些结构体对象建立了对象池，比如对应task结构的池、对应mm结构的池、等等。

而slab也维护有通用的对象池，比如"32字节大小"的对象池、"64字节大小"的对象池、等等。内核中常用的kmalloc函数（类似于用户态的malloc）就是在这些通用的对象池中实现分配的。

slab除了对象实际使用的内存空间外，还有其对应的控制结构。有两种组织方式，如果对象较大，则控制结构使用专门的页面来保存；如果对象较小，控制结构与对象空间使用相同的页面。

除了slab，linux 2.6还引入了mempool（内存池）。其意图是：某些对象我们不希望它会因为内存不足而分配失败，于是我们预先分配若干个，放在mempool中存起来。正常情况下，分配对象时是不会去动mempool里面的资源的，照常通过slab去分配。到系统内存紧缺，已经无法通过slab分配内存时，才会使用 mempool中的内容。

 

[页面换入换出](图：左上)(图：右上)

页面换入换出又是一个很复杂的系统。内存页面被换出到磁盘，与磁盘文件被映射到内存，是很相似的两个过程（内存页被换出到磁盘的动机，就是今后还要从磁盘将其载回内存）。所以swap复用了文件子系统的一些机制。

页面换入换出是一件很费CPU和IO的事情，但是由于内存昂贵这一历史原因，我们只好拿磁盘来扩展内存。但是现在内存越来越便宜了，我们可以轻松安装数G的内存，然后将swap系统关闭。于是swap的实现实在让人难有探索的欲望，在这里就不赘述了。（另见：《linux内核页面回收浅析》）

 

[用户空间内存管理]

malloc是libc的库函数，用户程序一般通过它（或类似函数）来分配内存空间。

libc对内存的分配有两种途径，一是调整堆的大小，二是mmap一个新的虚拟内存区域（堆也是一个vma）。

在内核中，堆是一个一端固定、一端可伸缩的vma（图：左中）。可伸缩的一端通过系统调用brk来调整。libc管理着堆的空间，用户调用malloc分配内存时，libc尽量从现有的堆中去分配。如果堆空间不够，则通过brk增大堆空间。

当用户将已分配的空间free时，libc可能会通过brk减小堆空间。但是堆空间增大容易减小却难，考虑这样一种情况，用户空间连续分配了10块内存，前9块已经free。这时，未free的第10块哪怕只有1字节大，libc也不能够去减小堆的大小。因为堆只有一端可伸缩，并且中间不能掏空。而第10块内存就死死地占据着堆可伸缩的那一端，堆的大小没法减小，相关资源也没法归还内核。

当用户malloc一块很大的内存时，libc会通过mmap系统调用映射一个新的vma。因为对于堆的大小调整和空间管理还是比较麻烦的，重新建一个vma会更方便（上面提到的free的问题也是原因之一）。

那么为什么不总是在malloc的时候去mmap一个新的vma呢？第一，对于小空间的分配与回收，被libc管理的堆空间已经能够满足需要，不必每次都去进行系统调用。并且vma是以page为单位的，最小就是分配一个页；第二，太多的vma会降低系统性能。缺页异常、vma的新建与销毁、堆空间的大小调整、等等情况下，都需要对vma进行操作，需要在当前进程的所有vma中找到需要被操作的那个（或那些）vma。vma数目太多，必然导致性能下降。（在进程的vma较少时，内核采用链表来管理vma；vma较多时，改用红黑树来管理。）

malloc函数的实质体现在，它有一个将可用的内存块连接为一个长长的列表的所谓空闲链表。调用malloc函数时，它沿连接表寻找一个大到足以满足用户请求所需要的内存块。然后，将该内存块一分为二（一块的大小与用户请求的大小相等，另一块的大小就是剩下的字节）。接下来，将分配给用户的那块内存传给用户，并将剩下的那块（如果有的话）返回到连接表上。调用free函数时，它将用户释放的内存块连接到空闲链上。到最后，空闲链会被切成很多的小内存片段，如果这时用户申请一个大的内存片段，那么空闲链上可能没有可以满足用户要求的片段了。于是，malloc函数请求延时，并开始在空闲链上翻箱倒柜地检查各内存片段，对它们进行整理，将相邻的小空闲块合并成较大的内存块。如果无法获得符合要求的内存块，malloc函数会返回NULL指针，因此在调用malloc动态申请内存块时，一定要进行返回值的判断。

 

C++

malloc和new的区别

malloc内存分配怎么进行（见上面内存管理）

继承、静态函数

多态和继承的关系，虚函数，虚表

git

git相关操作