死锁问题
用多线程load数据到数据库,发生下面的异常

Transaction   (Process   ID   98)   was   deadlocked   on   lock   resources   with   another   process   and   has   been   chosen   as   the   deadlock   victim.   Rerun   the   transaction.

看得出是数据库端抛了异常,   但是不是很清楚到底怎么被死锁了.   单线程是没有问题的.

望高手们指教

------解决方案--------------------
尽管死锁不能完全避免，但遵守特定的编码惯例可以将发生死锁的机会降至最低。将死锁减至最少可以增加事务的吞吐量并减少系统开销，因为只有很少的事务：

回滚，撤消事务执行的所有工作。


由于死锁时回滚而由应用程序重新提交。


下列方法有助于将死锁减至最少：

按同一顺序访问对象。


避免事务中的用户交互。


保持事务简短并处于一个批处理中。


使用较低的隔离级别。


使用基于行版本控制的隔离级别。


将 READ_COMMITTED_SNAPSHOT 数据库选项设置为 ON，使得已提交读事务使用行版本控制。


使用快照隔离。


使用绑定连接。

------解决方案--------------------
在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁。例如：

事务 A 获取了行 1 的共享锁。


事务 B 获取了行 2 的共享锁。


现在，事务 A 请求行 2 的排他锁，但在事务 B 完成并释放其对行 2 持有的共享锁之前被阻塞。


现在，事务 B 请求行 1 的排他锁，但在事务 A 完成并释放其对行 1 持有的共享锁之前被阻塞。


事务 A 必须在事务 B 完成之后才能完成，但事务 B 被事务 A 阻塞。这种情况也称为循环依赖关系：事务 A 依赖于事务 B，而事务 B 又依赖于事务 A，从而形成了一个循环。

除非某个外部进程断开死锁，否则死锁中的两个事务都将无限期等待下去。Microsoft SQL Server Database Engine 死锁监视器定期检查陷入死锁的任务。如果监视器检测到循环依赖关系，将选择其中一个任务作为牺牲品，然后终止其事务并提示错误。这样，其他任务就可以完成其事务。对于事务以错误终止的应用程序，它还可以重试该事务，但通常要等到与它一起陷入死锁的其他事务完成后执行。