contextvars

contextvars 顾名思义就是 context variables，直译「上下文变量」。

什么是上下文

高中英语课让我影响最深刻的就是「上下文」这个词，每次做完型阅读的时候老师总是强调要根据上下文选出最合适的词。上下文能够给这个空词位提供某些额外的信息，有了这些信息，这个空位就能选出一个最合适的词。

Flask 的设计中就包含了 Context。这个设计有什么用呢？简单地说：可以在一些场景下隐式地传递变量

在 Django 和 Sanic 中是这样传递 Request 对象的：

# Django
from django.http import HttpResponse


def index(request):
    text = request.GET.get('text')
    return HttpResponse(f'Text is {text}')

# Sanic
from sanic import response

app = Sanic()


@app.route('/')
async def index(request):
    text = request.args.get('text')
    return response.text(f'Text is {text}')

而在 Flask 里面是这样的：

from flask import Flask, request
app = Flask(__name__)

@app.route('/')
def index():
    text = request.args.get('text')
    return f'Text is {text}'

Django、Sanic 和 Flask 的区别：在 Flask 中，request 是 import 进来使用的（不需要就不用 import），和视图解耦了。这种设计下，不需要像 Django/Sanic 那样把参数传来传去。

通过查看源码，Flask 是通过实现了一个类似 ThreadLocal 的一个 Local 类来实现 context 的传递的。

Python 本身的 ThreadLocal 是线程安全的，但是 Flask 的 Local 类支持 Greenlet 的协程。

同样类似的功能，在 Tornado 中为了配合自己的异步特性，Tornado 也实现了一个类似的 StackContext 来管理上下文。

先看一下线程库中 ThreadLocal 的例子：

import random
import threading

local_data = threading.local()


def show():
    name = threading.current_thread().getName()
    try:
        val = local_data.value
    except AttributeError:
        print(f'Thread {name}: No value yet')
    else:
        print(f'Thread {name}: {val}')


def worker():
    show()
    local_data.value = random.randint(1, 100)
    show()


for i in range(2):
    t = threading.Thread(target=worker)
    t.start()

Thread Thread-1: No value yet
Thread Thread-1: 55
Thread Thread-2: No value yet
Thread Thread-2: 48

可见不同线程中的状态是相互独立的。

Flask里，请求 Context 在内部作为一个栈来维护（应用 Context 在另外一个栈）。每个访问 Flask 的请求，会绑定到当前的 Context，等请求结束后再销毁。维护的过程由框架实现，开发者不需要关心，你只需要用 flask.request 就可以了，这样就提高了接口的可读性和扩展性。

Tornado中，如果通过 add_callback 等在 ioloop 的添加了异步回调函数，当回调函数抛出异常时，无法通过在调用 add_callback 处捕捉到该异常：

def callback():
    raise Exception('in callback')

def func():
    ioloop.add_callback(callback)

ioloop = tornado.ioloop.IOLoop.instance()
try:
    func()
except:
    print('catch the Exception')
ioloop.start()

虽然是 func 导致了 callback 的调用，进而导致异常的抛出。但实际上 callback 在 func 中被 add_callback 后并没有立即执行，只是被放到 IOLoop 中，等到适当的时机执行。当 callback 执行时，它的环境早已不是“调用时”(func)的环境，因此对 func 的 try...except 无法捕捉到异常，自然“catch the Exception”也就不会被打印。

Tornado 通过 StackContext 实现对“调用时”上下文环境的保存，其内部也是通过栈来维护不同上下文的信息。

contextvars

随着 pyton 的不断发展，异步特性逐渐加强，threading.local 针对线程的隔离效果很好，但是协程的出现我们需要一个能在协程中也能有此特性，contextvars 就提供了一组接口，可以用于管理、存储、访问局部的 context 状态：

import asyncio
import contextvars

# 申明Context变量
request_id = contextvars.ContextVar('Id of request')


async def get():
    # Get Value
    print(f'Request ID (Inner): {request_id.get()}')


async def new_coro(req_id):
    # Set Value
    request_id.set(req_id)
    await get()
    print(f'Request ID (Outer): {request_id.get()}')


async def main():
    tasks = []
    for req_id in range(1, 5):
        tasks.append(asyncio.create_task(new_coro(req_id)))

    await asyncio.gather(*tasks)


asyncio.run(main())

Request ID (Inner): 1
Request ID (Outer): 1
Request ID (Inner): 2
Request ID (Outer): 2
Request ID (Inner): 3
Request ID (Outer): 3
Request ID (Inner): 4
Request ID (Outer): 4

可见不听协程间的数据状态互不影响。

注意：这个模块不仅仅给 aio 加入 Context 的支持，也用来替代 threading.local()。

contextvars 实现了 PEP 567, 如果在 Python3.6 想使用可以用 MagicStack/contextvars 这个向后移植库，它和标准库都是同一个作者写的，可以放心使用。用之前需要安装它：

pip install contextvars

内存泄漏和上下文清理

根据 Python 文档，contextvars 对象会持有变量值的强引用，所以如果没有适当清理，会导致内存漏泄。我们使用以下代码演示这种问题：

import asyncio
import contextvars
from unittest import TestCase
import weakref

obj_context = contextvars.ContextVar('obj')
obj_ref_dict = {}


class A(object):

    def __init__(self, x):
        self.x = x

    def __repr__(self):
        return '<A|x: %d>' % self.x


async def inner(x):
    obj = A(x)
    obj_context.set(obj)
    obj_ref_dict[x] = weakref.ref(obj)


async def outer(i):
    await inner(i)
    print('obj: %s in outer request-%d from obj_ref_dict' % (obj_ref_dict[i](), i))


async def dispatcher():
    await asyncio.gather(*[
        outer(i) for i in range(0, 10)
    ])
    for i in range(0, 10):
        print('obj-%d: %s in obj_ref_dict' % (i, obj_ref_dict[i]()))


class ContextTest(TestCase):

    def test(self):
        asyncio.run(dispatcher())

obj: <A|x: 0> in outer request-0 from obj_ref_dict
obj: <A|x: 1> in outer request-1 from obj_ref_dict
obj: <A|x: 2> in outer request-2 from obj_ref_dict
obj: <A|x: 3> in outer request-3 from obj_ref_dict
obj: <A|x: 4> in outer request-4 from obj_ref_dict
obj: <A|x: 5> in outer request-5 from obj_ref_dict
obj: <A|x: 6> in outer request-6 from obj_ref_dict
obj: <A|x: 7> in outer request-7 from obj_ref_dict
obj: <A|x: 8> in outer request-8 from obj_ref_dict
obj: <A|x: 9> in outer request-9 from obj_ref_dict
obj-0: <A|x: 0> in obj_ref_dict
obj-1: <A|x: 1> in obj_ref_dict
obj-2: <A|x: 2> in obj_ref_dict
obj-3: <A|x: 3> in obj_ref_dict
obj-4: <A|x: 4> in obj_ref_dict
obj-5: <A|x: 5> in obj_ref_dict
obj-6: <A|x: 6> in obj_ref_dict
obj-7: <A|x: 7> in obj_ref_dict
obj-8: <A|x: 8> in obj_ref_dict
obj-9: <A|x: 9> in obj_ref_dict

inner 方法在调用栈的最内部设置了上下文变量 obj_context，设置上下文的同时也将保存在上下文的对象 A 的实例保存到一个弱引用中，以便后续通过弱引用来检查对象实例是否被回收。

可以看到，无论是在 outer 中，还是在 dispatcher 中，所有 inner 方法保存的上下文变量都没有被回收，所以我们必须在使用完上下文变量后显式地清理上下文，否则会导致内存泄漏。

这里，我们在 inner 方法的最后，将 obj_context 设置为 None，就可以保证不会因为上下文而导致内存不会被回收：

async def inner(x):
    obj = A(x)
    obj_context.set(obj)
    obj_ref_dict[x] = weakref.ref(obj)
    obj_context.set(None)

再次执行代码：

obj: None in outer request-0 from obj_ref_dict
obj: None in outer request-1 from obj_ref_dict
obj: None in outer request-2 from obj_ref_dict
obj: None in outer request-3 from obj_ref_dict
obj: None in outer request-4 from obj_ref_dict
obj: None in outer request-5 from obj_ref_dict
obj: None in outer request-6 from obj_ref_dict
obj: None in outer request-7 from obj_ref_dict
obj: None in outer request-8 from obj_ref_dict
obj: None in outer request-9 from obj_ref_dict
obj-0: None in obj_ref_dict
obj-1: None in obj_ref_dict
obj-2: None in obj_ref_dict
obj-3: None in obj_ref_dict
obj-4: None in obj_ref_dict
obj-5: None in obj_ref_dict
obj-6: None in obj_ref_dict
obj-7: None in obj_ref_dict
obj-8: None in obj_ref_dict
obj-9: None in obj_ref_dict

可以看到，当 outer 和 dispatcher 尝试通过弱引用来访问曾经保存在上下文的对象实例的时候，这些对象都已经被回收了。