来源：http://www.cnblogs.com/li-chong/p/3345139.html
什么是死锁？
当多个进程同时访问一个资源时，其中的每个进程拥有的资源都是其他进程所需的，由此造成的每个进程都无法继续下去的情况。
产生死锁的原因主要是：
（1） 系统资源不足。
（2） 进程运行推进的顺序不合适。
（3） 资源分配不当等。
产生死锁的四个必要条件：
（1）互斥条件：一个资源每次只能被一个进程使用。
（2）请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3）不可剥夺条件：进程已获得的资源，在末使用完之前，不能强行剥夺。
（4）循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。
避免死锁：
死锁的预防是通过破坏产生条件来阻止死锁的产生，但这种方法破坏了系统的并行性和并发性。
死锁产生的前三个条件是死锁产生的必要条件，也就是说要产生死锁必须具备的条件，而不是存在这3个条件就一定产生死锁，那么只要在逻辑上回避了第四个条件就可以避免死锁。
避免死锁采用的是允许前三个条件存在，但通过合理的资源分配算法来确保永远不会形成环形等待的封闭进程链，从而避免死锁。该方法支持多个进程的并行执行，为了避免死锁，系统动态的确定是否分配一个资源给请求的进程。
预防死锁：
具体的做法是破坏产生死锁的四个必要条件之一。
在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配 。因此，对资源的分配要给予合理的规划。
最大限度降低死锁的产生的方法：
（1）按统一顺序访问对象
按同一顺序访问对象也就是：第一个事务提交或回滚后，第二个事务继续进行，这样不会发生死锁。
（2）避免事务中的用户交互
避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。例如，如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。
（3）保持事务简短并在一个批处理中：
在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致死锁。 保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。
（4）使用低隔离级别：
确定事务是否能在更低的隔离级别上运行，执行提交读取允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读取）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。
（5）使用绑定连接：
使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞。
对产生的死锁的建议：
(1)对于频繁使用的表使用集簇化的索引;
(2)设法避免一次性影响大量记录的T-SQL语句，特别是INSERT和UPDATE语句;
(3)设法让UPDATE和DELETE语句使用索引;
(4)使用嵌套事务时，避免提交和回退冲突;
(5)对一些数据不需要及时读取更新值的表在写SQL的时候在表后台加上(nolock)，如：Select * from tableA(nolock)
银行家算法：
该算法需要检查申请者对各类资源的最大需求量，如果现存的各类资源可以满足当前它对各类资源的最大需求量时，就满足当前的申请。换言之，仅当申请者可以在一定时间内无条件归还它所申请的全部资源时，才能把资源分配给它。这样申请者就可以很快完成其计算，然后释放它占用的资源，从而保证了系统中的所有进程都能完成，所以可以避免死锁的发生。这种算法的主要问题是，要求每个进程必须先知道资源的最大需求量，而且在系统的运行过程中，考察每个进程对各类资源的申请需花费较多的时间。另外，这一算法本身也有些保守，因为它总是考虑最坏可能的情况。