symfony 中 new semaphore() 不可用，因其依赖系统信号量扩展（如 sysvsem/posix），而多数生产环境未启用；且 semaphore 仅限单进程，不支持分布式场景，应改用 symfony lock 组件配合 redis 等后端实现跨进程锁。
为什么直接 new Semaphore() 在 Symfony 里不管用
Symfony 的 Semaphore 组件不是开箱即用的并发控制开关，它底层依赖系统级信号量（如 POSIX semaphores 或 Windows semaphore API），而大多数 PHP 运行环境（尤其是容器化部署、共享主机、甚至某些 Docker 镜像）默认禁用或未安装 sysvsem / posix 扩展。你写 new Semaphore('stock:1001') 后调用 acquire()，很可能直接抛出 RuntimeException: Unable to create semaphore，根本走不到业务逻辑。
更隐蔽的问题是：即使创建成功，Semaphore 只保证「同一进程内多次 acquire 不会重复计数」，但它**不跨进程、不跨机器、不跨容器**——在 Symfony 集群部署下，每个 PHP-FPM worker 进程都有自己的信号量实例，完全无法协同。这不是 bug，是设计使然。
- 确认扩展是否启用：
php -m | grep -E "(sysvsem|posix)" - 本地开发可用，但生产环境几乎不可靠，尤其用 Apache + mod_php 或 Nginx + PHP-FPM 多 worker 场景
- 它和
synchronized一样，只解决单机单进程锁，对电商秒杀毫无意义
真正起作用的是 Symfony Lock 组件，不是 Semaphore
Symfony 官方明确推荐用 Lock 组件替代手写信号量逻辑，因为它抽象了分布式锁能力，支持 Redis、PostgreSQL、MySQL 等多种存储后端，天然适配集群部署。库存扣减时你要的不是“最多 100 个线程同时执行”，而是“同一商品 ID 的扣减操作必须串行化”，这正是分布式锁的职责。
正确做法是用 LockFactory 创建基于 Redis 的锁：
use Symfony\Component\Lock\LockFactory;
use Symfony\Component\Lock\Store\RedisStore;
<p>$redis = new \Redis();
$redis->connect('127.0.0.1', 6379);
$store = new RedisStore($redis);
$factory = new LockFactory($store);</p><p>$lock = $factory->createLock('stock:sku_12345');</p>
然后在扣减前加锁、扣减后释放：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
$lock->acquire(true)—— 阻塞等待获取锁，返回true表示成功 - 获取锁后立刻查 Redis 库存（
GET stock:sku_12345），再DECRBY扣减 - 无论成功失败，都必须
$lock->release()，建议用try/finally包裹 - 锁自动带过期时间（默认 30 秒），避免死锁
用 Lock 做库存预占，比单纯扣减更安全
纯扣减（DECRBY）在用户下单未支付时会造成库存永久丢失。真实场景需要「预占 + 确认 + 释放」三阶段，而 Lock 正好能配合这个流程：预占时用锁保护库存状态变更，而不是保护整个扣减函数。
例如预占逻辑：
- 生成唯一订单号
order_abc123 - 用
$factory->createLock('reserve:sku_12345')获取商品级锁 - 读取当前可售库存
GET stock:sku_12345和已预占数HGETALL reserve:sku_12345 - 计算剩余可预占量：
total - reserved_total，足够则写入哈希HSET reserve:sku_12345 order_abc123 10（预占 10 件）并设置过期时间 - 释放锁，返回预占结果
这个过程里，Lock 保证了「读-判-写」的原子性，避免多个请求同时读到相同库存值后各自预占，导致超卖。
别忽略 Redis 连接和锁超时的耦合风险
很多人把锁超时设成 10 秒，但实际扣减逻辑（查库存、写预占、发消息、记录日志）可能因网络抖动或 DB 慢查询耗时 15 秒——锁提前释放，另一个请求进来，两个请求同时操作同一份库存，超卖就发生了。
解决方案不是盲目拉长锁超时，而是：
- 把锁超时设为「业务最长可能耗时 × 1.5」，比如预占逻辑 SLA 是 3 秒，锁设为 5 秒
- 在锁对象上绑定心跳续期（
$lock->refresh()），适用于长流程 - 绝不依赖锁超时兜底；所有业务分支（包括异常、重试、回调）都要显式调用
release() - Redis 连接池要独立配置，不能和主应用共用连接，避免锁操作被慢查询阻塞
最易被忽略的一点：LockFactory 默认使用 RedisStore 的 EVAL 脚本实现原子加锁，但如果 Redis 开启了 ACL 权限控制，而账号没授予 script 权限，acquire() 会静默失败——日志里只有一行 Failed to acquire lock，没有堆栈，排查起来极其费时。
