@Inn0Vat10n 在一个线程里每个任务的执行是连续非中断的。你假设的条件是第一个任务执行一半，然后执行第二个任务，然后再执行剩下一半。其实就变成任何锁只要锁了不释放都必然会阻塞。更准确的说只要嵌套请求锁就有可能因为嵌套的次序不同而阻塞。那么你就是在说 70 年论文对死锁的定义不严谨准确。那么你得到另一个有趣的结论。只要请求锁的嵌套次序都相同就不会死锁。所以循环嵌套也不是死锁的必然条件。

你看好好讨论就会得到一些有趣的结论。这不你又发现了一些奇怪的知识。所以死锁究竟应该如何定义？

@SingeeKing
@jinliming2
在单线程里死锁就失去可不可测试随机出现的条件。单线程被阻塞无论黑盒还是白盒跑一遍就发现了。写出有随机性质的需要一定的经验和技巧。

@kkbblzq 今天我轻描淡写的说出来，简单的不可思议。但我不光在理论上尝试解决这个问题，还写了一万字的论文和 4 万多行代码的工程和测试用例。我不是万能的，如果在并行计算有类似论文和解决方案也可以推荐给我。都是成年人了，请尽量让自己的回复能够对别人有帮助。

@Akiyu 是的没错，打开了一个新世界的大门了吧！任务不光可以拆分还能合并。很多技术细节没办法在一个帖子说清楚的。以后想到什么慢慢说吧。

@lance6716 你的意思是减少效率和死锁二选一？我认为多线程应用死锁是必须解决的不是二选一。静态分析不是不可能，静态分析是有前提条件的。

@PopRain 先不要急着说不可能，顺序访问只是解决方法之一。有了消息队列和线程池后系统环境和当时写论文的情景已经完全不同了。

@WangRicky 如果你有 100 个任务，其中 2 个任务死锁。把这两个任务单独放到你个线程里，剩下 98 个任务分别放的 98 个线程里。对于剩下 98 个任务死锁就不是问题吗？我没有否定线程，我只是否定有死锁条件的线程。我没有说有 2 个任务死锁，剩下的 98 个任务就不分线程。

@binux 如果我的理论是错误的，那么必然写不出 pelagia 呀。因为这是 pelagia 的理论基石之一。是不是偷换概念欺世盗名就让代码去说话吧。

@binux 套娃啦，这不是一个层面的问题

@cmqwan 人如其名的 帅

@codehz 准确的说是在无数个任务中找到可能死锁的任务，并将每组可能死锁的任务都放入一个线程。所以不是一个大锁，是无数个分组的锁。

查询的部分上 lucene 或 spark 。

没有被社会毒打和已经被社会毒打的两种生物。

对语法糖的追求是无穷无尽的毕生事业。

非工作时间做代码复查给加班费不？

搜索框架 Lucene

最初 html 时代是没有前端程序猿的。后端动态调整样式使用服务器过滤的方式。随着 JS，CSS 的流行，后端不再负责前端样式。

逻辑判断是一种条件筛选，目的是处理筛选的结果。
看不懂尽快返回这个判断标准。
也看不出两个例子的区别。

@VDimos 目前支撑使用 c，c++，lua 。嵌入 js 也在开发中。