今天上了一天的公选课，唉..现在晚上有时间接着昨天的问题来。
- 理解python中的全局解释锁
- 测试下cpu密集型和io密集型多线程的差异
1 .python中的全局解释锁(GIL)
推荐一篇解释GIL的文章
http://cenalulu.github.io/python/gil-in-python/作者：卢钧轶(cenalulu)
我总结了一下GIL大概是这么一回事。
- GIL是Cpython解释器引入的一个概念，并不是python特有的特性，意思你换个解释器可能就没这问题了,比如pypy,Jpython。
- GIL的存在是为了解决解释器中多线程中资源共享的问题，可能因为设计的原因，留下了这么一个bug,导致一个时刻只能有一个线程运行。
GIL导致的影响
1.同一时刻只能跑一个线程，不能真正利用多核CPU.
- 多线程不适合跑CPU密集型的任务，可能速度会更慢，可以利用多线程来替换。
- 利用多线程来跑io密集型任务，是可以提升效率的。
截了上面那篇文章的一段话：
为了直观的理解GIL对于多线程带来的性能影响，这里直接借用的一张测试结果图（见下图）。图中表示的是两个线程在双核CPU上得执行情况。两个线程均为CPU密集型运算线程。绿色部分表示该线程在运行，且在执行有用的计算，红色部分为线程被调度唤醒，但是无法获取GIL导致无法进行有效运算等待的时间。
GIL Performance
由图可见，GIL的存在导致多线程无法很好的立即多核CPU的并发处理能力。
那么Python的IO密集型线程能否从多线程中受益呢？我们来看下面这张测试结果。颜色代表的含义和上图一致。白色部分表示IO线程处于等待。可见，当IO线程收到数据包引起终端切换后，仍然由于一个CPU密集型线程的存在，导致无法获取GIL锁，从而进行无尽的循环等待。
GIL IO Performance
简单的总结下就是：Python的多线程在多核CPU上，只对于IO密集型计算产生正面效果；而当有至少有一个CPU密集型线程存在，那么多线程效率会由于GIL而大幅下降。
2.对比下执行cpu密集型和io密集型多线程的差异
import threading
import time
# cpu密集型
def cpu_counter():
i = 0
for _ in range(100000000):
i = i + 1
return True
# io密集型
def io_counter():
with open('test_1,txt', 'w')as f:
for i in range(5000000):
f.write(f'test:{i}\n')
f.close()
print("success")
if __name__ == '__main__':
"""
cpu顺序执行：total time:26.046419620513916
cpu多线程执行：total time:26.75766134262085
io顺序执行：total time:22.917461156845093
io多线程执行：total time:22.91920042037964
"""
threads = []
start_time = time.time()
# cpu顺序执行
# for tid in range(4):
# t = threading#.Thread(target=cpu_counter)
# t.start()
# t.jo#in()
# cpu多线程执行
# for tid in range(4):
# t = threading.Thread(target=cpu_counter)
# t.start()
# threads.append(t)
# for i in range(4):
# threads[i].join()
# io 顺序执行
# for tid in range(4):
# t = threading.Thread(target=io_counter)
# t.start()
# t.join()
# io多线程执行
for tid in range(4):
t = threading.Thread(target=io_counter)
t.start()
threads.append(t)
for i in range(4):
threads[i].join()
end_time = time.time()
print(f"total time:{end_time - start_time}")
1.发现python在cpu密集型和io密集型:线性操作跟多线程并无太大差异..
明天
明天该看看threading文档了。
