m0_45491627的博客

另外需要注意的是await只能等待非阻塞的任务，例如想要使用await完成爬虫任务需要将常使用的requests库替换为aiohttp库，因为requests的I/O操作会阻塞线程从而协程无法完成并发操作，而aiohttp允许异步爬取多个网站信息。async with的用法和with相同，async with可以与asyncontextmanager装饰器连用，使用async with时会调用__aenter__()方法，退出async with代码块时会调用__aexit__()方法。

基于上面的介绍，我们可以看到阻塞I/O与非阻塞I/O的区别在于wait阶段进程是否被阻塞；而同步I/O与异步I/O的区别在于copy(真正的I/O操作阶段)阶段是否被阻塞。因此上面介绍的阻塞I/O、非阻塞I/O、多路复用I/O都属于同步I/O。

而解释器中的数据和py文件中的数据又是共享的，所以必须要一种锁来确保多个线程在修改数据时数据的安全性，这就是GIL锁存在的原因。需要注意的是子线程也是要抢GIL锁后才能执行的，如果子线程抢到GIL锁后发现需要修改的数据被mutex锁上了，子线程会进入阻塞状态，然后解释器会回收子线程的GIL锁。GIL锁的是解释器的数据，自定义互斥锁锁的是用户的数据。例如用户创建三个线程修改文件中的某个数据，文件中的数据属于用户自己的数据不归解释器管，所以想要文件数据能被安全的修改必须加上自定义的互斥锁。

举个例子，进程好比是车间，而线程则是车间的流水线，流水线是实际的生产工具，而车间是集合生产资源的地方。当并发的任务数远远超过了计算机的承受能力时，即无法一次性开启过多的进程数或线程数时，就应该用池将开启的进程数或线程数限制在计算机可承受的范围内。守护线程的创建方式和守护进程相同，但是守护线程需要主进程内的所有子线程都运行完以后才会结束，而守护进程则是主进程的代码运行结束就会结束了。补充一句：上面说的守护进程/线程的结束是指主进程代码结束/主进程线程结束时守护进程/线程还没运行结束会被强制结束。

互斥锁的本质是每次只有一个进程可以修改上锁的数据，当其他进程想要修改时必须排队，只有正在修改数据的进程修改完了并且打开锁以后其他进程才能修改数据。守护进程的功能：守护进程本质是一个子进程，所以其目的是并发的执行父进程的任务，但是当父进程代码运行完毕后子进程没有存在的意义了，这时就应该将该子进程设置为守护进程，守护进程会在父进程代码结束后结束。由于进程之间不共享数据，当多个进程需要使用共同的数据时就要一套共同的文件系统，但是当多个进程竞争处理文件系统的数据时就有可能出现数据错乱的问题。(可以理解为公共锁)

p=Myprocess('子进程1')如上方代码所示创建子进程p。p.terminate()表示向操作系统请求强制终止子进程p。p.is_alive()表示查看子进程是否存活。p.pid表示子进程的pid号。如果想查看父进程的pid可以在父进程使用os.getpid()或者在子进程使用os.getppid()p.name表示子进程的名称。

有了上一篇文章的分析，我们知道tcp协议之所以会出现粘包现象，是因为无法得知每次传输的字节数。如果我们人为的给传输的数据添加一个报头用来表示接收内容的字节数就可以解决这个问题了。映像名称 PID 会话名 会话# 内存使用。映像名称 PID 会话名 会话# 内存使用。(接收内容过长，中间部分略去)(接收内容过长，中间部分略去)

我们知道tcp协议是流式协议，也就是说基于tcp协议发送消息时，服务端套接字会把需要发送的消息给自己的操作系统，而自己的操作系统将这些消息一段一段发送给客户端的操作系统，由于是一段一段的发送，客户端无法判断一条消息的始末，所以客户端套接字每次只从操作系统中取字节数限制字节的消息，当发送的消息量过大时，只有一部分消息会被接收并打印到终端上，剩余的消息依然在客户端的操作系统中。当我们再次向服务端发送消息接收消息以后，套接字会先接收上次没有接受完的消息，再接受新的消息，这就产生了粘包现象。

在同一个局域网中，由于源主机不知道目标主机的mac地址，源主机会一广播的方式发送arp报文给局域网的所有主机，当目标主机接收报文以后会缓存源主机的mac地址并发送arp报文回应，以此让源主机获取mac地址。四次挥手：当客户端发送完数据以后向服务端发送结束信息发送通道请求(FIN)，服务端接收请求并发送回应信息(ACK)，当服务端接收完数据以后会向客户端发送接收信息接收通道请求(FIN)，客户端接收请求并发送回应(ACK)，通信通道解除。mac地址是唯一的，可以用来标识计算机的身份信息。