深刻理解Python中的ThreadLocal变量（下）

时间 2020-02-10

标签深刻理解 python threadlocal 变量栏目 Python 繁體版

原文原文链接

在上篇咱们看到了 ThreadLocal 变量的简单使用，中篇对python中 ThreadLocal 的实现进行了分析，但故事尚未结束。本篇咱们一块儿来看下Werkzeug中ThreadLocal的设计。html

Werkzeug 做为一个 WSGI 工具库，因为一些方面的考虑，并无直接使用python内置的ThreadLocal类，而是本身实现了一系列Local类。包括简单的Local，以及在此基础上实现的LocalStack，LocalManager 和 LocalProxy。接下来咱们一块儿来看看这些类的使用方式，设计的初衷，以及具体的实现技巧。python

Local 类的设计

Werkzeug 的设计者认为python自带的ThreadLocal并不能知足需求，主要由于下面两个缘由：git

Werkzeug 主要用“ThreadLocal”来知足并发的要求，python 自带的ThreadLocal只能实现基于线程的并发。而python中还有其余许多并发方式，好比常见的协程（greenlet），所以须要实现一种可以支持协程的Local对象。github
WSGI不保证每次都会产生一个新的线程来处理请求，也就是说线程是能够复用的（能够维护一个线程池来处理请求）。这样若是werkzeug 使用python自带的ThreadLocal，一个“不干净（存有以前处理过的请求的相关数据）”的线程会被用来处理新的请求。flask

为了解决这两个问题，werkzeug 中实现了Local类。Local对象能够作到线程和协程之间数据的隔离，此外，还要支持清理某个线程或者协程下的数据（这样就能够在处理一个请求以后，清理相应的数据，而后等待下一个请求的到来）。并发

具体怎么实现的呢，思想其实特别简单，咱们在深刻理解Python中的ThreadLocal变量（上）一文的最后有提起过，就是建立一个全局字典，而后将线程（或者协程）标识符做为key，相应线程（或协程）的局部数据做为 value。这里 werkzeug 就是按照上面思路进行实现，不过利用了python的一些黑魔法，最后提供给用户一个清晰、简单的接口。app

具体实现

Local 类的实如今 werkzeug.local 中，以 8a84b62 版本的代码进行分析。经过前两篇对ThreadLocal的了解，咱们已经知道了Local对象的特色和使用方法。因此这里再也不给出Local对象的使用例子，咱们直接看代码。ide

class Local(object):
    __slots__ = ('__storage__', '__ident_func__')
    
    def __init__(self):
        object.__setattr__(self, '__storage__', {})
        object.__setattr__(self, '__ident_func__', get_ident)
    ...

因为可能有大量的Local对象，为了节省Local对象占用的空间，这里使用 __slots__ 写死了Local能够拥有的属性：函数

__storage__：值为一个字典，用来保存实际的数据，初始化为空；工具
__ident_func__：值为一个函数，用来找到当前线程或者协程的标志符。

因为Local对象实际的数据保存在__storage__中，因此对Local属性的操做实际上是对__storage__的操做。对于获取属性而言，这里用魔术方法__getattr__拦截__storage__ 和 __ident_func__之外的属性获取，将其导向__storage__存储的当前线程或协程的数据。而对于属性值的set或者del，则分别用__setattr__和__setattr__来实现（这些魔术方法的介绍见属性控制）。关键代码以下所示：

def __getattr__(self, name):
    try:
        return self.__storage__[self.__ident_func__()][name]
    except KeyError:
        raise AttributeError(name)

def __setattr__(self, name, value):
    ident = self.__ident_func__()
    storage = self.__storage__
    try:
        storage[ident][name] = value
    except KeyError:
        storage[ident] = {name: value}

def __delattr__(self, name):
    try:
        del self.__storage__[self.__ident_func__()][name]
    except KeyError:
        raise AttributeError(name)

假设咱们有ID为1，2， ... ， N 的N个线程或者协程，每一个都用Local对象保存有本身的一些局部数据，那么Local对象的内容以下图所示：

此外，Local类还提供了__release_local__方法，用来释放当前线程或者协程保存的数据。

Local 扩展接口

Werkzeug 在 Local 的基础上实现了 LocalStack 和 LocalManager，用来提供更加友好的接口支持。

LocalStack

LocalStack经过封装Local从而实现了一个线程（或者协程）独立的栈结构，注释里面有具体的使用方法，一个简单的使用例子以下：

ls = LocalStack()
ls.push(12)
print ls.top    # 12
print ls._local.__storage__
# {140735190843392: {'stack': [12]}}

LocalStack 的实现比较有意思，它将一个Local对象做为本身的属性_local，而后定义接口push, pop 和 top 方法进行相应的栈操做。这里用 _local.__storage__._local.__ident_func__() 这个list来模拟栈结构。在接口push, pop和top中，经过操做这个list来模拟栈的操做，须要注意的是在接口函数内部获取这个list时，不用像上面黑体那么复杂，能够直接用_local的getattr()方法便可。以 push 函数为例，实现以下：

def push(self, obj):
    """Pushes a new item to the stack"""
    rv = getattr(self._local, 'stack', None)
    if rv is None:
        self._local.stack = rv = []
    rv.append(obj)
    return rv

pop 和 top 的实现和通常栈相似，都是对 stack = getattr(self._local, 'stack', None) 这个列表进行相应的操做。此外，LocalStack还容许咱们自定义__ident_func__，这里用内置函数 property 生成了描述器，封装了__ident_func__的get和set操做，提供了一个属性值__ident_func__做为接口，具体代码以下：

def _get__ident_func__(self):
    return self._local.__ident_func__

def _set__ident_func__(self, value):
    object.__setattr__(self._local, '__ident_func__', value)
__ident_func__ = property(_get__ident_func__, _set__ident_func__)
del _get__ident_func__, _set__ident_func__

LocalManager

Local 和 LocalStack 都是线程或者协程独立的单个对象，不少时候咱们须要一个线程或者协程独立的容器，来组织多个Local或者LocalStack对象（就像咱们用一个list来组织多个int或者string类型同样）。

Werkzeug实现了LocalManager，它经过一个list类型的属性locals来存储所管理的Local或者LocalStack对象，还提供cleanup方法来释放全部的Local对象。Werkzeug中LocalManager最主要的接口就是装饰器方法make_middleware，代码以下：

def make_middleware(self, app):
    """Wrap a WSGI application so that cleaning up happens after
    request end.
    """
    def application(environ, start_response):
        return ClosingIterator(app(environ, start_response), self.cleanup)
    return application

这个装饰器注册了回调函数cleanup，当一个线程（或者协程）处理完请求以后，就会调用cleanup清理它所管理的Local或者LocalStack 对象（ClosingIterator 的实如今 werkzeug.wsgi中）。下面是一个使用 LocalManager 的简单例子：

from werkzeug.local import Local, LocalManager

local = Local()
local_2 = Local()
local_manager = LocalManager([local, local2])

def application(environ, start_response):
    local.request = request = Request(environ)
    ...

# application 处理完毕后，会自动清理local_manager 的内容
application = local_manager.make_middleware(application)

经过LocalManager的make_middleware咱们能够在某个线程（协程）处理完一个请求后，清空全部的Local或者LocalStack对象，这样这个线程又能够处理另外一个请求了。至此，文章开始时提到的第二个问题就能够解决了。Werkzeug.local 里面还实现了一个 LocalProxy 用来做为Local对象的代理，也很是值得去学习。

经过这三篇文章，相信对 ThreadLocal 有了一个初步的了解。Python标准库和Werkzeug在实现中都用到了不少python的黑魔法，不过最终提供给用户的都是很是友好的接口。Werkzeug做为WSGI 工具集，为了解决Web开发中的特定使用问题，提供了一个改进版本，而且进行了一系列封装，便于使用。不得不说，werkzeug的代码可读性很是好，注释也是写的很是棒，建议去阅读源码。