关于锁的相关知识，大家可以看我的这篇文章《知方可补不足~Sqlserver中的几把锁和.net中的事务级别》
死锁我想大家都知道，当一个对话（线程）占用一个资源时，别一个线程也同时去访问它，并且其中一个优化级高的对话将ＳＱＬ锁状态提升为Ｘ锁（排它锁）后，其一个对话将会被作为“牺牲品”抛弃，这种现象在ＳＱＬＳＥＲＶＥＲ中就叫做死锁，引起死锁的原因有很多，一般在网上被前人总结为四点
1、互斥使用（资源独占）
一个资源每次只能给一个进程使用
2、不可强占（不可剥夺）
资源申请者不能强行的从资源占有者手中夺取资源，资源只能由占有者自愿释放
3、请求和保持（部分分配，占有申请）
一个进程在申请新的资源的同时保持对原有资源的占有（只有这样才是动态申请，动态分配）
4、循环等待
存在一个进程等待队列 {P1 , P2 , … , Pn}, 其中P1等待P2占有的资源，P2等待P3占有的资源，…，Pn等待P1占有的资源，形成一个进程等待环路
观察锁的发生，使用sqlProfiler工具
设置对话（线程，spid）的优先级
SET TRANSACTION ISOLATION LEVEL Read Committed
BEGIN TRAN
SET DEADLOCK_PRIORITY HIGH对于优先级，以以下选项
LOW | NORMAL | HIGH
也可以直接使用数字
<numeric-priority> ::= { -10 | -9 | -8 | …| 0 | …| 8 | 9 | 10 }
在ＥＦ里，对发生死锁的代码进行重新提交
在ＥＦ架构里，仓储大叔提倡大家使用自己的SaveChanges方法，其原因就是可以对提交动作进行统一的控制，在里面加日志，加捕捉，加策略可以成为可能，呵呵。
//下面代码节选自大叔的DbContextRepository类 catch (EntityException ex)//EF配置异常，这个异常可以忽略(The underlying provider failed on Commit.) { if (Logger != null) Logger(ex.Message); throw new Exception(ex.Message);//EntityException } catch (Exception ex)//捕获所有异常 { if (Logger != null)//如果没有定义日志功能，就把异常抛出来吧 Logger(ex.Message + "处理时间：" + DateTime.Now); if (ex.GetBaseException() != null && ex.GetBaseException().GetType() == typeof(System.Data.SqlClient.SqlException)) { //SqlException异常，再重新进行提交 Db.SaveChanges(); } throw new Exception(ex.Message); }