V3.03.1Locking serializes collaboration设计研究
锁定避免冲突但阻断并行
别名: 悲观锁的并行代价 · 串行化协作 · 锁排队
概念解释
用锁定处理并发，得到的是确定没有冲突，付出的是并行本身：一个区域被锁住期间，其他人对它的任何操作都只能等待或绕开。这不仅是技术上的排队，更是协作行为的改写——人们会因为「那块被锁了」而推迟想法、另起副本、或者干脆不参与。锁定把「大家一起做」变成「轮流做」，冲突消失的代价是协作的密度下降。判定一个锁方案是否可接受，不是看它消灭了多少冲突，而是看它引入的串行化是否比被消灭的冲突更便宜。
机制
锁的排他性是二值的：拿到就是全部，拿不到就是零。这与人协作的真实节奏错位——两个人对同一区域的修改很少真的处处相撞，多数意图可以并存，但锁无法表达「大部分并行、小部分互斥」，只能把整个区域一次性划归一人。行为后果沿三条路径展开：等待，后来者被挡在锁外，注意力和思路被打断，等待越久越倾向于离开；绕行，被锁挡住的人另建副本修改，事后合并，反而制造出锁本来要防止的分叉；退出，反复被挡的人降低对共享空间的投入，退回单干。三条路径都让实际并行度低于系统名义上支持的人数。冲突成本是概率性的、一次性的，而串行化成本是确定性的、持续性的——这是权衡的底层结构。
怎么研究
- 范式：系统日志对比锁定式与合并式系统在相同任务下的人均等待时长、并行操作占比、副本外流率；受控实验操纵并发机制（锁 / 自动合并 / 无并发控制），观测小组的任务完成时间、同时编辑比例与成员参与度分布。
- 变量：自变量为并发机制与锁范围；因变量为等待时间、实际并行度、绕行行为发生率、参与者贡献均衡度。
- 在界面研究里的用途：为「这个协作场景值不值得上锁」提供数据——当冲突损失小于串行化损失时，锁是负资产。
- 方法论注意点：等待的代价不只是时长，还有被中断的思路与流失的参与意愿，日志测不到后者，需要配访谈或参与度的前后测量；实验室小组任务通常给足动机，掩盖了真实场景里「被挡两次就走了」的流失。
边界
锁并非一律劣选。当区域天然独占（我在重写这一节，别人确实不该动）、错误合并的代价极高（财务模型的核心公式、法律条款），锁定带来的串行是合理保险。锁的伤害也随持有时长放大：几秒的行级锁几乎无感，几小时的整篇锁定则是灾难。判断口径：冲突频率低而锁持有长的场景，锁的期望成本几乎总是超过收益，应改用检测-通知类的乐观方案。
怎么落地
- 引入锁定前先估算两个量：目标区域真实冲突频率（多数场景远低于直觉）、锁的平均持有时长；冲突低且持有长就放弃锁。
- 必须用锁时，把锁范围收到最小独占单元，并让等待者可以「预约下一个」而非反复试探。
- 显示持锁人与预计剩余时间，把不可预期的等待变成可预期的排队。
- 提供绕行的正式出口（基于副本的建议修改），防止用户用非正式副本绕行造成失控分叉。
- 验证：统计人均等锁次数与时长、锁外副本的数量走势；任一指标持续走高即说明串行化成本已超过冲突成本。