锁的建模分析方法

#why

最近听完同事多线程锁的分享，最大的感受是没有构建一个非常明确的模型，以便很多知识点较散、不便理解、记忆。这也是本篇wiki目的，用建模的思路去记忆锁的技术。

#抽象游戏模型

这是一个一群玩家竞争有限资源的游戏。这个游戏涉及三个元素：玩家、资源、守护者：

1) 玩家：这不是孤立的游戏、而是社交游戏。我们有很多玩家同时在线，他们都渴望使用资源。他们可以group成联盟、也可以选择独立行事。

他们可合作、也可竞争，这是他们的社交性。

2) 资源：游戏的目的在于追求资源的利用价值最大化。

3) 守护者。他是资源的管理者，负责制定规则、并做监管。他可以选择制定很高门槛的准入规则，也可以实施宽松的策略、冲突后监管。

标准的排队模型

乐观与悲观锁的模型差异：

#游戏模型分析

		特性	设计策略
玩家	1）尽最大努力获取资源；	社交性（social）：玩家既可以是朋友、也可以是敌人。有天然分组（group）的特性。存在公平性的问题。	读者/写者。公平问题。
资源	1）追求资源的利用价值最大化。	共享性（shared）：对于可共享的资源，增大reuse效率。	让旁大的读者sharing资源。独占 vs 共享：shared。
资源	1）追求资源的利用价值最大化。	有限性（limited）：资源相对有限，可适当增加/减少资源数量。	抽象多资源模式。
守护者	1）保护资源有序性修改； 2）最小的管理成本；	监看（Watch）：能看到所有玩家及资源的状态，是游戏的主载者。	维护全局玩家及资源的状态。
		守护（Guard）：制定规则，包含管理等待玩家，及处理资源运行时冲突、异常等情况。 “谁能不能进去、进去后出了乱子怎么搞。”	队列机制，发号器（玩家坐着等通知、还是站着排队）。悲观 vs 乐观。阻塞 vs 自旋。可重入 vs. 不可重入。公平 vs. 允许插队。
		智能化（smart & intellect）：关于自动化的本质，是让游戏编写者（programmer）人工配置参数、还是做依赖运行时状态、利用数据不断升级决策算法。	组合多种锁资源策略，动态选择

按此模型结构化整体的锁知识：

#java8对读写锁的优化

java8引入了：StampedLock、优化了读者与写者互斥问题（它没有implement readwrite lock接口）。老的readwrite lock读多写少、读写互斥、写可能抢不过而被等待很久，StampedLock引入spin lock机制，让写玩家来了就干，可能会出现读玩家被踢出来的场景。读玩家如果发现值被修改了、就再读一次新值。

#分布式锁模型 vs. 多线程锁模型的差异

分布式锁引入的新变量是：

1、在分布式里每个人都是不稳定的。体现在状态上。alive、die、unknown(network timeout)、suspended这四种状态，可以按明确状态（alive、die）、不明确状态（unknown）、以及错误状态（suspended）等。

2、网络延迟导致玩家当前状态与守护者的状态永远无法same、只能同步sync。

建模之后的分析及解决方案，就不做过深描述了。

#排队论(queuing theory)及scale

这个模型本质上排队论，对排队论不扩展。只启发地谈一个案例、如何将排队模型scale到其它领域上去，提升知识利用率。

技术团队接需求，就是经典的排队模型，需求就是玩家、开发就是资源、排期机制就是守护者。有的需求优先级高、允许插队，有的需求躺在需求池里太久、timeout了直接就抛弃掉。我们怎么决策要招多少技术、怎么衡量资源整体的效率？如何去做量化？ok！排队论里有一个Little law，套在需求排期的场景下就是：

生产周期(Lead Time) = 在制品数量WIP * 平均需求完成时间。 lead time类似周转率，越小越好。

这说明为了提升研发效率，一方面可以减少需求数量、提升质量，另一方面可以短期增加开发人数、长期提升团队能力以降低平均需求完成时间。这是一个最简单的排队模型，约束条件较多，还可以更深入的建模，以便更科学的量化效率指标。

#附录

1、java jdk locks包下的类结构：