python面试题

Posted 2020-12-27 it-scavenger

1 什么是局域网、广域网、城域网？

①局域网LAN（Local Area Network）：一般指覆盖范围在10公里以内，一座楼房或一个单位内部的网络。由于传输距离直接影响传输速度，因此，局域网内的通信，由于传输于距离短，传输的速率一般都比较高。目前，局域网的传输速率一般可达到10MB/S和100MB/S,高速局域网传输速率可达到1000MB/S。②广域网WAN（Wide Area Network）:是指远距离的、大范围的计算机网络。跨地区、跨城市、跨国家的网络都是广域网。由于广域的覆盖范围广，联网的计算机多，因此广域网上的信息量非常大，共享的信息资源很丰富。INTERNET是全球最大的广域网，它覆盖的范围遍布全世界。③城域网MAN（Metropolitan Area Network）：其覆盖范围在局域网和广域网之间。一般指覆盖范围为一个城市的网络。

2 什么是粘包？ socket 中造成粘包的原因是什么？ 哪些情况会发生粘包现象？

socket粘包：??

??socket 交互send时，连续处理多个send时会出现粘包，soket会把两条send作为一条send强制发送，会粘在一起。

??send发送会根据recv定义的数值发送一个固定的数值，如果最后一次，所剩的数值小于recv定义数就会连带两条send数据同时发送，发生粘包状况。

解决方案：

??方案1：可以使用time.sleep 在两send之间加上时间（不建议）

??方案2：可以在send两条之间加入一条 conn.recv(1024)??

服务端

conn.send(str(len(cmd_res.encode())).encode("utf-8")) 
client_ack = conn.recv(1024) #wait client to confirm
conn.send(cmd_res.encode("utf-8"))

客户端 client.send("准备好接收了,loser可以发了".encode("utf-8"))

原理：recv在接收数据时是一个堵塞状态，自动卡在中间， ?? 客户会自动返回client_ack的数据信息，相当于两个 ?? send之间多了一次交互，就不会出现粘包情况。 ?

    方案3：通过if判断实现粘包解决（推荐）

while 总数值 > 递增接收数据:
   if 总数值 - 递增接收数据 > recv(1024): #比定义值大就成立
       size = 1024
   else: #最后一次
       size = 总数值 - 递增接收数据 #剩的数值
   recv(size)   #赋值给 recv

3 IO多路复用的作用？

什么是文件描述符 我们都知道unix(like)世界里，一切皆文件，而文件是什么呢？文件就是一串二进制流而已，不管socket,还是FIFO、管道、终端，对我们来说，一切都是文件，一切都是流。在信息 交换的过程中，我们都是对这些流进行数据的收发操作，简称为I/O操作(input and output)，往流中读出数据，系统调用read，写入数据，系统调用write。不过话说回来了 ，计算机里有这么多的流，我怎么知道要操作哪个流呢？对，就是文件描述符，即通常所说的fd，一个fd就是一个整数，所以，对这个整数的操作，就是对这个文件（流）的操作。我们创建一个socket,通过系统调用会返回一个文件描述符，那么剩下对socket的操作就会转化为对这个描述符的操作。不能不说这又是一种分层和抽象的思想。

阻塞？ 什么是程序的阻塞呢？想象这种情形，比如你等快递，但快递一直没来，你会怎么做？有两种方式：

快递没来，我可以先去睡觉，然后快递来了给我打电话叫我去取就行了。

快递没来，我就不停的给快递打电话说：擦，怎么还没来，给老子快点，直到快递来。

很显然，你无法忍受第二种方式，不仅耽搁自己的时间，也会让快递很想打你。 而在计算机世界，这两种情形就对应阻塞和非阻塞忙轮询。

非阻塞忙轮询：数据没来，进程就不停的去检测数据，直到数据来。

阻塞：数据没来，啥都不做，直到数据来了，才进行下一步的处理。

先说说阻塞，因为一个线程只能处理一个套接字的I/O事件，如果想同时处理多个，可以利用非阻塞忙轮询的方式，伪代码

while true:
   for i in stream[]:
       if i has data:
           read until unavailable

我们只要把所有流从头到尾查询一遍，就可以处理多个流了，但这样做很不好，因为如果所有的流都没有I/O事件，白白浪费CPU时间片。正如有一位科学家所说，计算机所有的问题都可以增加一个中间层来解决，同样，为了避免这里cpu的空转，我们不让这个线程亲自去检查流中是否有事件，而是引进了一个代理(一开始是select,后来是poll)，这个代理很牛，它可以同时观察许多流的I/O事件，如果没有事件，代理就阻塞，线程就不会挨个挨个去轮询了，伪代码如下：

while true:
   select(streams[]) //这一步死在这里，知道有一个流有I/O事件时，才往下执行
   for i in streams[]:
       if i has data
           read until unavailable

但是依然有个问题，我们从select那里仅仅知道了，有I/O事件发生了，却并不知道是哪那几个流（可能有一个，多个，甚至全部），我们只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。所以select具有O(n)的无差别轮询复杂度，同时处理的流越多，无差别轮询时间就越长。

epoll可以理解为event poll，不同于忙轮询和无差别轮询，epoll会把哪个流发生了怎样的I/O事件通知我们。所以我们说epoll实际上是事件驱动（每个事件关联上fd）的，此时我们对这些流的操作都是有意义的。（复杂度降低到了O(1)）伪代码如下：

while true:
   active_stream[] = epoll_wait(epollfd)
   for i in active_stream[]:
       read or write till

可以看到，select和epoll最大的区别就是：select只是告诉你一定数目的流有事件了，至于哪个流有事件，还得你一个一个地去轮询，而epoll会把发生的事件告诉你，通过发生的事件，就自然而然定位到哪个流了。不能不说epoll跟select相比，是质的飞跃，我觉得这也是一种牺牲空间，换取时间的思想，毕竟现在硬件越来越便宜了。

I/O多路复用

好了，我们讲了这么多，再来总结一下，到底什么是I/O多路复用。 先讲一下I/O模型： 首先，输入操作一般包含两个步骤：

等待数据准备好（waiting for data to be ready）。对于一个套接口上的操作，这一步骤关系到数据从网络到达，并将其复制到内核的某个缓冲区。

将数据从内核缓冲区复制到进程缓冲区（copying the data from the kernel to the process）。

其次了解一下常用的3种I/O模型：

阻塞I/O模型 最广泛的模型是阻塞I/O模型，默认情况下，所有套接口都是阻塞的。 进程调用recvfrom系统调用，整个过程是阻塞的，直到数据复制到进程缓冲区时才返回（当然，系统调用被中断也会返回）。

非阻塞I/O模型 当我们把一个套接口设置为非阻塞时，就是在告诉内核，当请求的I/O操作无法完成时，不要将进程睡眠，而是返回一个错误。当数据没有准备好时，内核立即返回EWOULDBLOCK错误，再次调用系统调用时，数据已经存在，这时将数据复制到进程缓冲区中。这其中有一个操作时轮询（polling）。

I/O复用模型 此模型用到select和poll函数，这两个函数也会使进程阻塞，select先阻塞，有活动套接字才返回，但是和阻塞I/O不同的是，这两个函数可以同时阻塞多个I/O操作，而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写（就是监听多个socket）。select被调用后，进程会被阻塞，内核监视所有select负责的socket，当有任何一个socket的数据准备好了，select就会返回套接字可读，我们就可以调用recvfrom处理数据。 正因为阻塞I/O只能阻塞一个I/O操作，而I/O复用模型能够阻塞多个I/O操作，所以才叫做多路复用。

4 简述 进程、线程、协程的区别 以及应用场景？

线程和进程：

线程是属于进程的，线程运行在进程空间内，同一进程所产生的线程共享同一内存空间，当进程退出时该进程所产生的线程都会被强制退出并清除。线程可与属于同一进程的其它线程共享进程所拥有的全部资源，但是其本身基本上不拥有系统资源，只拥有一点在运行中必不可少的信息(如程序计数器、一组寄存器和栈)。

线程、进程与协程： 线程和进程的操作是由程序触发系统接口，最后的执行者是系统；协程的操作则是程序员

协程存在的意义：对于多线程应用，CPU通过切片的方式来切换线程间的执行，线程切换时需要耗时（保持状态，下次继续）。协程，则只使用一个线程，在一个线程中规定某个代码块执行顺序。 协程的适用场景： 当程序中存在大量不需要CPU的操作时（IO），适用于协程；

5 GIL锁是什么鬼？

我们所说的Python全局解释锁（GIL）简单来说就是一个互斥体（或者说锁），这样的机制只允许一个线程来控制Python解释器。

这就意味着在任何一个时间点只有一个线程处于执行状态。GIL对执行单线程任务的程序员们来说并没什么显著影响，但是它成为了计算密集型（CPU-bound）和多线程任务的性能瓶颈。

由于GIL即使在拥有多个CPU核的多线程框架下都只允许一次运行一个线程，所以在Python众多功能中其声誉可谓是“臭名昭著”。

在这篇文章中，你将了解到GIL是如何影响到你的Python程序性能的以及如何减轻它对代码带来的影响。

GIL解决了Python中的什么问题？ Python利用引用计数来进行内存管理，这就意味着在Python中创建的对象都有一个引用计数变量来追踪指向该对象的引用数量。当数量为0时，该对象占用的内存即被释放。

我们来通过一个简单的代码演示引用计数是如何工作的：

 

 

在上述例子中，空列表对象[ ]的引用计数为3。该列表对象被a、b和传递给sys.getrefcount( )的参数引用。

回到GIL本身：

问题在于，这个引用计数变量需要在两个线程同时增加或减少时从竞争条件中得到保护。如果发生了这种情况，可能会导致泄露的内存永远不会被释放，抑或更严重的是当一个对象的引用仍然存在的情况下错误地释放内存。这可能会导致Python程序崩溃或带来各种诡异的bug。

通过对跨线程分享的数据结构添加锁定以至于数据不会不一致地被修改，这样做可以很好的保证引用计数变量的安全。

但是对每一个对象或者对象组添加锁意味着会存在多个锁这也就导致了另外一个问题——死锁（只有当存在多个锁时才会发生）。而另一个副作用是由于重复获取和释放锁而导致的性能下降。

GIL是解释器本身的一个单一锁，它增加的一条规则表明任何Python字节码的执行都需要获取解释锁。这有效地防止了死锁（因为只存在一个锁）并且不会带来太多的性能开销。但是这的确使每一个计算密集型任务变成了单线程。

GIL虽然也被其他语言解释器使用（如Ruby），但是这不是解决这个问题的唯一办法。一些编程语言通过使用除引用计数以外的方法（如垃圾收集）来避免GIL对线程安全内存管理的请求。

从另一方面来看，这也意味着这些语言通常需要添加其他性能提升功能（如JIT编译器）来弥补GIL单线程性能优势的损失。

为什么选取GIL作为解决方案？ 那么为什么在Python中使用了这样一种看似绊脚石的技术呢？这是Python开发人员的一个错误决定么？

正如Larry Hasting所说，GIL的设计决定是Python如今受到火热追捧的重要原因之一。

当操作系统还没有线程的概念的时候Python就一直存在着。Python设计的初衷是易于使用以便更快捷地开发，这也使得越来越多的程序员开始使用Python。

人们针对于C库中那些被Python所需的功能写了许多扩展，为了防止不一致变化，这些C扩展需要线程安全内存管理，而这些正是GIL所提供的。

GIL是非常容易实现而且很容易添加到Python中。因为只需要管理一个锁所以对于单线程任务来说带来了性能提升。

非线程安全的C库变得更容易集成，而这些C扩展则成为Python被不同社区所接受的原因之一。

正如您所看到的，GIL是CPython开发者在早期Python生涯中面对困难问题的一种实用解决方案。

对多线程Python程序的影响 当你留意一些典型的Python程序或任何计算机程序时你会发现一个程序针对计算密集型和I/O密集型任务之间的性能表现是有所差异的。

计算密集型任务是那些促使CPU达到极限的任务。这其中包括了进行数学计算的程序，如矩阵相乘、搜索、图像处理等。

I/O密集型任务是一些需要花费时间来等待来自用户、文件、数据库、网络等的输入输出的任务。I/O密集型任务有时需要等待非常久直到他们从数据源获取到他们所需要的内容为止。这是因为在准备好输入输出之前数据源本身需要先进行自身处理。举例来说，一个用户考虑在输入提示中输入什么或者在其自己进程中运行的数据库查询。

让我们先来看一个执行倒计时的简单的计算密集型程序：

 

 

在我的4核系统上运行得到以下输出：

 

 

接下来我对代码做出微调，使用两个线程并行处理来完成倒计时：

 

 

接下来我再次运行：

 

 

正如你所看到的，两个版本的完成时间相差无几。在多线程版本中GIL阻止了计算密集型任务线程并行执行。

GIL对I/O密集型任务多线程程序的性能没有太大的影响，因为在等待I/O时锁可以在多线程之间共享。

但是对于一个线程是完全计算密集型的任务来说（例如，利用线程进行部分图像处理）不仅会由于锁而变成单线程任务而且还会明显的增加执行时间。正如上例中多线程与完全单线程相比的结果。

这种执行时间的增加是由于锁带来的获取和释放开销。

如何处理Python中的GIL？ 如果GIL给你带来困扰，你可尝试一下方法：

多进程vs多线程：最流行的方法是应用多进程方法，在这个方法中你使用多个进程而不是多个线程。每一个Python进程都有自己的Python解释器和内存空间，因此GIL不会成为问题。Python拥有一个multiprocessing模块可以帮助我们轻松创建多进程：

 

 

在系统上运行得到

 

 

相比于多线程版本，性能有所提升。

但是时间并没有下降到我们之前版本的一半，这是因为进程管理有自己的开销。多进程比多线程更“重”，因此请记住，这可能成为规模瓶颈。

替代Python解释器：Python中有多个解释器实现办法，分别用C,Java,C#和Python编写的CPython，JPython，IronPython和PyPy是最受欢迎的。GIL只存在于传统的Python实现方法如CPython中。如果你的程序及其库文件可以通过别的实现方式实现，那么你也可以尝试一下。

等等看吧：许多用户利用GIL提升了单线程任务性能表现。当然多线程程序员们也不必为此烦恼，因为Python社区内的一些聪明大脑们正在致力于从CPython中删除GIL。其中一种尝试为Giletomy。

Python GIL经常被认为是一个神秘而困难的话题。但是请记住作为一名Python支持者，只有当您正在编写C扩展或者您的程序中有计算密集型的多线程任务时才会被GIL影响。

在这种情况下，这篇文章应该给了你需要的一切去了解GIL是什么以及如何在自己的项目中处理它。如果您希望了解GIL的低层次内部运行，我建议您观看David Beazley的Understanding the Python GIL。

 

识别图中二维码,领取python全套视频资料