Python 多线程锁详解

线程锁 Lock

多线程和多进程最大的不同在于，多进程中，同一个变量，各自有一份拷贝存在于每个进程中，互不影响，而多线程中，所有变量都由所有线程共享，所以，任何一个变量都可以被任何一个线程修改，因此，线程之间共享数据最大的危险在于多个线程同时改一个变量，把内容给改乱了。

先看一个没有加锁的操作

balance = 0
def change_it_without_lock(n):
    global balance
    # 不加锁的话 最后的值不是0
    # 线程共享数据危险在于 多个线程同时改同一个变量
    # 如果每个线程按顺序执行，那么值会是0， 但是线程时系统调度，又不确定性，交替进行
    # 没锁的话，同时修改变量
    # 所以加锁是为了同时只有一个线程再修改，别的线程表一定不能改
    for i in range(100000):
        balance = balance + n
        balance = balance - n

    print balance

threads = [
    threading.Thread(target=change_it_without_lock, args=(8,) ),
    threading.Thread(target=change_it_without_lock, args=(10,) )
]

[t.start() for t in threads]
[t.join() for t in threads]

print balance

我们定义了一个共享变量balance，初始值为0，并且启动两个线程，先存后取，理论上结果应该为0
但是，由于线程的调度是由操作系统决定的，当t1、t2交替执行时，只要循环次数足够多，balance的结果就不一定是0了。

按照一个线程的思想， balance无论处理循环多少次都是等于0的，然而开了2个线程最后结果却不是0，那是因为两个线程交换进行，操作没有原子性，比如，
线程1进行到 balance=balance + 8 == 0 + 8 = 8
此时切换到线程2，线程2拿到的balance=8, 进行balance = 8 + 10 = 18，
此时切换到前程1 ，balance = balance - 8 = 18-8=10 ! = 0
线程1的结果已经不等0，之后的结果也会乱套，就是因为操作没有原子性，
所以我们多线程操作同一个资源（这里就是全局变量balance）的时候，需要加锁

加锁修改后，代码

def change_it_with_lock(n):
    global balance
    if lock.acquire():
        try
            for i in range(100000):
                balance = balance + n
                balance = balance - n
        # 这里的finally 防止中途出错了，也能释放锁
        finally:
            lock.release()
threads = [
    threading.Thread(target=change_it_without_lock, args=(8,) ),
    threading.Thread(target=change_it_without_lock, args=(10,) )
]
lock = threading.Lock()
[t.start() for t in threads]
[t.join() for t in threads]

print balance
# 这里的结果一定是0

线程死锁

线程的一大问题就是通过加锁来”抢夺“共享资源的时候有可能造成死锁，例如下面的程序：

import threading
import os
import time
import random

balance=0
def change_it(n, lock):
    global balance
    threading_name = threading.currentThread().name
    if lock.acquire():
        try:
            for i in range(1000000):
                balance = balance + n
                balance = balance - n
                #time.sleep(random.random())
                # 中途错误，会死锁，所以应该包个try finally 释放锁
                # 假设线程1中途错误， 没有释放锁
                if i == 200 and threading_name == 'Thread-1':
                    print 'set error', threading_name
                    raise Exception('hah')

            #  循环完释放锁， 但是线程1来不到这里 已经出错了
            lock.release()
        except Exception, e:
            print 'error', threading_name
            pass
        finally:
            pass
            print 'release lock', threading_name
            print 'i is ',  i, threading_name
            # 这里注释了， 最安全的做法应该释放锁是放在这里的， 我们为了演示死锁，注释掉
            #lock.release()
lock2 = threading.Lock()

t1 = threading.Thread(target=change_it, args=(5, lock2))
t2 = threading.Thread(target=change_it, args=(5, lock2))
t1.start()
t2.start()
t1.join()
t2.join()
print balance

还有一种死锁不是由于内部错误，没有合理释放锁导致的， 就是两个线程都在等待对方的锁，看下面代码：

from threading import Lock  
_base_lock = Lock()  
_pos_lock  = Lock()  
_base = 1

def _sum(x, y):  
    # Time 1
    with _base_lock:
        # Time 3
        with _pos_lock:
            result = x + y
    return result
def _minus(x, y):  
    # Time 0
    with _pos_lock:
        # Time 2
        with _base_lock:
            result = x - y
    return result

由于线程的调度执行顺序是不确定的，在执行上面两个线程 _sum/_minus
的时候就有可能出现注释中所标注的时间顺序，即 # Time 0
的时候运行到 with _pos_lock
获取了_pos_lock 锁，
而接下来由于阻塞马上切换到了 _sum 中的 # Time 1，并获取了_base_lock
，接下来由于两个线程互相锁定了彼此需要的下一个锁，将会导致死锁，即程序无法继续运行。根据 我是一个线程 中所描述的，为了避免死锁，需要所有的线程按照指定的算法（或优先级）来进行加锁操作。不管怎么说，死锁问题都是一件非常伤脑筋的事，原因之一在于不管线程实现的是并发还是并行，在编程模型和语法上看起来都是并行的，而我们的大脑虽然是一个（内隐的）绝对并行加工的机器，却非常不善于将并行过程具象化（至少在未经足够训练的时候）。而与线程相比，协程（尤其是结合事件循环）无论在编程模型还是语法上，看起来都是非常友好的单线程同步过程。