进程同步（锁）
因为进程之间数据不共享，在多个进程同时操作同一块数据（文件数据等）时，会发生写乱数据的问题，例如多进程抢票。
这时我们可以加锁处理，加锁可以保证多个进程修改同一块数据时，同一时间只能有一个任务可以进行修改，即串行的修改，这样速度是慢了，但牺牲了速度却保证了数据的安全。
#多进程抢票
import time
## 不加锁 去掉lock
import json
from multiprocessing import Process,Lock
## 查询票余额
def check(i):
with open('ticket', 'rt', encoding='utf-8') as f:
res = json.load(f)
print('%s:在查询票，票还剩%s张' % (i, res['count']))
if res['count'] > 0:
return True
## 抢票，票的余额减一
def buy(i):
with open('ticket', 'rt', encoding='utf-8') as f:
res = json.load(f)
time.sleep(1) # 模拟查票延迟
if res['count'] > 0:
print('%s现在要买了，票数还是大于0'%i)
res['count'] -= 1
time.sleep(2) # 模拟买票延迟
with open('ticket', 'wt', encoding='utf-8') as f1:
json.dump(res, f1)
print('%s这个人购票成功' % i)
else:
print('%s这个人购票失败，票不够了，买不了了' % i)
def task(i,lock):
res = check(i)
if res:
lock.acquire()
buy(i)
lock.release()
##模拟10个人买票
if __name__ == '__main__':
lock=Lock()
for i in range(10):
p = Process(target=task, args=[i,lock ])
p.start()
虽然可以用文件共享数据实现进程间通信，但问题是：
- 效率低（共享数据基于文件，而文件是硬盘上的数据）
- 需要自己加锁处理
因此我们最好找寻一种解决方案能够兼顾：
- 效率高（多个进程共享一块内存的数据）
- 帮我们处理好锁问题。这就是mutiprocessing模块为我们提供的基于消息的IPC通信机制：队列和管道。
队列和管道都是将数据存放于内存中，队列又是基于（管道+锁）实现的，可以让我们从复杂的锁问题中解脱出来，我们应该尽量避免使用共享数据，尽可能使用消息传递和队列，避免处理复杂的同步和锁问题，而且在进程数目增多时，往往可以获得更好的可获展性
ps: 队列在这： https://www.cnblogs.com/lzl121/p/14693201.html
同步锁（互斥锁）
线程之间数据共享，所以当多个线程几乎同时要修改某一个共享数据的时候，需要进行同步控制。线程同步能够保证多个线程安全访问竞争资源，最简单的同步机制是引入互斥锁（同步锁）。
某个线程要更改共享数据时，先将其锁定，此时资源的状态为“锁定”，其他线程不能更改；直到该线程释放资源，将资源的状态变成“非锁定”，其他的线程才能再次锁定该资源，进而操作数据。互斥锁保证了每次只有一个线程进行写入操作，从而保证了多线程情况下数据的正确性。
锁的优点：确保了某段关键代码只能由一个线程执行，保证数据安全
锁的缺点：阻止了多线程并发执行，包含锁的某段代码实际上只能以单线程模式执行，效率下降；还可能造成死锁
全局解释器锁（GIL）
在Cpython解释器中，同一个进程下开启的多线程，同一时刻只能有一个线程执行，无法利用多核优势
首先需要明确的一点是GIL并不是Python的特性，它是在实现Python解析器(CPython)时所引入的一个概念。就好比C++是一套语言（语法）标准，但是可以用不同的编译器来编译成可执行代码。有名的编译器例如GCC，INTEL C++，Visual C++等。Python也一样，同样一段代码可以通过CPython，PyPy，Psyco等不同的Python执行环境来执行。像其中的JPython就没有GIL。然而因为CPython是大部分环境下默认的Python执行环境。所以在很多人的概念里CPython就是Python，也就想当然的把GIL归结为Python语言的缺陷。所以这里要先明确一点：GIL并不是Python的特性，Python完全可以不依赖于GIL
为什么要有GIL,还是历史问题，百度
GIL本质就是一把互斥锁，既然是互斥锁，所有互斥锁的本质都一样，都是将并发运行变成串行，以此来控制同一时间内共享数据只能被一个任务所修改，进而保证数据安全。
GIL保护的是解释器级的数据(垃圾回收机制数据等)，保护用户自己的数据则需要自己加锁处理
GIL和多线程
有了GIL的存在，同一时刻同一进程中只有一个线程被执行
对计算来说，cpu越多越好，但是对于I/O来说，再多的cpu也没用
当然对运行一个程序来说，随着cpu的增多执行效率肯定会有所提高（不管提高幅度多大，总会有所提高），这是因为一个程序基本上不会是纯计算或者纯I/O，所以我们只能相对的去看一个程序到底是计算密集型还是I/O密集型，从而进一步分析python的多线程到底有无用武之地
#分析：
我们有四个任务需要处理，处理方式肯定是要玩出并发的效果，解决方案可以是：
方案一：开启四个进程
方案二：一个进程下，开启四个线程
#单核情况下，分析结果:
如果四个任务是计算密集型，没有多核来并行计算，方案一徒增了创建进程的开销，方案二胜
如果四个任务是I/O密集型，方案一创建进程的开销大，且进程的切换速度远不如线程，方案二胜
#多核情况下，分析结果：
如果四个任务是计算密集型，多核意味着并行计算，在python中一个进程中同一时刻只有一个线程执行用不上多核，方案一胜
如果四个任务是I/O密集型，再多的核也解决不了I/O问题，方案二胜
#结论：现在的计算机基本上都是多核，python对于计算密集型的任务开多线程的效率并不能带来多大性能上的提升，甚至不如串行(没有大量切换)，但是，对于IO密集型的任务效率还是有显著提升的。
多线程用于IO密集型，如socket，爬虫，web
多进程用于计算密集型，如金融分析
死锁与递归锁（进程线程都有）
所谓死锁： 是指两个或两个以上的进程或线程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程，如下就是死锁
from threading import Thread,Lock
import time
mutexA=Lock()
mutexB=Lock()
class MyThread(Thread):
def run(self):
self.func1()
self.func2()
def func1(self):
mutexA.acquire()
print('\033[41m%s 拿到A锁\033[0m' %self.name)
mutexB.acquire()
print('\033[42m%s 拿到B锁\033[0m' %self.name)
mutexB.release()
mutexA.release()
def func2(self):
mutexB.acquire()
print('\033[43m%s 拿到B锁\033[0m' %self.name)
time.sleep(2)
mutexA.acquire()
print('\033[44m%s 拿到A锁\033[0m' %self.name)
mutexA.release()
mutexB.release()
if __name__ == '__main__':
for i in range(10):
t=MyThread()
t.start()
'''
Thread-1 拿到A锁
Thread-1 拿到B锁
Thread-1 拿到B锁
Thread-2 拿到A锁
然后就卡住，死锁了
'''
解决方法，递归锁，在Python中为了支持在同一线程中多次请求同一资源，python提供了可重入锁RLock。
这个RLock内部维护着一个Lock和一个counter变量，counter记录了acquire的次数，从而使得资源可以被多次require。直到一个线程所有的acquire都被release，其他的线程才能获得资源。上面的例子如果使用RLock代替Lock，则不会发生死锁：
mutexA=mutexB=threading.RLock() #一个线程拿到锁，counter加1,该线程内又碰到加锁的情况，则counter继续加1，这期间所有其他线程都只能等待，等待该线程释放所有锁，即counter递减到0为止
