多线程开发的终结者 pelagia

[gantleman]

全文地址: gameinstitute.qq.com/community/detail/133448

依赖和死锁问题。 在介绍各种多线程开发工具前我先要介绍下多线程下最大的二个问题。 第一个问题就是任务执行的依赖关系。在不同线程间执行的任务代码会有先后次序的需求。但因为多线程的特性会导致这些代码被同时执行。那么需要一种方法来控制多线程间代码的依赖关系。违反这种依赖关系可能会导致数据的丢失。执行过程的严重错误。甚至崩溃，死机。

第二个问题就是死锁。在多线程执行过程中，多个线程会访问同一个数据。如果其中一个线程锁住了一个数据，然后请求另一个数据的锁。而其他线程刚好锁住了他请求中的数据，并也刚好请求他拥有的数据。就会导致两个线程互相等待系统卡死的问题。

为什么多线程下这两个问题是核心问题？ 因为这两个问题的出现与多线程软件规模成正比，也就是说随着多线程软件规模的增加，这两个问题出现的概率也在增加。他们像达克摩斯之剑一样悬挂在任何多线程项目的上空。

pelagia

是开源项目其地址在 github.com/surparallel/pelagia

pelagia 是由 surparallel open source 推出的开源项目，是唯一同时解决依赖和死锁的多线程工具。 在前面我简单的介绍了多线程工具的现状。我们知道依赖和死锁是多线程开发中必须要解决的两个问题。并不是简单的因为依赖和死锁会有概率的出现在多线程项目中。而是因为在多线程项目中存在指数规模效应的问题。

所谓指数规模效应是指假设一个项目有两个线程，如果你新添加一个线程，那么两个线程间发生依赖和死锁，就有 3 的 2 次方即 9 种可能。如果有 99 个线程，你同样是新添加一个线程，那么发生依赖和死锁的可能就变成了 100 的 2 次方种可能。也就是说可能发生依赖和死锁的状况，随着开发任务的增加成指数级别的增加。

这样就导致每开发一个新的线程任务就要和其余的线程任务做仔细的检查。检查是否可能出现依赖和死锁。而这种检查的规模也是程指数增加的。这样就导致我们开发的多线程项目很快就会达到团队所能承受的极限。

因为指数规模效应的存在就必然会有祖传代码拍死老师傅。为了避免老师傅们被祖传代码拍死。pelagia 结合消息通信和数据分区两个技术，同时解决依赖和死锁问题，彻底拯救了老师傅。

pelagia 目前处于准完成阶段。大部分功能已经开发完毕。包括消息通信的统计系统，支持多线程的日志系统，多线程数据分区的存储系统。其硬盘储存系统性能略快于 redis 。

[KunMinX]

“指数规模效应” 这个词挺有趣的，我通常称之为 “破窗效应”，指在多人协作的软件工程背景下，一旦放任，后续就不再受控制、一发不可收拾。

比如客户端或前端页面开发中用到的 DataBinding 、React 等数据驱动框架技术，就是通过函数式编程或类似的手法，将过程隐藏，来解决过程变量的暴露导致的不可预期问题。（比如视图实例通过 findViewById 被暴露出去导致一系列不可控的 null 安全问题）

刚刚看到你在我的帖子下方的留言了，找了一圈没有找到你的联系方式。如对 “原创价值观” 感兴趣，可通过我在 github 主页留下的方式联系到我，备注 v2 原创价值观。

[helloword123]

恕我眼拙 我总觉得 你把多线程 的问题 描述的太简单了些 依赖 死锁？

[gantleman]

@helloword123 不不不，您不是眼拙。