其实这个题目有点夸大，但是我还是相信对于大家找出大F睡死的原因有着理论的指导意义。
首先我们知道，大F也和大家上网用的计算机一样，是个微缩化，专业化的计算机。它同样具有CPU，内存等等一系列的硬件，只是它不像计算机可以随便我们拆开，可以明确的看到各个部件。（当然如果你对自己的拆东西和装东西手艺有信心，就当我没有说过。）计算机的各种资源是非常有限的，比如计算机内存，端口，CPU的时间片，等等，这些往往就是各个程序运行所必需的资源。现代计算机的操作系统，对于运行的程序对于资源的需求都是通过一定的方式来有序的进行分配，以确保系统能稳定有序的运行下去。
比如一个程序，或者说一个进程PRO1，需要访问端口com1，同时又要访问dsk0，这个时候操作系统就先判断com1是否空闲，如果空闲那么将该端口分配给pro1，完成后才判断DSK0是否空闲以便能分配给PRO1。在这个时候就出现2种情况了，第一种，你很幸运dsk0空闲，操作系统将按pro1的要求将该资源dsk0分配给进程，pro1将很正常的运行下去。
第二种情况，很不幸该资源（本例子资源是DSK0）被某进程PRO2占用，PRO1将继续等待PRO2将dsk0释放，这个时候我们在系统上所看到的就是该程序PRO1死了，对其操作全部没有反应。但是这个时候又有2种情况。第一种：PRO2占用dsk0，当PRO2对资源dsk0使用结束后将该资源释放，操作系统将DSK0再次分配给PRO1，于是我们的PRO1就再次运行起来。我们感觉就是PRO1曾经卡了，但是经过段时间后又可以继续运行了。第二种情况呢就是你太不幸了，PRO2一直不释放该资源，甚至可能PRO2也需要访问COM1,于是2个进程就像2个傻子在独木桥上顶牛，你不让我我不让你。操作系统对于2个进程都无法解决，这种情况在计算机上被称为死锁。如果我们在计算机上遇到这个问题，一般重启机器或者关闭死锁的一个进程，就可以解决。但是像大F这样的资源紧张的专业系统资源就更紧张，如果写程序的对于死锁没有进行过预先的规划，往往可能出现死锁的问题。但是如果要预先进行规划，则可能以降低程序运行速度和增加运行所需内存空间为代价，并且对程序编制人的专业知识和对系统了解提出了更高的要求。这些对于软件开发企业来说投入的成本将进一步增加，当然这就是题外话了。
