单例模式在PHP并发环境下本质是“并发安全”而非“线程安全”问题：FPM多进程或Swoole协程中，静态变量不跨进程共享，但多个worker可能同时执行未加锁的懒汉式getInstance()导致重复实例化；推荐采用进程级隔离（每个worker独享实例）或显式同步（如Redis锁），并避免在Promise回调中依赖单例状态共享。
guzzlehttp/promises 本身不提供单例类，也不依赖单例模式；如果你在 Composer 包中（比如自定义服务类、HTTP 客户端封装、日志器或配置管理器）用了单例，并且它被 Promise 链式调用并发触发，那线程/协程安全问题就不是 Promise 自身的问题，而是你那个单例类的初始化逻辑没防住并发读写。
PHP 是多进程模型（FPM）或协程模型（Swoole、RoadRunner），没有“多线程”意义上的共享内存竞争，但并发请求下多个 worker 进程/协程同时执行同一段初始化代码，仍可能造成重复实例化、状态错乱或竞态条件。重点不在“线程安全”，而在“并发安全”。
为什么 getInstance() 在 Promise 链里会出问题
当你把一个单例的 getInstance() 放在 then() 回调里调用，尤其是多个 Promise 并发 resolve 后几乎同时执行该方法，就可能触发以下情况：
- 懒汉式未加锁：多个协程/进程看到
instance === null，各自 new 一次，覆盖彼此 - 饿汉式看似安全，但若构造函数含外部依赖（如数据库连接、缓存读取），而这些依赖本身不支持并发复用，就会隐性失败
- 静态变量在 Swoole 的常驻内存中不会重置，但若你在 reload 或热更新时未清理，旧实例可能残留并被错误复用
PHP 环境下真正可用的并发安全单例写法
别用双重检查锁（synchronized 在 PHP 里不存在，pthread 已废弃），也别迷信 volatile（PHP 没这个语义）。可行方案只有两个方向：
-
进程级隔离：接受每个 FPM worker / Swoole worker 独享一个实例，用
static+ 构造保护即可，无需锁 —— 这是 PHP 最自然的并发模型 -
显式同步控制：仅当必须跨进程共享状态（如 Redis 锁管理器），才用
Redis::setnx()或flock()做初始化互斥，但代价高，慎用
示例（推荐的 FPM/Swoole 兼容写法）：
class ConfigManager
{
private static ?self $instance = null;
<pre class="brush:php;toolbar:false;">private function __construct()
{
// 不做耗时或非幂等操作，例如不在此处 connect DB
}
public static function getInstance(): self
{
if (self::$instance === null) {
self::$instance = new self();
}
return self::$instance;
}}
Promise 链中调用单例的典型陷阱
常见错误不是单例本身崩溃，而是你误以为“所有 Promise 共享同一个实例”从而在回调里修改了它的状态，结果下一个 Promise 读到脏数据。比如：
- 在
$promise->then(fn() => ConfigManager::getInstance()->set('env', 'test'))中改配置，后续 Promise 却读到这个临时值 - 单例内部缓存了某次 HTTP 请求结果，但没按 Promise 的上下文隔离，导致 A 用户的数据被 B 用户的 Promise 读到
- 用了
static $cache = []但没考虑 key 是否包含用户 ID、请求 ID 等区分维度
解决办法很简单：单例只负责“创建和持有”，不负责“状态隔离”。状态应由调用方传入，或用 WeakMap（PHP 8.0+）绑定到当前 Promise 实例或请求上下文。
关键点在于：PHP 的“并发安全”从来不是靠锁住 getInstance()，而是靠理解运行模型 —— 你要的不是“全局唯一实例”，而是“每个请求/协程能可靠拿到自己该用的那个实例”。一旦混淆这点，再严谨的单例实现也会在 Promise 场景下翻车。
