swoole\table本身不自动保证原子性，需配合行级锁、swoole\atomic或swoole\lock才能实现安全并发读写；其set()/get()默认无锁，多进程同时写同一行会导致覆盖丢失；type_int字段可用incr()原子操作，字符串等类型必须显式加锁。
Swoole 的共享内存本身不自动保证原子性，必须配合 Swoole\Table 的行级锁、Swoole\Atomic 的 CPU 原子指令，或显式 Swoole\Lock 才能达成真正安全的并发读写。
为什么直接操作 Swoole\Table 不等于线程安全
Swoole\Table 是共享内存结构，但它的 set() 和 get() 方法默认不加锁 —— 这意味着两个 Worker 同时对同一行执行 set()，后写入者会覆盖前写入者的数据，出现“丢失更新”。只有当你主动调用 lock()/unlock()（针对某一行），或使用内置原子字段（如 TYPE_INT 配合 incr()）时，才触发原子保障。
常见错误现象：
– 在线人数统计忽高忽低；
– 用户状态字段被反复覆盖为旧值；
– 多个定时任务同时写入同一配置行，最终只保留最后一次结果。
使用场景判断依据：
– 若只是单字段数值增减（如计数器），优先用 Swoole\Atomic；
– 若需多字段组合更新（如用户 last_login_time + login_count），必须用 Table->lock($key) 包裹整段逻辑；
– 若字段类型为 TYPE_STRING 或 TYPE_FLOAT，incr() 不可用，只能靠锁。
Swoole\Atomic 为什么快，又为什么受限
Swoole\Atomic 底层调用的是 CPU 级原子指令（如 __sync_fetch_and_add），不涉及系统调用、无上下文切换、也不依赖内核锁，所以吞吐远高于 Table->lock()。但它只支持 int64 类型，且所有操作都是“单值”粒度 —— 没有 key、不能存字符串、无法做条件比较后再写入（比如“仅当当前值为 0 时才设为 1”这种 CAS 场景需自行封装）。
参数差异：
– 初始化必须传初始值：new Swoole\Atomic(0)，不能传 null 或字符串；
– get() 返回当前 int 值，set($val) 强制覆盖，add($delta) 和 sub($delta) 是带返回值的原子加减；
– 不提供超时等待、不可重入、不兼容浮点运算。
性能影响：
– 百万级 QPS 下，Atomic::incr() 耗时稳定在纳秒级；
– 若误用于字符串拼接（如试图用 Atomic 存 session_id），运行时报错：Fatal error: Uncaught Error: Call to undefined method Swoole\Atomic::strval()。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
什么时候非得上 Swoole\Lock
当业务逻辑跨多个 Table 行、或混合了外部资源（如文件写入、数据库更新、HTTP 请求回调）时，Swoole\Table 的行锁和 Atomic 的单值原子都失效了，必须引入显式锁。此时 Swoole\Lock 是唯一选择，推荐用 SWOOLE_LOCK_FILE 类型（基于文件 fcntl 锁），它在多进程下稳定、跨重启有效，且不依赖系统共享内存配置。
容易踩的坑：
– 忘记 unlock()：会导致其他进程永久阻塞，表现是服务突然卡死、新请求无法进入；
– 在协程中用 LOCK_RW：该类型不支持协程调度，会引发致命错误 Segmentation fault；
– 锁路径没写绝对路径：new Swoole\Lock(SWOOLE_LOCK_FILE, 'table_lock') 会被解析为相对路径，不同 Worker 可能锁不同文件，形同虚设；
– 把锁对象存在局部变量里：每次回调都 new 一个新锁，等于没锁。
正确姿势：
– 全局单例初始化：$lock = new Swoole\Lock(SWOOLE_LOCK_FILE, '/tmp/global_counter.lock');；
– 在临界区入口立即 $lock->lock()；
– 所有分支（包括 try/catch/return）前确保 $lock->unlock()；
– 不要在 lock 区域内调用可能挂起协程的函数（如 co::sleep()）。
Table 容量预估不准会怎样
Swoole\Table 创建后容量固定，无法扩容。如果 create() 时设了 1024 行，但实际插入 1025 条，第 1025 次 set() 会直接失败并抛出异常：Swoole\Table::ERR_TABLE_FULL。这个错误不会被 PHP 的 try/catch 捕获（它是 C 层错误），而是以 warning 形式输出，接着进程继续运行 —— 表面看服务正常，实则数据已丢失。
规避方法：
– 根据业务最大并发连接数 × 平均每连接需存字段数，再乘以 1.5 倍冗余；
– 启动时用 Table->count() 监控实时占用率，超过 80% 触发告警；
– 不要用 Table 存日志类无限增长数据，改用 Task 进程 + 文件/数据库持久化；
– 若真遇到 ERR_TABLE_FULL，唯一办法是重启 Server 并增大容量，无法热修复。
最易被忽略的一点：Table 的内存占用不是按“行数 × 字段数”粗略估算的，而是按“行数 × 单行最大字节数”计算，其中 TYPE_STRING 字段长度声明（如 64）会全额预留空间，哪怕你只存了 3 个字符 —— 浪费空间比想象中更严重。
