死锁怎么解决？

处理死锁的思路如下：

预防死锁：破坏四个必要条件中的一个或多个来预防死锁。

避免死锁：在资源动态分配的过程中，用某种方式防止系统进入不安全的状态。

检测死锁：运行时产生死锁，及时发现思索，将程序解脱出来。

解除死锁：发生死锁后，撤销进程，回收资源，分配给正在阻塞状态的进程。

预防死锁的办法：

破坏请求和保持条件：

1、一次性的申请所有资源。之后不在申请资源，如果不满足资源条件则得不到资源分配。

2、只获得初期资源运行，之后将运行完的资源释放，请求新的资源。

破坏不可抢占条件：当一个进程获得某种不可抢占资源，提出新的资源申请，若不能满足，则释放所有资源，以后需要，再次重新申请。

破坏循环等待条件：对资源进行排号，按照序号递增的顺序请求资源。若进程获得序号高的资源想要获取序号低的资源，就需要先释放序号高的资源。

扩展资料

形成死锁的四个必要条件：

（1） 互斥条件：一个资源每次只能被一个进程使用。

（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。

（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。

（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

如果一组进程中每一个进程都在等待仅由该组进程中的其他进程才能引发的事件，那么该组进程是死锁的。

举例来说：有两个进程A和B,A持有资源a等待b资源，B持有资源b等待a资源，两个进程都在等待另一个资源的同时不释放资源，就形成死锁。

在并发程序设计中，死锁 (deadlock) 是一种十分常见的逻辑错误。通过采用正确的编程方式，死锁的发生不难避免。

死锁的四个必要条件

在计算机专业的本科教材中，通常都会介绍死锁的四个必要条件。这四个条件缺一不可，或者说只要破坏了其中任何一个条件，死锁就不可能发生。我们来复习一下，这四个条件是：

•互斥（Mutual exclusion）：存在这样一种资源，它在某个时刻只能被分配给一个执行绪（也称为线程）使用；

•持有（Hold and wait）：当请求的资源已被占用从而导致执行绪阻塞时，资源占用者不但无需释放该资源，而且还可以继续请求更多资源；

•不可剥夺（No preemption）：执行绪获得到的互斥资源不可被强行剥夺，换句话说，只有资源占用者自己才能释放资源；

•环形等待（Circular wait）：若干执行绪以不同的次序获取互斥资源，从而形成环形等待的局面，想象在由多个执行绪组成的环形链中，每个执行绪都在等待下一个执行绪释放它持有的资源。

解除死锁的必要条件

不难看出，在死锁的四个必要条件中，第二、三和四项条件比较容易消除。通过引入事务机制，往往可以消除第二、三两项条件，方法是将所有上锁 *** 作均作为事务对待，一旦开始上锁，即确保全部 *** 作均可回退，同时通过锁管理器检测死锁，并剥夺资源（回退事务）。这种做法有时会造成较大开销，而且也需要对上锁模式进行较多改动。

消除第四项条件是比较容易且代价较低的办法。具体来说这种方法约定：上锁的顺序必须一致。具体来说，我们人为地给锁指定一种类似“水位”的方向性属性。无论已持有任何锁，该执行绪所有的上锁 *** 作，必须按照一致的先后顺序从低到高（或从高到低）进行，且在一个系统中，只允许使用一种先后次序。

请注意，放锁的顺序并不会导致死锁。也就是说，尽管按照 锁A, 锁B, 放A, 放B 这样的顺序来进行锁 *** 作看上去有些怪异，但是只要大家都按先A后B的顺序上锁，便不会导致死锁。

举例

假如有三个对象A、B、C，我们人为约定它们的锁序是： A 先于 B 先于 C。举例说来，下列锁序均为合法：

• 锁C，放C

• 锁B，放B

• 锁B，锁C，放B，放C

• 锁B，锁C，放C，放B

• 锁A，放A

• 锁A，锁C，放A，放C

• 锁A，锁C，放C，放A

• 锁A，锁B，放A，放B

• 锁A，锁B，放B，放A

• 锁A，锁B，锁C，放A，放B，放C

• 锁A，锁B，锁C，放C，放B，放A

而在上面定义的系统中，可能导致发生死锁典型上锁序列包括：

• 锁B，锁A，锁C，放C，放A，放B

（因为先B后A的上锁顺序违反了锁序约定，如果另一执行绪同时按照先A后B的顺序上锁，则可能由于执行绪甲获得了B，执行绪乙获得了A，而导致双方同时等待对方释放所持有的锁，从而形成死锁局面；解法是将 *** 作序列中增加适当的锁 *** 作，即改为锁B，放B，锁A，锁B，锁C，放C，放A，放B）

或者说，只要拿锁的时候不出现逆序（例如拿着C的时候试图抓B或A，或者拿着B的时候试图抓A），并出现潜在逆序的时候先放掉“小”锁再抓大的，就一定不造成死锁了。

第一，内存泄漏

C/C++程序还可能产生另一个指针问题:丢失对已分配内存的引用。当内存是在子程序中被分 配时，通常会出现这种问题，其结果是程序从子程序中返回时不会释放内存。如此一来，对已分配的内存的引用就会丢失，只要 *** 作系统还在运行中，则进程就会一 直使用该内存。这样的结果是，曾占用更多的内存的程序会降低系统性能，直到机器完全停止工作，才会完全清空内存。

第二，C指针错误

用C或C++编写的程序，如Web服务器API模块，有可能导致系统的崩溃，因为只要间接引 用指针(即，访问指向的内存)中出现一个错误，就会导致 *** 作系统终止所有程序。另外，使用了糟糕的C指针的Java模拟量(analog)将访问一个空的 对象引用。Java中的空引用通常不会导致立刻退出JVM，但是前提是程序员能够使用异常处理方法恰当地处理错误。在这方面，Java无需过多的关注，但 使用Java对可靠性进行额外的度量则会对性能产生一些负面影响。

第三，数据库中的临时表不够用

许多数据库的临时表(cursor)数目都是固定的，临时表即保留查询结果的内存区域。在临时表中的数据都被读取后，临时表便会被释放，但大量同时进行的查询可能耗尽数目固定的所有临时表。这时，其他的查询就需要列队等候，直到有临时表被释放时才能再继续运行。

第四，线程死锁

由多线程带来的性能改善是以可靠性为代价的，主要是因为这样有可能产生线程死锁。线程死锁 时，第一个线程等待第二个线程释放资源，而同时第二个线程又在等待第一个线程释放资源。我们来想像这样一种情形:在人行道上两个人迎面相遇，为了给对方让 道，两人同时向一侧迈出一步，双方无法通过，又同时向另一侧迈出一步，这样还是无法通过。双方都以同样的迈步方式堵住了对方的去路。假设这种情况一直持续 下去，这样就不难理解为何会发生死锁现象了。

第五，磁盘已满

导致系统无法正常运行的最可能的原因是磁盘已满。一个好的网络管理员会密切关注磁盘的使用情况，隔一定的时间，就需要将磁盘上的一些负载转存到备份存储介质中(例如磁带)。

日志文件会很快用光所有的磁盘空间。Web服务器的日志文件、SQL*Net的日志文件、 JDBC日志文件，以及应用程序服务器日志文件均与内存泄漏有同等的危害。可以采取措施将日志文件保存在与 *** 作系统不同的文件系统中。日志文件系统空间已 满时Web服务器也会被挂起，但机器自身被挂起的几率已大大减低。

第六，服务器超载

Netscape Web服务器的每个连接都使用一个线程。Netscape Enterprise Web服务器会在线程用完后挂起，而不为已存在的连接提供任何服务。如果有一种负载分布机制可以检测到服务器没有响应，则该服务器上的负载就可以分布到其 它的Web服务器上，这可能会致使这些服务器一个接一个地用光所有的线程。这样一来，整个服务器组都会被挂起。 *** 作系统级别可能还在不断地接收新的连接， 而应用程序(Web服务器)却无法为这些连接提供服务。用户可以在浏览器状态行上看到connected(已连接)的提示消息，但这以后什么也不会发生。

总之，还有许多因素也极有可能导致Web香港服务器租用或香港服务器托管站点无法工作。有许多种原因可能导致Web站点无法正常工作，这使得系统地检查所有问题变得很困难。

---