话说回来真正逼我把 Fine 语言的多线程同步拿上台面来收拾是因为一个看起来人畜无害的计数器。当时在某嵌入式网关项目里脚本层起了五个线程各自往一个共享计数器上累加。跑单线程时计数一点问题没有线程一多偶尔就会神秘地少个几百。一开始我还怀疑是外围 C 模块的问题排查到最后才发现锅在解释器自己身上Fine 的 VM 根本没给脚本提供任何同步原语多个线程同时修改同一个槽位时底层的分配器和内存模型保护不了这种操作。也是从那次之后我花了不少时间把 Fine 语言的线程同步体系从零搭了一遍互斥锁、读写锁、条件变量、信号量、原子操作、无锁队列一个接一个地在 VM 层实现又从脚本层验证。这篇文章就把这个过程完整地记录下来包括当时的设计取舍、底层原理、踩过的坑以及最后那个计数器问题的完整排查链路。适合两类读者一类是给自己的脚本语言或嵌入式解释器加并发能力的人另一类是在 Fine 语言里写多线程业务、想知道同步原语为什么长成这样的人。1. 为什么 Fine 把同步放进解释器而不是丢给脚本作者先说实话Fine 语言最初的并发模型非常简陋线程只是对底层 OS 线程的轻量级包装脚本里能 spawn 线程也能 join但线程之间没有任何同步机制。共享数据全靠“大家自觉不加锁”。小项目里凑合能用线程一旦多起来问题就像溃堤一样涌出来。1.1 线程模型先要定清楚脚本线程到底跑在哪动手设计同步原语之前我把 Fine 的线程模型彻底理了一遍。Fine 里的线程本质上是一种“任务”概念调度器会把这些任务分配到线程池上执行。每个脚本线程对应一个独立的调用栈和线程局部状态但字节码执行时共享同一个 VM 实例和堆内存。这件事的后果非常直接一条线程正在执行字节码的同时另一条线程完全可能正在修改同一个哈希表或者同一个对象的字段。如果你只是在外面用 pthread_mutex 随便套一层锁不住解释器内部的共享状态问题依然存在。所以 Fine 在 VM 层引入了一个调度锁scheduler latch。字节码解释循环只持有这个锁很短的时间凡是触及全局状态的操作对象分配、GC 标记、内置表查询都会在锁内部完成。这有点像一个大厨房里几个厨师共用一把菜刀刀只有一把但大家不是从头到尾占着刀而是在切菜的瞬间用一下切完马上放下。调度锁就是那把菜刀。1.2 全局大锁走通之后为什么又要拆成细粒度锁第一版实现简单粗暴整个解释执行阶段都持有调度锁。对全部。这样同步问题的确消失了因为同一时刻只有一个线程在跑脚本其他线程全部排队。当时跑基准测试的场景是四线程并发做纯计算测试区域内只有 2.3 倍加速比理想是 4 倍。瓶颈很明显全局大锁把真正的并行变成了串行线程间切换调度开销还额外吃掉一部分性能。于是第二版把调度锁从“整个解释循环持有”改成“只在真正修改共享堆时持有”。对象分配的 fast path 仍然加锁因为新生代对象区的 bump pointer 是全局共享的但是纯局部变量的运算、基本算术、流程控制这些操作不再上锁。每一个字节码都检查“当前是否触及共享状态”是就加锁不是就裸跑。这一改纯计算场景的加速比从 2.3 倍涨到了 3.6 倍左右代价是解释器代码里到处能看到 lock/unlock 的显式标注。但无论如何这是值得的脚本层的同步原语必须建立在一个“底层已经知道哪些操作危险”的 VM 基础之上。2. 脚本层的锁原语从互斥锁到读写锁的暴露方式线程模型摊清楚之后才开始设计脚本层能用的同步原语。这一步的核心问题是你不能把 pthread_mutex 直接扔给脚本作者那样又危险又难用。Fine 的目标是把底层能力封装成一看就会用的对象。2.1 互斥锁最基础也最容易用错Fine 提供fine.Lock()语义上对齐常见的互斥锁同一时刻只有一个线程能持有。用法上支持显式 acquire/release也支持 with 块。lock fine.Lock() shared_counter 0 def worker(): global shared_counter for i in range(1000): lock.acquire() try: shared_counter 1 finally: lock.release()with 语法在编译阶段会展开成 try/finally保证异常路径上锁也能被释放。如果你只想拿锁尝试一下不等待Fine 额外提供了try_acquire()if lock.try_acquire(): try: do_critical_work() finally: lock.release() else: fallback_work()底层实现用的是 pthread_mutex但有个细节跟原生锁不同请求锁时VM 会先把调度锁释放掉让其他脚本线程仍然可以推进然后才进入 pthread_mutex_lock 等待。如果不做这一步持锁线程在等锁期间会把自己的整个 VM 堵死甚至可能因为锁的持有者也想抢调度锁而直接死锁。经验脚本语言的锁封装永远不要用一个简单的 pthread_mutex_lock 包一层就交出去。一定要考虑“当前线程在等待期间解释器整体还能不能继续执行其他任务”这一层。2.2 读写锁读者多写者少才有意义很多并发场景是读多写少。比如配置表、索引缓存、热词统计这些数据脚本里大部分线程都在查询只有少数几个线程在更新。如果全部用互斥锁串起来读线程之间互相阻塞白白浪费并发能力。Fine 的fine.RWLock()就是对 pthread_rwlock 的封装config_lock fine.RWLock() config {retry_count: 3, timeout_ms: 500} def get_config(key): config_lock.acquire_read() try: return config.get(key) finally: config_lock.release_read() def update_config(patch): config_lock.acquire_write() try: config.update(patch) finally: config_lock.release_write()这个 API 本身不难难的是让人记住两点第一读锁和写锁必须严格配对如果写完用 release_read 释放或者反过来底层会直接乱掉而且很难排查第二不要把读锁当普通互斥锁用——在写者等待时还反复抢读锁可能会把写者活活饿死这是 pthread_rwlock 的写优先策略在默认配置下的表现。我后来在文档里单独加了一段警告能用 Lock 就别用 RWLock。RWLock 是为那些已经验证确实读多写少的场景准备的不是为了显得高级。2.3 原子操作能不能完全替代锁有一部分并发场景根本不需要临界区只需要一个计数器或者一个标志位。对这种需求Fine 提供了fine.AtomicIntvisits fine.AtomicInt(0) def record_visit(): visits.fetch_add(1) # 读取当前值 print(visits.load())底层直接映射到 C11 的 atomic_fetch_add没有锁全靠 CPU 的原子指令。这也是当初修正计数器问题时的最终方案之一如果只是累加一个整数用锁去保护一个i 1确实浪费。但要清楚原子操作的边界它能保证“这个整数本身不会被撕开”不能保证“你先读取判断再操作”这个复合流程是原子的。比如if visits.load() 100: visits.fetch_add(1)这段代码在并发下完全可能让 visit 超过 100因为 load 和 fetch_add 是两次独立操作。遇到这种 check-then-act 的需求该用锁就用锁原子操作救不了你。3. 条件变量与信号量被线程唤醒的工程细节锁解决的是“互斥”但并发里另一类常见需求是“等待”。比如一个消费者线程等着队列里有数据一个计算任务等着所有 worker 到达某个汇合点。这类需求靠锁没法直接表达需要条件变量、信号量和屏障。3.1 条件变量为什么必须配一把锁Fine 的fine.Condition设计上要求跟一个锁绑定使用lock fine.Lock() queue [] cond fine.Condition(lock) def producer(item): lock.acquire() try: queue.append(item) cond.notify_one() finally: lock.release() def consumer(): lock.acquire() try: while len(queue) 0: cond.wait() item queue.pop(0) return item finally: lock.release()wait 时为什么必须要持有锁因为条件变量的核心语义是“原子化地释放锁并睡眠”。设想一下如果 wait 之前不释放锁消费者睡眠时把锁攥在手里生产者就永远无法拿到锁往队列里放数据死锁。所以 Fine 的底层实现里cond.wait() 做了三件事先把当前持有的脚本层锁释放再把线程挂起到等待队列等被唤醒后重新拿回锁。这里有一个所有教科书都会强调的细节while len(queue) 0这个循环不能写成if。因为可能发生虚假唤醒spurious wakeup也可能出现多个消费者同时被唤醒但只有一个能拿到数据的情况。循环重新检查条件是最稳的写法。3.2 信号量计数型事件不是锁的替代品信号量在 Fine 里的语义很简单就是一个非负计数器。粗略地说acquire 会让计数器减一如果当前是 0 就等待release 会让计数器加一并唤醒一个等待者。slots fine.Semaphore(3) def upload(): slots.acquire() try: do_upload() finally: slots.release()这个设计适合限制并发数量比如最多允许 3 个上传任务同时跑。但我在实际使用中见过不少人把信号量当互斥锁用init 成 1然后 acquire/release 包住临界区。语法上确实能工作语义上却有很大隐患——信号量没有持有者概念一个线程释放了另一个线程 acquire 的信号量完全合法这会让“谁锁的谁释放”这个心智模型彻底失效。Fine 的文档里明确写了限制并发用信号量保护临界区用互斥锁不要把两者混用。3.3 屏障多线程汇合点还有一个容易被忽略的同步原语屏障barrier。场景是N 个线程分别计算一部分数据计算完之后必须在同一时刻点汇合才能进入下一阶段。Fine 提供了fine.Barrier(n)phase_barrier fine.Barrier(4) shared_result [] def phase_one(index): partial heavy_compute(index) shared_result.append(partial) phase_barrier.wait() # 所有线程都在这里等全部到达后才继续 merge_and_analyze(shared_result, index)Barrier 的实现可以基于 mutex condition也可以基于原子计数器 futex。Fine 选的是后者因为等待者通常较多futex 在无竞争时开销更小。不过对脚本层来说这些都不需要关心只需要知道barrier 是一次性的如果你想做多轮阶段同步需要创建多个 barrier 实例或者反复调用 reset。4. 那些年踩过的坑计数器丢失与死锁的完整排查链路前面讲的是设计思路真正让 Fine 的同步体系稳定下来是靠一个个真实问题砸出来的。这段我只讲两个印象最深的案例完整还原当时的排查过程。4.1 消失的 200 次计数第一案发现场回到文章开头那个计数器问题。现象是5 个线程分别累加一个计数器 1 万次理论上应该是 5 万实际有时候 49700有时候 49300偶尔 49800规律完全随机。我当时的第一反应是“脚本作者的逻辑有问题”可能有人做了缓存可能有人把共享变量无意中复制了。但逐行查脚本发现就是最简单的shared_counter 1。然后我进入第二层猜测难道是 VM 的解释循环对shared_counter 1编译出的字节码不是原子的复盘了一下编译结果加一操作至少包含三条字节码加载槽位、加载常量、原子加并存储。单线程连续执行没问题两个线程交错执行时“加载槽位”和“存储结果”之间就可能被另一个线程的写入覆盖。为了验证这个判断我在关键指令附近塞了一些临时的调试日志强制把线程上下文切换点暴露出来。跑了几百次之后抓到了如下交错线程 A 读取 shared_counter 为 100 线程 B 读取 shared_counter 为 100 线程 B 写入 101 线程 A 写入 101。两次累加一共只加了 1丢了一次计数。至此根因坐实VC 的共享变量更新没有原子保护也没有同步原语可用。修复分两步先把 VM 的变量插槽写入指令用调度锁保护起来从底层杜绝“交错更新变量槽位”导致丢失的可能然后补上脚本层的 Lock、AtomicInt 等原语让上层能写出确定性的并发代码。修完底层之后再用锁跑同一台设备的五线程计数连续跑 5 万轮计数从没再丢过。4.2 锁顺序颠倒引发的连环死锁有了 Lock 之后新的问题又浮上来了分布式同个线程持有多把锁时锁的获取顺序不一致会造成死锁。当时有一个模块同时操作两个共享对象一个是登录会话表一个是设备状态表。线程 A 先拿会话锁再拿状态锁线程 B 却先拿状态锁再拿会话锁。一旦两个线程各自持有一把锁、又在等另一把锁——经典“哲学家吃饭”问题整个 VM 直接卡死而且不打印任何错误看起来就像机器休眠了。排查这种死锁我用的办法是给所有锁加一个 owner 记录和获取顺序日志。Fine 内部在调试模式下会把每条线程持锁顺序记录到一个环形缓冲里。死锁发生时直接把缓存导出线程 1 持有会话锁等待状态锁 线程 2 持有状态锁等待会话锁。一眼就看明白。修复方式是调整代码让所有线程都以“会话锁 → 状态锁”的全局顺序获取锁。后来我把这个规则固化成了代码评审的必查项任何持有多把锁的地方获取顺序必须在整个项目里保持一致。除了顺序问题还有一个隐蔽的死锁源头脚本线程在持有脚本层锁的时候回调进入 C 扩展模块而 C 模块里又去抢一个内部的 C 锁。如果另一条线程先拿到了 C 锁又在等待调度锁两边就会咬死。对这类问题我没有更好的魔法只能定一条纪律脚本层的锁和原生层的锁要尽量避免嵌套实在不能避免就把锁的层级顺序写到文档里谁都别去打破。4.3 条件变量唤醒丢失notify 与 wait 的时序陷阱另一个让我折腾了半天的坑来自条件变量。Python 用户很熟悉with cond:的写法Fine 也支持类似用法。有一个版本里使用者写出了这样的逻辑lock fine.Lock() cond fine.Condition(lock) ready False def notify(): global ready lock.acquire() try: ready True cond.notify_all() finally: lock.release()看起来很对对吧问题出在另一处等待方向写完条件后先做了一次notify()然后才开始wait()。结果 notify 发生时等待者还没睡下唤醒信号直接丢失等待者继续傻等。没有别的线程再来 notify整个线程组挂死。这类问题的标准解法是条件变量必须配合外部状态使用等待方必须反复检查状态再决定是否 wait。Fine 官方示例里已经全部改成类似这样def waiter(): lock.acquire() try: while not ready: cond.wait() finally: lock.release()这样即使 notify 先发生也只会把 ready 置为 true等待方进入循环检查时看到 ready 已经是 true就不 wait 了。唤醒丢失这个坑根本上是没有理解“条件变量不保存事件只负责在条件改变时唤醒等待者”这一条。5. 性能调优带来的设计转变降低锁粒度的实操路线同步做对了还不够性能才是压垮骆驼的最后一根稻草。Fine 在这轮改造里经历了“加锁先把功能跑通 → 性能不够 → 想尽办法降低锁竞争”的完整链条。5.1 先粗后细从整表锁到槽位锁最初用锁保护共享哈希表时我偷懒直接给整张表挂了一把互斥锁。逻辑完全正确但多个线程同时读这张表也会互相阻塞导致并发查询效率极低。尤其是几个高频查询函数锁等待占比一度超过 40%。后来把表结构改成分段锁把哈希桶分成 16 个段每个段各自一把锁。查询和修改只对命中的那一段加锁其他段的读写完全并行。实测高频读写下整体吞吐提升了两倍多。这段优化的心得是不要一开始就过度设计。先把功能用最朴素的锁跑通然后通过 profiling 找出真正被锁拖慢的路径再考虑分段、分槽这些优化手段。绝大多数人不会一上来就需要无锁结构。5.2 无锁队列什么时候值得上某些场景锁竞争再怎么优化都不够比如高吞吐日志转发。多个生产者线程往队列里写日志一个消费者线程批量取出上传。即使只用很短的分段锁几次实测数据也显示队列锁占了很大的 CPU 时间片于是引入了无锁队列。Fine 里实现的是 MPSC多生产者单消费者队列底层用原子 CAS 控制头尾指针void* mpsc_push(MPSCQueue* q, void* item) { Node* n (Node*)malloc(sizeof(Node)); n-data item; n-next NULL; Node** tail q-tail; Node* prev __atomic_exchange_n(tail, n, __ATOMIC_RELEASE); // 让消费者看到的是 release/acquire 语义 __atomic_store_n(prev-next, n, __ATOMIC_RELEASE); return n; }这段代码的关键在于我用了一个 atomic exchange 来原子地把新节点接到尾部。所有生产者的 push 操作都不会相斥等待消费者则不断读取头节点的 next 指针来消费数据。无锁队列比看起来要难调试得多一个内存序用错就是诡异的内存竞争。给 Fine 做这版队列的时候我额外写了一个多线程压测脚本跑了整整一个晚上才敢让它进主线。如果不是真实场景吃不下锁的吞吐不建议轻易上无锁方案。5.3 性能数据同步改造前后对比为了给后续功能开发一个参照我用同一台四核设备跑了一个标准并发任务32 个线程并发向共享表写入 20 万条记录并读取。结果大致如下方案耗时相对单线程加速比备注无任何同步错误3.2s约 2.1 倍数据严重丢失全局大锁9.8s约 0.68 倍功能正确但性能退化分段锁4.6s约 1.45 倍功能正确性能可接受分段锁 无锁队列3.4s约 1.97 倍吞吐最接近单线程 2 倍无任何同步的方案之所以“快”是因为它根本没做保护数据丢得一塌糊涂。全局大锁是最可靠但最慢的。分段锁跑通后已经在多数业务场景里够用了。无锁队列只是针对单一热点路径的针对性优化。这个表也说明了一个道理并发优化的目标从来不是无限追求加速比而是在正确性和可维护性之间找到那个平衡点。Fine 最后落地时默认推荐的就是分段锁方案无锁队列只留给了真正需要极高吞吐的扩展模块去用。6. 写在最后的实践建议整个 Fine 多线程同步的改造做下来我个人的体会是给脚本语言加同步原语本质上是在解决三层问题——底层的线程安全和内存模型中层的锁/条件变量/信号量原语设计上层的编程范式引导。每一层都有各自的陷阱跳层思考往往会栽跟头。如果想在自己的项目里复刻这条路我的建议是先给 VM 打上调度锁跑通全链路再逐步细分锁粒度每引入一种新同步原语都要配套一个简单而残酷的并发压测用例每次死锁或竞态出现务必还原现场、记录持锁顺序而不是盲目重启重试。最后分享一个小实操Fine 的调试模块里后来加了一个“锁断言”功能任何线程释放一把不是自己持有的锁直接抛出异常退出而不是静默失败。就是这个不起眼的小功能帮我后续排查同步问题时省下了一半时间。并发同步这种东西越是在早期把错误暴露得难堪后期就越少在线上出洋相。 
长河君 · 2026/10/14 23:40:42 · 阅读 1.2k Fine语言多线程同步原语设计：从互斥锁到无锁队列
话说回来真正逼我把 Fine 语言的多线程同步拿上台面来收拾是因为一个看起来人畜无害的计数器。当时在某嵌入式网关项目里脚本层起了五个线程各自往一个共享计数器上累加。跑单线程时计数一点问题没有线程一多偶尔就会神秘地少个几百。一开始我还怀疑是外围 C 模块的问题排查到最后才发现锅在解释器自己身上Fine 的 VM 根本没给脚本提供任何同步原语多个线程同时修改同一个槽位时底层的分配器和内存模型保护不了这种操作。也是从那次之后我花了不少时间把 Fine 语言的线程同步体系从零搭了一遍互斥锁、读写锁、条件变量、信号量、原子操作、无锁队列一个接一个地在 VM 层实现又从脚本层验证。这篇文章就把这个过程完整地记录下来包括当时的设计取舍、底层原理、踩过的坑以及最后那个计数器问题的完整排查链路。适合两类读者一类是给自己的脚本语言或嵌入式解释器加并发能力的人另一类是在 Fine 语言里写多线程业务、想知道同步原语为什么长成这样的人。1. 为什么 Fine 把同步放进解释器而不是丢给脚本作者先说实话Fine 语言最初的并发模型非常简陋线程只是对底层 OS 线程的轻量级包装脚本里能 spawn 线程也能 join但线程之间没有任何同步机制。共享数据全靠“大家自觉不加锁”。小项目里凑合能用线程一旦多起来问题就像溃堤一样涌出来。1.1 线程模型先要定清楚脚本线程到底跑在哪动手设计同步原语之前我把 Fine 的线程模型彻底理了一遍。Fine 里的线程本质上是一种“任务”概念调度器会把这些任务分配到线程池上执行。每个脚本线程对应一个独立的调用栈和线程局部状态但字节码执行时共享同一个 VM 实例和堆内存。这件事的后果非常直接一条线程正在执行字节码的同时另一条线程完全可能正在修改同一个哈希表或者同一个对象的字段。如果你只是在外面用 pthread_mutex 随便套一层锁不住解释器内部的共享状态问题依然存在。所以 Fine 在 VM 层引入了一个调度锁scheduler latch。字节码解释循环只持有这个锁很短的时间凡是触及全局状态的操作对象分配、GC 标记、内置表查询都会在锁内部完成。这有点像一个大厨房里几个厨师共用一把菜刀刀只有一把但大家不是从头到尾占着刀而是在切菜的瞬间用一下切完马上放下。调度锁就是那把菜刀。1.2 全局大锁走通之后为什么又要拆成细粒度锁第一版实现简单粗暴整个解释执行阶段都持有调度锁。对全部。这样同步问题的确消失了因为同一时刻只有一个线程在跑脚本其他线程全部排队。当时跑基准测试的场景是四线程并发做纯计算测试区域内只有 2.3 倍加速比理想是 4 倍。瓶颈很明显全局大锁把真正的并行变成了串行线程间切换调度开销还额外吃掉一部分性能。于是第二版把调度锁从“整个解释循环持有”改成“只在真正修改共享堆时持有”。对象分配的 fast path 仍然加锁因为新生代对象区的 bump pointer 是全局共享的但是纯局部变量的运算、基本算术、流程控制这些操作不再上锁。每一个字节码都检查“当前是否触及共享状态”是就加锁不是就裸跑。这一改纯计算场景的加速比从 2.3 倍涨到了 3.6 倍左右代价是解释器代码里到处能看到 lock/unlock 的显式标注。但无论如何这是值得的脚本层的同步原语必须建立在一个“底层已经知道哪些操作危险”的 VM 基础之上。2. 脚本层的锁原语从互斥锁到读写锁的暴露方式线程模型摊清楚之后才开始设计脚本层能用的同步原语。这一步的核心问题是你不能把 pthread_mutex 直接扔给脚本作者那样又危险又难用。Fine 的目标是把底层能力封装成一看就会用的对象。2.1 互斥锁最基础也最容易用错Fine 提供fine.Lock()语义上对齐常见的互斥锁同一时刻只有一个线程能持有。用法上支持显式 acquire/release也支持 with 块。lock fine.Lock() shared_counter 0 def worker(): global shared_counter for i in range(1000): lock.acquire() try: shared_counter 1 finally: lock.release()with 语法在编译阶段会展开成 try/finally保证异常路径上锁也能被释放。如果你只想拿锁尝试一下不等待Fine 额外提供了try_acquire()if lock.try_acquire(): try: do_critical_work() finally: lock.release() else: fallback_work()底层实现用的是 pthread_mutex但有个细节跟原生锁不同请求锁时VM 会先把调度锁释放掉让其他脚本线程仍然可以推进然后才进入 pthread_mutex_lock 等待。如果不做这一步持锁线程在等锁期间会把自己的整个 VM 堵死甚至可能因为锁的持有者也想抢调度锁而直接死锁。经验脚本语言的锁封装永远不要用一个简单的 pthread_mutex_lock 包一层就交出去。一定要考虑“当前线程在等待期间解释器整体还能不能继续执行其他任务”这一层。2.2 读写锁读者多写者少才有意义很多并发场景是读多写少。比如配置表、索引缓存、热词统计这些数据脚本里大部分线程都在查询只有少数几个线程在更新。如果全部用互斥锁串起来读线程之间互相阻塞白白浪费并发能力。Fine 的fine.RWLock()就是对 pthread_rwlock 的封装config_lock fine.RWLock() config {retry_count: 3, timeout_ms: 500} def get_config(key): config_lock.acquire_read() try: return config.get(key) finally: config_lock.release_read() def update_config(patch): config_lock.acquire_write() try: config.update(patch) finally: config_lock.release_write()这个 API 本身不难难的是让人记住两点第一读锁和写锁必须严格配对如果写完用 release_read 释放或者反过来底层会直接乱掉而且很难排查第二不要把读锁当普通互斥锁用——在写者等待时还反复抢读锁可能会把写者活活饿死这是 pthread_rwlock 的写优先策略在默认配置下的表现。我后来在文档里单独加了一段警告能用 Lock 就别用 RWLock。RWLock 是为那些已经验证确实读多写少的场景准备的不是为了显得高级。2.3 原子操作能不能完全替代锁有一部分并发场景根本不需要临界区只需要一个计数器或者一个标志位。对这种需求Fine 提供了fine.AtomicIntvisits fine.AtomicInt(0) def record_visit(): visits.fetch_add(1) # 读取当前值 print(visits.load())底层直接映射到 C11 的 atomic_fetch_add没有锁全靠 CPU 的原子指令。这也是当初修正计数器问题时的最终方案之一如果只是累加一个整数用锁去保护一个i 1确实浪费。但要清楚原子操作的边界它能保证“这个整数本身不会被撕开”不能保证“你先读取判断再操作”这个复合流程是原子的。比如if visits.load() 100: visits.fetch_add(1)这段代码在并发下完全可能让 visit 超过 100因为 load 和 fetch_add 是两次独立操作。遇到这种 check-then-act 的需求该用锁就用锁原子操作救不了你。3. 条件变量与信号量被线程唤醒的工程细节锁解决的是“互斥”但并发里另一类常见需求是“等待”。比如一个消费者线程等着队列里有数据一个计算任务等着所有 worker 到达某个汇合点。这类需求靠锁没法直接表达需要条件变量、信号量和屏障。3.1 条件变量为什么必须配一把锁Fine 的fine.Condition设计上要求跟一个锁绑定使用lock fine.Lock() queue [] cond fine.Condition(lock) def producer(item): lock.acquire() try: queue.append(item) cond.notify_one() finally: lock.release() def consumer(): lock.acquire() try: while len(queue) 0: cond.wait() item queue.pop(0) return item finally: lock.release()wait 时为什么必须要持有锁因为条件变量的核心语义是“原子化地释放锁并睡眠”。设想一下如果 wait 之前不释放锁消费者睡眠时把锁攥在手里生产者就永远无法拿到锁往队列里放数据死锁。所以 Fine 的底层实现里cond.wait() 做了三件事先把当前持有的脚本层锁释放再把线程挂起到等待队列等被唤醒后重新拿回锁。这里有一个所有教科书都会强调的细节while len(queue) 0这个循环不能写成if。因为可能发生虚假唤醒spurious wakeup也可能出现多个消费者同时被唤醒但只有一个能拿到数据的情况。循环重新检查条件是最稳的写法。3.2 信号量计数型事件不是锁的替代品信号量在 Fine 里的语义很简单就是一个非负计数器。粗略地说acquire 会让计数器减一如果当前是 0 就等待release 会让计数器加一并唤醒一个等待者。slots fine.Semaphore(3) def upload(): slots.acquire() try: do_upload() finally: slots.release()这个设计适合限制并发数量比如最多允许 3 个上传任务同时跑。但我在实际使用中见过不少人把信号量当互斥锁用init 成 1然后 acquire/release 包住临界区。语法上确实能工作语义上却有很大隐患——信号量没有持有者概念一个线程释放了另一个线程 acquire 的信号量完全合法这会让“谁锁的谁释放”这个心智模型彻底失效。Fine 的文档里明确写了限制并发用信号量保护临界区用互斥锁不要把两者混用。3.3 屏障多线程汇合点还有一个容易被忽略的同步原语屏障barrier。场景是N 个线程分别计算一部分数据计算完之后必须在同一时刻点汇合才能进入下一阶段。Fine 提供了fine.Barrier(n)phase_barrier fine.Barrier(4) shared_result [] def phase_one(index): partial heavy_compute(index) shared_result.append(partial) phase_barrier.wait() # 所有线程都在这里等全部到达后才继续 merge_and_analyze(shared_result, index)Barrier 的实现可以基于 mutex condition也可以基于原子计数器 futex。Fine 选的是后者因为等待者通常较多futex 在无竞争时开销更小。不过对脚本层来说这些都不需要关心只需要知道barrier 是一次性的如果你想做多轮阶段同步需要创建多个 barrier 实例或者反复调用 reset。4. 那些年踩过的坑计数器丢失与死锁的完整排查链路前面讲的是设计思路真正让 Fine 的同步体系稳定下来是靠一个个真实问题砸出来的。这段我只讲两个印象最深的案例完整还原当时的排查过程。4.1 消失的 200 次计数第一案发现场回到文章开头那个计数器问题。现象是5 个线程分别累加一个计数器 1 万次理论上应该是 5 万实际有时候 49700有时候 49300偶尔 49800规律完全随机。我当时的第一反应是“脚本作者的逻辑有问题”可能有人做了缓存可能有人把共享变量无意中复制了。但逐行查脚本发现就是最简单的shared_counter 1。然后我进入第二层猜测难道是 VM 的解释循环对shared_counter 1编译出的字节码不是原子的复盘了一下编译结果加一操作至少包含三条字节码加载槽位、加载常量、原子加并存储。单线程连续执行没问题两个线程交错执行时“加载槽位”和“存储结果”之间就可能被另一个线程的写入覆盖。为了验证这个判断我在关键指令附近塞了一些临时的调试日志强制把线程上下文切换点暴露出来。跑了几百次之后抓到了如下交错线程 A 读取 shared_counter 为 100 线程 B 读取 shared_counter 为 100 线程 B 写入 101 线程 A 写入 101。两次累加一共只加了 1丢了一次计数。至此根因坐实VC 的共享变量更新没有原子保护也没有同步原语可用。修复分两步先把 VM 的变量插槽写入指令用调度锁保护起来从底层杜绝“交错更新变量槽位”导致丢失的可能然后补上脚本层的 Lock、AtomicInt 等原语让上层能写出确定性的并发代码。修完底层之后再用锁跑同一台设备的五线程计数连续跑 5 万轮计数从没再丢过。4.2 锁顺序颠倒引发的连环死锁有了 Lock 之后新的问题又浮上来了分布式同个线程持有多把锁时锁的获取顺序不一致会造成死锁。当时有一个模块同时操作两个共享对象一个是登录会话表一个是设备状态表。线程 A 先拿会话锁再拿状态锁线程 B 却先拿状态锁再拿会话锁。一旦两个线程各自持有一把锁、又在等另一把锁——经典“哲学家吃饭”问题整个 VM 直接卡死而且不打印任何错误看起来就像机器休眠了。排查这种死锁我用的办法是给所有锁加一个 owner 记录和获取顺序日志。Fine 内部在调试模式下会把每条线程持锁顺序记录到一个环形缓冲里。死锁发生时直接把缓存导出线程 1 持有会话锁等待状态锁 线程 2 持有状态锁等待会话锁。一眼就看明白。修复方式是调整代码让所有线程都以“会话锁 → 状态锁”的全局顺序获取锁。后来我把这个规则固化成了代码评审的必查项任何持有多把锁的地方获取顺序必须在整个项目里保持一致。除了顺序问题还有一个隐蔽的死锁源头脚本线程在持有脚本层锁的时候回调进入 C 扩展模块而 C 模块里又去抢一个内部的 C 锁。如果另一条线程先拿到了 C 锁又在等待调度锁两边就会咬死。对这类问题我没有更好的魔法只能定一条纪律脚本层的锁和原生层的锁要尽量避免嵌套实在不能避免就把锁的层级顺序写到文档里谁都别去打破。4.3 条件变量唤醒丢失notify 与 wait 的时序陷阱另一个让我折腾了半天的坑来自条件变量。Python 用户很熟悉with cond:的写法Fine 也支持类似用法。有一个版本里使用者写出了这样的逻辑lock fine.Lock() cond fine.Condition(lock) ready False def notify(): global ready lock.acquire() try: ready True cond.notify_all() finally: lock.release()看起来很对对吧问题出在另一处等待方向写完条件后先做了一次notify()然后才开始wait()。结果 notify 发生时等待者还没睡下唤醒信号直接丢失等待者继续傻等。没有别的线程再来 notify整个线程组挂死。这类问题的标准解法是条件变量必须配合外部状态使用等待方必须反复检查状态再决定是否 wait。Fine 官方示例里已经全部改成类似这样def waiter(): lock.acquire() try: while not ready: cond.wait() finally: lock.release()这样即使 notify 先发生也只会把 ready 置为 true等待方进入循环检查时看到 ready 已经是 true就不 wait 了。唤醒丢失这个坑根本上是没有理解“条件变量不保存事件只负责在条件改变时唤醒等待者”这一条。5. 性能调优带来的设计转变降低锁粒度的实操路线同步做对了还不够性能才是压垮骆驼的最后一根稻草。Fine 在这轮改造里经历了“加锁先把功能跑通 → 性能不够 → 想尽办法降低锁竞争”的完整链条。5.1 先粗后细从整表锁到槽位锁最初用锁保护共享哈希表时我偷懒直接给整张表挂了一把互斥锁。逻辑完全正确但多个线程同时读这张表也会互相阻塞导致并发查询效率极低。尤其是几个高频查询函数锁等待占比一度超过 40%。后来把表结构改成分段锁把哈希桶分成 16 个段每个段各自一把锁。查询和修改只对命中的那一段加锁其他段的读写完全并行。实测高频读写下整体吞吐提升了两倍多。这段优化的心得是不要一开始就过度设计。先把功能用最朴素的锁跑通然后通过 profiling 找出真正被锁拖慢的路径再考虑分段、分槽这些优化手段。绝大多数人不会一上来就需要无锁结构。5.2 无锁队列什么时候值得上某些场景锁竞争再怎么优化都不够比如高吞吐日志转发。多个生产者线程往队列里写日志一个消费者线程批量取出上传。即使只用很短的分段锁几次实测数据也显示队列锁占了很大的 CPU 时间片于是引入了无锁队列。Fine 里实现的是 MPSC多生产者单消费者队列底层用原子 CAS 控制头尾指针void* mpsc_push(MPSCQueue* q, void* item) { Node* n (Node*)malloc(sizeof(Node)); n-data item; n-next NULL; Node** tail q-tail; Node* prev __atomic_exchange_n(tail, n, __ATOMIC_RELEASE); // 让消费者看到的是 release/acquire 语义 __atomic_store_n(prev-next, n, __ATOMIC_RELEASE); return n; }这段代码的关键在于我用了一个 atomic exchange 来原子地把新节点接到尾部。所有生产者的 push 操作都不会相斥等待消费者则不断读取头节点的 next 指针来消费数据。无锁队列比看起来要难调试得多一个内存序用错就是诡异的内存竞争。给 Fine 做这版队列的时候我额外写了一个多线程压测脚本跑了整整一个晚上才敢让它进主线。如果不是真实场景吃不下锁的吞吐不建议轻易上无锁方案。5.3 性能数据同步改造前后对比为了给后续功能开发一个参照我用同一台四核设备跑了一个标准并发任务32 个线程并发向共享表写入 20 万条记录并读取。结果大致如下方案耗时相对单线程加速比备注无任何同步错误3.2s约 2.1 倍数据严重丢失全局大锁9.8s约 0.68 倍功能正确但性能退化分段锁4.6s约 1.45 倍功能正确性能可接受分段锁 无锁队列3.4s约 1.97 倍吞吐最接近单线程 2 倍无任何同步的方案之所以“快”是因为它根本没做保护数据丢得一塌糊涂。全局大锁是最可靠但最慢的。分段锁跑通后已经在多数业务场景里够用了。无锁队列只是针对单一热点路径的针对性优化。这个表也说明了一个道理并发优化的目标从来不是无限追求加速比而是在正确性和可维护性之间找到那个平衡点。Fine 最后落地时默认推荐的就是分段锁方案无锁队列只留给了真正需要极高吞吐的扩展模块去用。6. 写在最后的实践建议整个 Fine 多线程同步的改造做下来我个人的体会是给脚本语言加同步原语本质上是在解决三层问题——底层的线程安全和内存模型中层的锁/条件变量/信号量原语设计上层的编程范式引导。每一层都有各自的陷阱跳层思考往往会栽跟头。如果想在自己的项目里复刻这条路我的建议是先给 VM 打上调度锁跑通全链路再逐步细分锁粒度每引入一种新同步原语都要配套一个简单而残酷的并发压测用例每次死锁或竞态出现务必还原现场、记录持锁顺序而不是盲目重启重试。最后分享一个小实操Fine 的调试模块里后来加了一个“锁断言”功能任何线程释放一把不是自己持有的锁直接抛出异常退出而不是静默失败。就是这个不起眼的小功能帮我后续排查同步问题时省下了一半时间。并发同步这种东西越是在早期把错误暴露得难堪后期就越少在线上出洋相。