python threading多线程

threading简介

python 基础库提供了两个线程模块，thread,和thrading,threading模块是对thread模块进行了封装，提供了更方便的API来操作线程，所以大多数情况下我们使用threading模块就可以。

Thread基本使用方式

Python中使用线程有两种方式：函数或者用类来包装线程对象

使用函数

使用threading.Thread的构造函数生成一个线程对象，target设置要调用的函数，name设置线程的名字，start()是启动此线程，join()等待Worker_A线程运行完后再执行MainThread线程的代码。

执行结果如下：

继承Thread类

继承threading.Thread类，Worker初始时需要调用父类的初始化方法，

然后重写父类的run方法，执行结果和上面的效果一样。

threading_API

方法：

threading.active_count() 返回当前处于 active 状态的线程的数目。

threading.current_thread() 返回调用者当前的 Thread 对象。

threading.enumerate() 返回当前处于 active 状态的线程组成的列表。

threading.stack_size([size]) 返回创建线程时分配的栈空间大小，或通过参数进行设定。

常量：

threading.TIMEOUT_MAX 此常量限定 timeout 参数的最大值，超则OverflowError（3.2新增）。

Thread_API

方法

Thread.start() 开始线程。

Thread.run() 线程实际执行的内容

Thread.join(timeout=None) 被调用 join() 方法的线程会一直阻塞调用者的线程，直到自己结束（正常结束，或引发未处理异常），或超出 timeout 的时间。

is_alive() 返回本线程是否是 alive 状态。

setDaemon() 设置为“daemon thread”,一定要在 start() 被调用前设定。

锁Lock

线程之间是可以共享资源的，如果不进行资源的合理分配，对数据造成破坏，使得线程运行的结果不可预期。这种现象称为“线程不安全。

下面举个栗子：

有的同学认为最终的number为,实事是这样嘛？肯定不是了，是的话我还讲什么呢？最终的number的值是不固定的，每次运行时产生的值都是不一样的。

为什么会出现这种情况呢？有的同学可能猜到了，没错，就是python ps:这个只在解析器才会有。

简单地说，Python全局解释器锁或GIL是一个互斥体（或锁），它只允许一个线程来控制Python解释器。

这意味着只有一个线程可以在任何时间点处于执行状态。对于执行单线程程序的开发人员来说，GIL的影响是不可见的，但它可能成为CPU绑定和多线程代码中的性能瓶颈。

由于GIL一次只允许一个线程执行，即使在多线程架构中也有多个CPU内核，GIL已经获得了Python“臭名昭着”的声誉。

GIL在遇到IO操作，或执行到一定数量的字节码时就会释放出来GIL这把锁出来。

下面来解析一下上面的代码为什么会出现这种情况：

这看上去好像是一行代码，实际反译到字节码就不是这样子了。下面来看一下add方法的字节码。

这是啥，看不懂哇，我也看不懂

没关系，我们只需要关注下面的字节码，看到仅就生成了这5条字码，就是说在执行某一行字节码时就有可能把GIL锁释放出去。

比如：

thread1: number +1，也就是 0+1 ，这时候，跳到thread2

thread2: number -1 也就是 0-1 ，这时候，跳到thread1

thread1：number = 0+1 也就是此时的number的值是1，这时候，跳到thread2

thread:number = 0-1 也就是此时的number的值是-1。

这理就可以看出number的值已经是错了，当然这种是极端的情况。

那我怎么解决上面的问题呢？没错，加锁,将上面的代码修改为：

死锁

在使用锁的时候一定要注意死锁的问题：

est1:获得了Lock_A这把锁,休眠1秒,跳Test2

Test2:获得了Lock_B这把锁,休眠1秒,跳Test1

Test1：等待Lock_B这把锁释放,跳Test2

Test2：等待Lock_A这把锁释放,跳Test2

可以看得出现，都在互相等锁释放，从而造成了死锁现象。

End

如果你觉得还不错，那就点个赞吧

听说喜欢留言、分享的人

运气都不会差

python笔记侠