2020/8/29 滴滴一面复盘

1. 算法题
   （1） 求两个数组的交集
   我的方法：先排序再做，O(nlgn)，没有达到最优的时间复杂度
   最优方法：哈希表，先遍历较短的数组，构造一个哈希表。对于较长的数组，如果哈希表的key对应的值大于0，则value减1，并加入到答案中
   （2） 只用加法实现减法、乘法和除法（此题做错）
   （1） def negate(a):
   （2） value = -1 if a >= 0 else 1
   （3） if a == 0:
   （4） return 0
   （5） else:
   （6） res = 0
   （7） while a:
   （8） a += value
   （9） res += value
   （10） return res
   （11）
   （12） def absolute(a):
   （13） if a >= 0:
   （14） return a
   （15） else:
   （16） return negate(a)
   （17）
   （18） def subtract(a, b):
   （19） return a+negate(b)
   （20）
   （21） def multiply(a, b):
   （22） if b >= 0:
   （23） count = 0
   （24） res = 0
   （25） while count < b:
   （26） res += a
   （27） count += 1
   （28） return res
   （29） else:
   （30） b = negate(b)
   （31） return negate(multiply(a, b))
   （32）
   （33） def divide(a, b):
   （34） if b == 0:
   （35） print ‘chushu can not be 0’
   （36） return
   （37） if multiply(a, b) >= 0:
   （38） a = absolute(a)
   （39） b = absolute(b)
   （40） res, temp = 0, 0
   （41） while temp <= a:
   （42） temp += b
   （43） res += 1
   （44） return res-1
   （45） else:
   （46） return negate(divide(absolute(a), absolute(b)))
2. 如何设置长连接
   在HTTP1.0和HTTP1.1协议中都有对长连接的支持。其中HTTP1.0需要在请求头中增加”Connection： keep-alive“ header才能够支持，而HTTP1.1默认支持.

http1.0请求与服务端的交互过程:
a)客户端发出带有包含一个header：”Connection： keep-alive“的请求
b)服务端接收到这个请求后,根据http1.0和”Connection： keep-alive“判断出这是一个长连接,就会在response的header中也增加”Connection： keep-alive“,同是不会关闭已建立的tcp连接.
c)客户端收到服务端的response后,发现其中包含”Connection： keep-alive“，就认为是一个长连接，不关闭这个连接。并用该连接再发送request.转到a)

http1.1请求与服务端的交互过程:
a)客户端发出http1.1的请求
b)服务端收到http1.1后就认为这是一个长连接,会在返回的response设置Connection： keep-alive,同是不会关闭已建立的连接.
c)客户端收到服务端的response后,发现其中包含”Connection： keep-alive“，就认为是一个长连接，不关闭这个连接。并用该连接再发送request.转到a)

基于http协议的长连接减少了请求,减少了建立连接的时间,但是每次交互都是由客户端发起的,客户端发送消息,服务端才能返回客户端消息.因为客户端也不知道服务端什么时候会把结果准备好,所以客户端的很多请求是多余的,仅是维持一个心跳,浪费了带宽.

3. time_wait状态及其危害
   服务器也可能处于time_wait状态，比如爬虫服务器
   在高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接。这个场景下，会出现大量socket处于TIMEWAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。

time_wait状态如何避免
首先调用bind()之前设置SO_REUSEADDR套接字选项，服务器可以设置SO_REUSEADDR套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是，如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。
Close_wait状态产生的原因：
（1） 服 务器A是一台爬虫服务器，它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源，正常情况下，如果请求成功，那么在抓取完 资源后，服务器A会主动发出关闭连接的请求，这个时候就是主动关闭连接，服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢？假设 请求的资源服务器B上并不存在，那么这个时候就会由服务器B发出关闭连接的请求，服务器A就是被动的关闭了连接，如果服务器A被动关闭连接之后程序员忘了 让HttpClient释放连接，那就会造成CLOSE_WAIT的状态了。
（2） 咱们引入两个系统调用close(sockfd)和shutdown(sockfd,how)接着往下分析。在这儿，需要明确的一个概念---- 一个进程打开一个socket，然后此进程再派生子进程的时候，此socket的sockfd会被继承。socket是系统级的对象，现在的结果是，此socket被两个进程打开，此socket的引用计数会变成2。
继续说上述两个系统调用对socket的关闭情况。调用close(sockfd)时，内核检查此fd对应的socket上的引用计数。如果引用计数大于1，那么将这个引用计数减1，然后返回。如果引用计数等于1，那么内核会真正通过发FIN来关闭TCP连接。调用shutdown(sockfd，SHUT_RDWR)时,内核不会检查此fd对应的socket上的引用计数，直接通过发FIN来关闭TCP连接。现在应该真相大白了，可能是服务器的实现有点问题，父进程打开了socket，然后用派生子进程来处理业务，父进程继续对网络请求进行监听，永远不会终止。客户端发FIN过来的时候，处理业务的子进程的read返回0，子进程发现对端已经关闭了，直接调用close()对本端进行关闭。实际上，仅仅使socket的引用计数减1，socket并没关闭。从而导致系统中又多了一个CLOSE_WAIT的socket.如何避免这样的情况发生?子进程的关闭处理应该是这样的：
shutdown(sockfd, SHUT_RDWR);
close(sockfd);
这样处理，服务器的FIN会被发出，socket进入LAST_ACK状态，等待最后的ACK到来，就能进入初始状态CLOSED。

4. 单例模式，使用场景优缺点
   构造方法私有化、提供一个当前类型的私有静态变量、对外提供一个公开的静态的可以获取当前类型对象的方法
   public class Singleton{
   private static Singleton s;
   private Singleton {};
   public static Singleton getInstance(){
   if(s == null){
   s = new Singleton();
   }
   return s;
   }
   }
   单例模式在多线程下要小心使用，如果当唯一实例尚未创建时，有两个线程同时调用创建方法，那么它们同时没有检测到唯一实例的存在，从而同时各自创建了一个实例， 这样就有两个实例被构造出来，从而违反了单例模式中实例唯一的原则。（在Java中，synchronized关键字是用来控制线程同步的，就是在多线程的环境下，控制synchronized代码段不被多个线程同时执行）
   缺点：构造方法私有化，单例模式的类无法被继承
   使用场景：1、有频繁实例化然后销毁的情况，也就是频繁的 new 对象，可以考虑单例模式；2、创建对象时耗时过多或者耗资源过多，但又经常用到的对象；
   3、频繁访问 IO 资源的对象，例如数据库连接池或访问本地文件

网站计数器、读取配置文件、应用程序日志

5. 网络IO
   阻塞IO、非阻塞IO、IO多路复用、信号驱动IO、异步IO
   再说一下IO发生时涉及的对象和步骤。对于一个network IO (这里我们以read举例)，它会涉及到两个系统对象，一个是调用这个IO的process (or thread)，另一个就是系统内核(kernel)。当一个read操作发生时，它会经历两个阶段：
   1）等待数据准备 (Waiting for the data to be ready)
   2）将数据从内核拷贝到进程中(Copying the data from the kernel to the process)
   （1）阻塞IO
   在linux中，默认情况下所有的socket都是blocking，一个典型的读操作流程大概是这样：

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。
所以，blocking IO的特点就是在IO执行的两个阶段（等待数据和拷贝数据两个阶段）都被block了。
几乎所有的程序员第一次接触到的网络编程都是从listen()、send()、recv() 等接口开始的，这些接口都是阻塞型的。使用这些接口可以很方便的构建服务器/客户机的模型。下面是一个简单地“一问一答”的服务器。

我们注意到，大部分的socket接口都是阻塞型的。所谓阻塞型接口是指系统调用（一般是IO接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。
实际上，除非特别指定，几乎所有的IO接口 ( 包括socket接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。

一个简单的改进方案是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。具体使用多进程还是多线程，并没有一个特定的模式。传统意义上，进程的开销要远远大于线程，所以如果需要同时为较多的客户机提供服务，则不推荐使用多进程；如果单个服务执行体需要消耗较多的CPU资源，譬如需要进行大规模或长时间的数据运算或文件访问，则进程较为安全。通常，使用pthread_create ()创建新线程，fork()创建新进程。

我们假设对上述的服务器 / 客户机模型，提出更高的要求，即让服务器同时为多个客户机提供一问一答的服务。于是有了如下的模型。

在上述的线程 / 时间图例中，主线程持续等待客户端的连接请求，如果有连接，则创建新线程，并在新线程中提供为前例同样的问答服务。
很多初学者可能不明白为何一个socket可以accept多次。实际上socket的设计者可能特意为多客户机的情况留下了伏笔，让accept()能够返回一个新的socket。下面是 accept 接口的原型：
int accept(int s, struct sockaddr *addr, socklen_t *addrlen);
输入参数s是从socket()，bind()和listen()中沿用下来的socket句柄值。执行完bind()和listen()后，操作系统已经开始在指定的端口处监听所有的连接请求，如果有请求，则将该连接请求加入请求队列。调用accept()接口正是从 socket s 的请求队列抽取第一个连接信息，创建一个与s同类的新的socket返回句柄。新的socket句柄即是后续read()和recv()的输入参数。如果请求队列当前没有请求，则accept() 将进入阻塞状态直到有请求进入队列。
上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。
很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如websphere、tomcat和各种数据库等。但是，“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用IO接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。
对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型也会遇到瓶颈，可以用非阻塞接口来尝试解决这个问题。

（2）非阻塞IO
Linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时，流程是这个样子：

从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。
所以，在非阻塞式IO中，用户进程其实是需要不断的主动询问kernel数据准备好了没有。

非阻塞的接口相比于阻塞型接口的显著差异在于，在被调用之后立即返回。使用如下的函数可以将某句柄fd设为非阻塞状态。
fcntl( fd, F_SETFL, O_NONBLOCK ); 

下面将给出只用一个线程，但能够同时从多个连接中检测数据是否送达，并且接受数据的模型。

在非阻塞状态下，recv() 接口在被调用后立即返回，返回值代表了不同的含义。如在本例中，
* recv() 返回值大于 0，表示接受数据完毕，返回值即是接受到的字节数；
* recv() 返回 0，表示连接已经正常断开；
* recv() 返回 -1，且 errno 等于 EAGAIN，表示 recv 操作还没执行完成；
* recv() 返回 -1，且 errno 不等于 EAGAIN，表示 recv 操作遇到系统错误 error。
可以看到服务器线程可以通过循环调用recv()接口，可以在单个线程内实现对所有连接的数据接收工作。但是上述模型绝不被推荐。因为，循环调用recv()将大幅度推高CPU 占用率；此外，在这个方案中recv()更多的是起到检测“操作是否完成”的作用，实际操作系统提供了更为高效的检测“操作是否完成“作用的接口，例如select()多路复用模式，可以一次检测多个连接是否活跃。

（3） 多路复用IO
IO multiplexing这个词可能有点陌生，但是如果我说select/epoll，大概就都能明白了。有些地方也称这种IO方式为事件驱动IO(event driven IO)。我们都知道，select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。它的流程如图：

当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。
这个图和blocking IO的图其实并没有太大的不同，事实上还更差一些。因为这里需要使用两个系统调用(select和recvfrom)，而blocking IO只调用了一个系统调用(recvfrom)。但是，用select的优势在于它可以同时处理多个connection。（多说一句：所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）
在多路复用模型中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。因此select()与非阻塞IO类似。

大部分Unix/Linux都支持select函数，该函数用于探测多个文件句柄的状态变化。下面给出select接口的原型：
FD_ZERO(int fd, fd_set* fds) 
FD_SET(int fd, fd_set* fds) 
FD_ISSET(int fd, fd_set* fds) 
FD_CLR(int fd, fd_set* fds) 
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, 
struct timeval *timeout) 
这里，fd_set 类型可以简单的理解为按 bit 位标记句柄的队列，例如要在某 fd_set 中标记一个值为16的句柄，则该fd_set的第16个bit位被标记为1。具体的置位、验证可使用 FD_SET、FD_ISSET等宏实现。在select()函数中，readfds、writefds和exceptfds同时作为输入参数和输出参数。如果输入的readfds标记了16号句柄，则select()将检测16号句柄是否可读。在select()返回后，可以通过检查readfds有否标记16号句柄，来判断该“可读”事件是否发生。另外，用户可以设置timeout时间。
下面将重新模拟上例中从多个客户端接收数据的模型。

上述模型只是描述了使用select()接口同时从多个客户端接收数据的过程；由于select()接口可以同时对多个句柄进行读状态、写状态和错误状态的探测，所以可以很容易构建为多个客户端提供独立问答服务的服务器系统。如下图。

https://blog.csdn.net/u010313909/article/details/80764954