一、死锁现象与递归锁
进程也是有死锁的
所谓死锁： 是指两个或两个以上的进程或线程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，
它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程，
如下就是死锁
死锁-------------------
from threading import Thread,Lock,RLock
import time
mutexA = Lock()
mutexB = Lock()
class MyThread(Thread):
def run(self):
self.f1()
self.f2()
def f1(self):
mutexA.acquire()
print(‘\033[33m%s 拿到A锁 ‘%self.name)
mutexB.acquire()
print(‘\033[45%s 拿到B锁 ‘%self.name)
mutexB.release()
mutexA.release()
def f2(self):
mutexB.acquire()
print(‘\033[33%s 拿到B锁 ‘ % self.name)
time.sleep(1) #睡一秒就是为了保证A锁已经被别人那到了
mutexA.acquire()
print(‘\033[45m%s 拿到B锁 ‘ % self.name)
mutexA.release()
mutexB.release()
if __name__ == ‘__main__‘:
for i in range(10):
t = MyThread()
t.start() #一开启就会去调用run方法
死锁现象
那么怎么解决死锁现象呢？
解决方法，递归锁：在Python中为了支持在同一线程中多次请求同一资源，python提供了可重入锁RLock。
这个RLock内部维护着一个Lock和一个counter变量，counter记录了acquire的次数，从而使得资源可以被多次require。
直到一个线程所有的acquire都被release，其他的线程才能获得资源。上面的例子如果使用RLock代替Lock，则不会发生死锁
mutexA=mutexB=threading.RLock() #一个线程拿到锁，counter加1,该线程内又碰到加锁的情况，<br>则counter继续加1，这期间所有其他线程都只能等待，等待该线程释放所有锁，即counter递减到0为止
# 2.解决死锁的方法--------------递归锁
from threading import Thread,Lock,RLock
import time
mutexB = mutexA = RLock()
class MyThread(Thread):
def run(self):
self.f1()
self.f2()
def f1(self):
mutexA.acquire()
print(‘\033[33m%s 拿到A锁 ‘%self.name)
mutexB.acquire()
print(‘\033[45%s 拿到B锁 ‘%self.name)
mutexB.release()
mutexA.release()
def f2(self):
mutexB.acquire()
print(‘\033[33%s 拿到B锁 ‘ % self.name)
time.sleep(1) #睡一秒就是为了保证A锁已经被别人拿到了
mutexA.acquire()
print(‘\033[45m%s 拿到B锁 ‘ % self.name)
mutexA.release()
mutexB.release()
if __name__ == ‘__main__‘:
for i in range(10):
t = MyThread()
t.start() #一开启就会去调用run方法
解决死锁
二、信号量Semaphore（其实也是一把锁）
Semaphore管理一个内置的计数器
Semaphore与进程池看起来类似，但是是完全不同的概念。
进程池：Pool(4)，最大只能产生四个进程，而且从头到尾都只是这四个进程，不会产生新的。
信号量：信号量是产生的一堆进程/线程，即产生了多个任务都去抢那一把锁
from threading import Thread,Semaphore,currentThread
import time,random
sm = Semaphore(5) #运行的时候有5个人
def task():
sm.acquire()
print(‘\033[42m %s上厕所‘%currentThread().getName())
time.sleep(random.randint(1,3))
print(‘\033[31m %s上完厕所走了‘%currentThread().getName())
sm.release()
if __name__ == ‘__main__‘:
for i in range(20): #开了10个线程 ，这20人都要上厕所
t = Thread(target=task)
t.start()
Semaphore举例
hread-1上厕所 Thread-2上厕所 Thread-3上厕所 Thread-4上厕所 Thread-5上厕所 Thread-3上完厕所走了 Thread-6上厕所 Thread-1上完厕所走了 Thread-7上厕所 Thread-2上完厕所走了 Thread-8上厕所 Thread-6上完厕所走了 Thread-5上完厕所走了 Thread-4上完厕所走了 Thread-9上厕所 Thread-10上厕所 Thread-11上厕所 Thread-9上完厕所走了 Thread-12上厕所 Thread-7上完厕所走了 Thread-13上厕所 Thread-10上完厕所走了 Thread-8上完厕所走了 Thread-14上厕所 Thread-15上厕所 Thread-12上完厕所走了 Thread-11上完厕所走了 Thread-16上厕所 Thread-17上厕所 Thread-14上完厕所走了 Thread-15上完厕所走了 Thread-17上完厕所走了 Thread-18上厕所 Thread-19上厕所 Thread-20上厕所 Thread-13上完厕所走了 Thread-20上完厕所走了 Thread-16上完厕所走了 Thread-18上完厕所走了 Thread-19上完厕所走了
运行结果
三、Event
线程的一个关键特性是每个线程都是独立运行且状态不可预测。如果程序中的其 他线程需要通过判断某个线程的状态来确定自己下一步的操作,这时线程同步问题就会变得非常棘手。为了解决这些问题,我们需要使用threading库中的Event对象。 对象包含一个可由线程设置的信号标志,它允许线程等待某些事件的发生。在 初始情况下,Event对象中的信号标志被设置为假。如果有线程等待一个Event对象, 而这个Event对象的标志为假,那么这个线程将会被一直阻塞直至该标志为真。一个线程如果将一个Event对象的信号标志设置为真,它将唤醒所有等待这个Event对象的线程。如果一个线程等待一个已经被设置为真的Event对象,那么它将忽略这个事件, 继续执行
from threading import Event Event.isSet() #返回event的状态值 Event.wait() #如果 event.isSet()==False将阻塞线程； Event.set() #设置event的状态值为True，所有阻塞池的线程激活进入就绪状态， 等待操作系统调度； Event.clear() #恢复
四、定时器（Timer）
指定n秒后执行某操作
from threading import Timer
def func(n):
print(‘hello,world‘,n)
t = Timer(3,func,args=(123,)) #等待三秒后执行func函数，因为func函数有参数，那就再传一个参数进去
t.start()
五、线程queue
queue队列 ：使用import queue，用法与进程Queue一样
queue.Queue(maxsize=0) #先进先出
queue.LifoQueue(maxsize=0)#先进后出
queue.PriorityQueue(maxsize=0) #存储数据时可设置优先级的队列
# ---------------- ‘‘‘3.put进入一个元组，元组的第一个元素是优先级 （通常也可以是数字，或者也可以是非数字之间的比较） 数字越小，优先级越高‘‘‘ q = queue.PriorityQueue() q.put((20,‘a‘)) q.put((10,‘b‘)) #先出来的是b,数字越小优先级越高嘛 q.put((30,‘c‘)) print(q.get()) print(q.get()) print(q.get())
六、多线程性能测试
1.多核也就是多个CPU（1）cpu越多，提高的是计算的性能（2）如果程序是IO操作的时候（多核和单核是一样的），再多的cpu也没有意义。2.实现并发第一种：一个进程下，开多个线程第二种：开多个进程3.多进程： 优点：可以利用多核 缺点：开销大4.多线程 优点：开销小 缺点：不可以利用多核5多进程和多进程的应用场景 1.计算密集型：也就是计算多，IO少 如果是计算密集型，就用多进程（如金融分析等） 2.IO密集型：也就是IO多，计算少 如果是IO密集型的，就用多线程（一般遇到的都是IO密集型的）
原文地址：https://www.cnblogs.com/edison-chen/p/9777413.html