8.12. python下划线的作用 三次握手四次挥手流程 线程进程的关系以及GIL

8.12 Python作业： python下划线的作用 三次握手四次挥手流程 线程进程的关系以及GIL

python下划线的作用

python中下划线：

单前导下划线：_var
单末尾下划线：var_
双前导下划线：__var
双前导和末尾下划线：_var_

单下划线：_

单前导下划线 _var

以单个下划线开头的变量或方法仅供内部使用。“单下划线” 开始的成员变量叫做保护变量，意思是只有类对象和子类对象自己能访问到这些变量；
以单下划线开头（_foo）的代表不能直接访问的类属性，需通过类提供的接口进行访问，不能用“from xxx import *”而导入

####单末尾下划线 var_

单个末尾下划线（后缀）是一个约定，用来避免与Python关键字产生命名冲突。

####双前导下划线 __var

“双下划线” 开始的是私有成员，意思是只有类对象自己能访问，连子类对象也不能访问到这个数据。类的私有成员

####双前导和双末尾下划线 var

以双下划线开头和结尾的（foo）代表python里特殊方法专用的标识，如 init（）代表类的构造函数。

####单下划线 _

单个独立下划线是用作一个名字，来表示某个变量是临时的或无关紧要的。

三次握手四次挥手流程

[外链图片转存失败(img-uUvSYpXB-1565608355334)(/Users/shaojun/Desktop/Python笔记/20190227105556562.png)]

初始状态：客户端A和服务器B均处于CLOSED状态，然后服务器B创建socket，调用监听接口使得服务器处于LISTEN状态，等待客户端连接。（后续内容用A，B简称代替）

A首先向B发起连接，这时TCP头部中的SYN标识位值为1，然后选定一个初始序号seq=x（一般是随机的），消息发送后，A进入SYN_SENT状态，SYN=1的报文段不能携带数据，但要消耗一个序号。

B收到A的连接请求后，同意建立连接，向A发送确认数据，这时TCP头部中的SYN和ACK标识位值均为1，确认序号为ack=x+1，然后选定自己的初始序号seq=y（一般是随机的），确认消息发送后，B进入SYN_RCVD状态，与连接消息一样，这条消息也不能携带数据，同时消耗一个序号。

A收到B的确认消息后，需要给B回复确认数据，这时TCP头部中的ACK标识位值为1，确认序号是ack=y+1，自己的序号在连接请求的序号上加1，也就是seq=x+1，此时A进入ESTABLISHED状态，当B收到A的确认回复后，B也进入ESTABLISHED状态，至此TCP成功建立连接，A和B之间就可以通过这个连接互相发送数据了。

[外链图片转存失败(img-wwoARWuN-1565608355335)(/Users/shaojun/Desktop/Python笔记/20190227105622734.png)]

初始状态：客户端A和服务器B之间已经建立了TCP连接，并且数据发送完成，打算断开连接，此时客户端A和服务器B是等价的，双方都可以发送断开请求，下面以客户端A主动发起断开请求为例。（后续内容用A，B简称代替）

A首先向B发送断开连接消息，这时TCP头部中的FIN标识位值为1，序号是seq=m，m为A前面正常发送数据最后一个字节序号加1得到的，消息发送后A进入FNI_WAIT_1状态，FIN=1的报文段不能携带数据，但要消耗一个序号。

B收到A的断开连接请求需要发出确认消息，这时TCP头部中的ACK标识位值为1，确认号为ack=m+1，而自己的序号为seq=n,n为B前面正常发送数据最后一个字节序号加1得到的，然后B进入CLOSE_WAIT状态，此时就关闭了A到B的连接，A无法再给B发数据，但是B仍然可以给A发数据（此处存疑），同时B端通知上方应用层，处理完成后被动关闭连接。然后A收到B的确认信息后，就进入了FIN_WAIT_2状态。

B端应用层处理完数据后，通知关闭连接，B向A发送关闭连接的消息，这时TCP头部中的FIN和ACK标识位值均为1，确认号ack=m+1，自己的序号为seq=k，（B发出确认消息后有发送了一段数据，此处存疑），消息发送后B进入LACK_ACK状态。

A收到B的断开连接的消息后，需要发送确认消息，这是这时TCP头部中的ACK标识位值为1，确认号ack=k+1，序号为m+1（因为A向B发送断开连接的消息时消耗了一个消息号），然后A进入TIME_WAIT状态，若等待时间经过2MSL后，没有收到B的重传请求，则表明B收到了自己的确认，A进入CLOSED状态，B收到A的确认消息后则直接进入CLOSED状态。至此TCP成功断开连接。

GIL（全局解析器锁）

GIL是什么

首先需要明确的一点是GIL并不是Python的特性，它是在实现Python解析器(CPython)时所引入的一个概念。

官方给出的解释：

In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython’s memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)

译文：

在CPython中，全局解释器锁(global interpreter lock, GIL)是一个互斥体，它防止多个本机线程同时执行Python字节码。这个锁是必要的，主要是因为CPython的内存管理不是线程安全的。(然而，自从GIL存在以来，其他特性已经逐渐依赖于它强制执行的保证。)

为什么会有GIL

由于物理上得限制，各CPU厂商在核心频率上的比赛已经被多核所取代。为了更有效的利用多核处理器的性能，就出现了多线程的编程方式，而随之带来的就是线程间数据一致性和状态同步的困难。即使在CPU内部的Cache也不例外，为了有效解决多份缓存之间的数据同步时各厂商花费了不少心思，也不可避免的带来了一定的性能损失。

Python当然也逃不开，为了利用多核，Python开始支持多线程。而解决多线程之间数据完整性和状态同步的最简单方法自然就是加锁。 于是有了GIL这把超级大锁，而当越来越多的代码库开发者接受了这种设定后，他们开始大量依赖这种特性（即默认python内部对象是thread-safe的，无需在实现时考虑额外的内存锁和同步操作）。

慢慢的这种实现方式被发现是蛋疼且低效的。但当大家试图去拆分和去除GIL的时候，发现大量库代码开发者已经重度依赖GIL而非常难以去除了。有多难？做个类比，像MySQL这样的“小项目”为了把Buffer Pool Mutex这把大锁拆分成各个小锁也花了从5.5到5.6再到5.7多个大版为期近5年的时间，本且仍在继续。MySQL这个背后有公司支持且有固定开发团队的产品走的如此艰难，那又更何况Python这样核心开发和代码贡献者高度社区化的团队呢？

所以简单的说GIL的存在更多的是历史原因。如果推到重来，多线程的问题依然还是要面对，但是至少会比目前GIL这种方式会更优雅。

GIL的影响

从上文的介绍和官方的定义来看，GIL无疑就是一把全局排他锁。毫无疑问全局锁的存在会对多线程的效率有不小影响。甚至就几乎等于Python是个单线程的程序。
那么读者就会说了，全局锁只要释放的勤快效率也不会差啊。只要在进行耗时的IO操作的时候，能释放GIL，这样也还是可以提升运行效率的嘛。或者说再差也不会比单线程的效率差吧。理论上是这样，而实际上呢？Python比你想的更糟。

下面我们就对比下Python在多线程和单线程下得效率对比。测试方法很简单，一个循环1亿次的计数器函数。一个通过单线程执行两次，一个多线程执行。最后比较执行总时间。测试环境为双核的Mac pro。注：为了减少线程库本身性能损耗对测试结果带来的影响，这里单线程的代码同样使用了线程。只是顺序的执行两次，模拟单线程。