Swoole协程的局部上下文传递：避免隐式全局状态污染的实践 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

Swoole 协程的局部上下文传递：避免隐式全局状态污染的实践

大家好，今天我们来聊聊 Swoole 协程编程中一个非常重要，但又常常被忽视的问题：局部上下文传递，以及如何避免隐式全局状态污染。在传统的 PHP 开发中，由于请求生命周期短，全局变量的使用可能不会带来太大的问题。但是，在 Swoole 的协程环境下，请求是并发执行的，如果全局变量使用不当，就会造成数据混乱，甚至导致程序崩溃。

协程并发下的隐患：全局状态污染

在 Swoole 协程中，多个协程共享同一个进程空间。这意味着，如果我们在全局范围内定义和修改变量，那么这些变量会被所有协程共享。考虑以下简单的例子：

<?php

$request_id = 0;

SwooleCoroutinerun(function () {
    for ($i = 0; $i < 2; $i++) {
        go(function () use ($i) {
            global $request_id;
            $request_id = $i;
            co::sleep(0.1); // 模拟耗时操作
            echo "Coroutine {$i}: request_id = " . $request_id . PHP_EOL;
        });
    }
});

在这个例子中，我们定义了一个全局变量 $request_id，然后在两个协程中分别对其进行赋值和读取。你可能会期望协程 0 输出 request_id = 0，协程 1 输出 request_id = 1。然而，实际的输出结果往往是：

Coroutine 0: request_id = 1
Coroutine 1: request_id = 1

或者

Coroutine 0: request_id = 0
Coroutine 1: request_id = 0

甚至更混乱的结果。这是因为协程之间存在竞争关系，当一个协程修改了 $request_id 的值后，另一个协程可能立即读取到修改后的值，导致数据错乱。这就是典型的全局状态污染。

为什么传统解决方案不适用？

你可能会想到使用传统的锁机制来解决这个问题。例如，使用 SwooleCoroutineLock 来保护 $request_id 的访问。

<?php

$request_id = 0;
$lock = new SwooleCoroutineLock();

SwooleCoroutinerun(function () {
    for ($i = 0; $i < 2; $i++) {
        go(function () use ($i, $lock) {
            global $request_id;
            $lock->lock();
            $request_id = $i;
            co::sleep(0.1);
            echo "Coroutine {$i}: request_id = " . $request_id . PHP_EOL;
            $lock->unlock();
        });
    }
});

虽然这种方式可以避免数据竞争，保证 $request_id 的正确性，但同时也引入了锁的开销，降低了程序的并发性能。更重要的是，过度使用锁会增加程序的复杂度，容易出现死锁等问题。

此外，传统的依赖注入（DI）也无法完全解决这个问题。虽然 DI 可以减少全局变量的使用，但如果依赖注入的容器本身是全局的，那么仍然存在全局状态污染的风险。

局部上下文传递：解决之道

解决全局状态污染的根本方法是避免使用全局变量，或者至少避免在协程中直接修改全局变量。我们需要将状态信息与特定的协程关联起来，实现局部上下文传递。

Swoole 提供了多种机制来实现局部上下文传递：

使用 SwooleCoroutine::getContext() 获取协程上下文

SwooleCoroutine::getContext() 可以获取当前协程的上下文对象，我们可以在这个对象上存储和读取与协程相关的数据。
```
<?php

SwooleCoroutinerun(function () {
    for ($i = 0; $i < 2; $i++) {
        go(function () use ($i) {
            $context = SwooleCoroutine::getContext();
            $context->request_id = $i;
            co::sleep(0.1);
            echo "Coroutine {$i}: request_id = " . $context->request_id . PHP_EOL;
        });
    }
});
```
在这个例子中，我们不再使用全局变量 $request_id，而是将 request_id 存储在协程的上下文中。每个协程都有自己的上下文对象，因此可以避免数据竞争。

优点： 简单易用，无需额外的依赖。

缺点： 需要手动管理上下文对象，代码可读性稍差。

使用 SwooleCoroutineContext 对象

SwooleCoroutineContext 是一个专门用于存储协程上下文数据的类。它可以更清晰地表达协程的上下文信息。

<?php

SwooleCoroutinerun(function () {
    for ($i = 0; $i < 2; $i++) {
        go(function () use ($i) {
            $context = new SwooleCoroutineContext();
            $context->request_id = $i;
            SwooleCoroutine::getContext()->context = $context; // 将Context对象关联到当前协程
            co::sleep(0.1);
            echo "Coroutine {$i}: request_id = " . SwooleCoroutine::getContext()->context->request_id . PHP_EOL;
        });
    }
});

优点： 结构清晰，易于扩展。

缺点： 需要手动创建和管理 Context 对象，代码稍显冗余。

封装请求上下文类

我们可以将与请求相关的数据封装到一个类中，然后在协程中创建这个类的实例，并将实例存储在协程的上下文中。

<?php

class RequestContext
{
    public $request_id;
    public $user_id;
    // ... 其他请求相关数据
}

SwooleCoroutinerun(function () {
    for ($i = 0; $i < 2; $i++) {
        go(function () use ($i) {
            $context = new RequestContext();
            $context->request_id = $i;
            SwooleCoroutine::getContext()->requestContext = $context; // 将RequestContext对象关联到当前协程

            co::sleep(0.1);
            echo "Coroutine {$i}: request_id = " . SwooleCoroutine::getContext()->requestContext->request_id . PHP_EOL;
        });
    }
});

优点： 代码结构清晰，易于维护和扩展，可以方便地添加和修改请求相关的数据。

缺点： 需要定义额外的类，增加了一定的代码量。

使用 SwooleCoroutine::call_user_func 或 SwooleCoroutine::call_user_func_array

这两个函数允许我们传递参数到协程执行的函数中，从而避免使用全局变量。

<?php

function processRequest(int $request_id)
{
    co::sleep(0.1);
    echo "Coroutine {$request_id}: request_id = " . $request_id . PHP_EOL;
}

SwooleCoroutinerun(function () {
    for ($i = 0; $i < 2; $i++) {
        go(function () use ($i) {
            SwooleCoroutine::call_user_func('processRequest', $i);
        });
    }
});

优点： 简单直接，无需额外的上下文管理。

缺点： 只能传递有限数量的参数，不适用于复杂的请求上下文。

选择合适的上下文传递方式

不同的上下文传递方式适用于不同的场景。下面是一个简单的对比表格：

方式	优点	缺点	适用场景
`SwooleCoroutine::getContext()`	简单易用，无需额外依赖	代码可读性稍差，需要手动管理上下文对象	简单的上下文传递，只需要存储少量数据
`SwooleCoroutineContext`	结构清晰，易于扩展	需要手动创建和管理 `Context` 对象，代码稍显冗余	需要存储多个相关数据，且希望代码结构清晰
封装请求上下文类	代码结构清晰，易于维护和扩展，可以方便地添加和修改请求相关的数据	需要定义额外的类，增加了一定的代码量	需要存储大量的请求相关数据，且需要频繁地修改和扩展数据结构
`SwooleCoroutine::call_user_func`	简单直接，无需额外的上下文管理	只能传递有限数量的参数，不适用于复杂的请求上下文	只需要传递少量参数，且不需要复杂的上下文管理

在实际开发中，我们需要根据具体的业务需求和代码复杂程度，选择合适的上下文传递方式。

最佳实践：结合依赖注入和协程上下文

为了更好地管理协程的上下文，我们可以将依赖注入和协程上下文结合起来使用。首先，我们定义一个请求上下文类，并将需要的依赖注入到这个类中。然后，在协程中创建这个类的实例，并将实例存储在协程的上下文中。

<?php

use PsrLogLoggerInterface;

class RequestContext
{
    public $request_id;
    public $user_id;
    private $logger;

    public function __construct(LoggerInterface $logger)
    {
        $this->logger = $logger;
    }

    public function log(string $message)
    {
        $this->logger->info($message, ['request_id' => $this->request_id]);
    }
}

// 假设我们有一个依赖注入容器
$container = new DIContainer();

SwooleCoroutinerun(function () use ($container) {
    for ($i = 0; $i < 2; $i++) {
        go(function () use ($i, $container) {
            // 从容器中获取 LoggerInterface 的实例
            /** @var LoggerInterface $logger */
            $logger = $container->get(LoggerInterface::class);

            // 创建 RequestContext 实例，并注入 LoggerInterface
            $context = new RequestContext($logger);
            $context->request_id = $i;
            SwooleCoroutine::getContext()->requestContext = $context;

            // 使用 RequestContext 的 log 方法记录日志
            $context->log("Processing request");

            co::sleep(0.1);
            echo "Coroutine {$i}: request_id = " . SwooleCoroutine::getContext()->requestContext->request_id . PHP_EOL;
        });
    }
});

在这个例子中，我们使用依赖注入容器来管理 LoggerInterface 的实例，并将这个实例注入到 RequestContext 中。这样，我们就可以在 RequestContext 中使用 LoggerInterface 来记录日志，而无需在协程中手动创建 LoggerInterface 的实例。

优点：

代码结构清晰，易于维护和扩展。
可以方便地管理依赖关系，减少代码的耦合度。
可以更好地利用依赖注入容器的特性，例如单例模式、延迟加载等。

缺点：

需要引入依赖注入容器，增加了一定的复杂度。
需要熟悉依赖注入的概念和使用方法。

避免常见的陷阱

在使用协程上下文传递时，需要注意以下几个常见的陷阱：

不要在协程外部访问协程上下文

协程上下文只在协程内部有效。如果在协程外部访问协程上下文，会导致错误。

<?php

SwooleCoroutinerun(function () {
    go(function () {
        $context = SwooleCoroutine::getContext();
        $context->request_id = 123;
    });
});

// 错误：在协程外部访问协程上下文
// echo SwooleCoroutine::getContext()->request_id; // 会报错或者得到不确定的结果

注意协程上下文的生命周期

协程上下文的生命周期与协程的生命周期相同。当协程结束时，协程上下文也会被销毁。因此，不要在协程结束后访问协程上下文。
避免在多个协程之间共享协程上下文

虽然可以在多个协程之间共享协程上下文，但这会引入数据竞争的风险。因此，除非有特殊的需求，否则应该避免在多个协程之间共享协程上下文。
谨慎使用全局单例模式
全局单例模式本质上是一种全局状态。在协程环境下，如果单例对象的状态被修改，可能会影响到其他协程。因此，在协程环境下，应该谨慎使用全局单例模式。如果确实需要使用单例模式，可以考虑使用协程级别的单例，即每个协程都拥有自己的单例对象。

总结一下

总的来说，在 Swoole 协程编程中，避免全局状态污染是一个非常重要的问题。通过使用局部上下文传递，我们可以将状态信息与特定的协程关联起来，从而避免数据竞争，提高程序的并发性能和稳定性。选择合适的上下文传递方式，结合依赖注入，可以使我们的代码更加清晰、易于维护和扩展。谨记避免常见的陷阱，才能写出高效、可靠的 Swoole 协程程序。

如何选择合适的策略

根据项目规模和复杂性选择，简单的用getContext，需要封装数据结构的用Context类，复杂的用DI容器。

正确使用协程上下文是关键

协程上下文是避免全局状态污染的有效手段，正确使用是写出高效、可靠Swoole协程应用的关键。