北大青鸟java培训：在Java程序中处理数据库超时与死锁

每个使用关系型数据库的程序都可能遇到数据死锁或不可用的情况，而这些情况需要在代码中编程来解决;本文主要介绍与数据库事务死锁等情况相关的重试逻辑概念，此外，还会探讨如何避免死锁等问题，文章以DB2(版本9)与为例进行讲解。

什么是数据库锁定与死锁锁定(Locking)发生在当一个事务获得对某一资源的“锁”时，这时，其他的事务就不能更改这个资源了，这种机制的存在是为了保证数据一致性;在设计与数据库交互的程序时，必须处理锁与资源不可用的情况。

锁定是个比较复杂的概念，仔细说起来可能又需要一大篇，所以在本文中，只把锁定看作是一个临时事件，这意味着如果一个资源被锁定，它总会在以后某个时间被释放。

而死锁发生在当多个进程访问同一数据库时，其中每个进程拥有的锁都是其他进程所需的，由此造成每个进程都无法继续下去。

如何避免锁我们可利用事务型数据库中的隔离级别机制来避免锁的创建，正确地使用隔离级别可使程序处理更多的并发事件(如允许多个用户访问数据)，还能预防像丢失修改(LostUpdate)、读“脏”数据(DirtyRead)、不可重复读(NonrepeatableRead)及“虚”(Phantom)等问题。

隔离级别问题现象丢失修改读“脏”数据不可重复读“虚”可重复读取NoNoNoNo读取稳定性NoNoNoYes光标稳定性NoNoYesYes未提交的读NoYesYesYes表1：DB2的隔离级别与其对应的问题现象在只读模式中，就可以防止锁定发生，而不用那些未提交只读隔离级别的含糊语句。

湖北电脑培训>

并发访问：当多个事务同时访问数据库中的同一张表时，就会出现并发访问的情况。如果这些事务在 *** 作时没有正确地使用锁机制，就可能导致死锁或锁表的问题。

锁粒度：锁粒度通常是指锁定的数据范围大小，如果锁的粒度不合理，例如过大或过小，就可能导致死锁或锁表的问题。通常建议在进行并发 *** 作时，使用尽可能小的锁粒度，以避免死锁或锁表的问题。

事务处理：如果事务处理不当，例如事务的隔离级别设置不当，就可能导致死锁或锁表的问题。例如，在并发环境下，如果多个事务同时访问同一张表，而其中一个事务占用了一条记录的锁，另一个事务也需要访问该记录，就可能导致死锁或锁表的问题。

针对死锁和锁表的问题，可以从以下方面来定位问题：

锁定信息：查询数据库中的锁定信息，查看哪些表被锁定，以及锁定的粒度、类型等信息。可以使用SHOW LOCKS或者SELECT FROM INFORMATION_SCHEMAINNODB_LOCKS来查询锁定信息。

连接信息：查询数据库中的连接信息，查看哪些连接占用了锁资源，以及锁资源的具体情况。可以使用SHOW PROCESSLIST或者SELECT FROM INFORMATION_SCHEMAPROCESSLIST来查询连接信息。

SQL语句：检查并发 *** 作中使用的SQL语句，查看是否存在锁定粒度不合理、事务隔离级别设置不当等问题，以及是否存在死循环、递归查询等问题。

系统资源：检查系统资源使用情况，查看是否存在内存、磁盘等资源不足的情况，以及是否存在网络延迟等问题。

多线程是很容易造成死锁，一般情况下死锁都是因为并发 *** 作引起的。我不懂JAVA,但死锁这个问题每种开发工具和数据库都会碰到解决办法是：

1、程序方面优化算法（如有序资源分配法、银行算法等），在一个程序里，能不用多线程更新同一张数据库表尽量不要用，如果要用，其避免死锁的算法就很复杂。

2、数据库方面设置等待超时时间

3、发生死锁后直接KILL掉数据库进程

一、活锁

如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求，，T2有可能永远等待，这就是活锁的情形，如图84(a)所示。

避免活锁的简单方法是采用先来先服务的策略。

二、死锁

如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已封锁了R2，于是T1等待T2释放R2上的锁。接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2，而T2又在等待T1的局面，T1和T2两个事务永远不能结束，形成死锁。

1 死锁的预防

在数据库中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法：

① 一次封锁法

一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。

一次封锁法虽然可以有效地防止死锁的发生，但也存在问题，一次就将以后要用到的全部数据加锁，势必扩大了封锁的范围，从而降低了系统的并发度。

② 顺序封锁法

顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。

顺序封锁法可以有效地防止死锁，但也同样存在问题。事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。

可见，在 *** 作系统中广为采用的预防死锁的策略并不很适合数据库的特点，因此DBMS在解决死锁的问题上普遍采用的是诊断并解除死锁的方法。

2 死锁的诊断与解除

① 超时法

如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。超时法实现简单，但其不足也很明显。一是有可能误判死锁，事务因为其他原因使等待时间超过时限，系统会误认为发生了死锁。二是时限若设置得太长，死锁发生后不能及时发现。

② 等待图法

事务等待图是一个有向图G=(T,U)。 T为结点的集合，每个结点表示正运行的事务；U为边的集合，每条边表示事务等待的情况。若T1等待T2,则T1、T2之间划一条有向边，从T1指向T2。事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地（比如每隔1分钟）检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。

DBMS的并发控制子系统一旦检测到系统中存在死锁，就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务，将其撤消，释放此事务持有的所有的锁，使其它事务得以继续运行下去。当然，对撤消的事务所执行的数据修改 *** 作必须加以恢复。

用悲观锁呗

当一个用户正在 *** 作某条记录时,这条记录将不能被读取,直到该用户的 *** 作完成,其他用户才能读取到这条记录

优点:数据读取的准确率和最新程度比较好

缺点:并发性比较差,需要上个用户 *** 作完毕了,下个用户才能进行 *** 作

Hibernate里有套封装好了的,这里就给一句关键代码,其他详细的,你自己找找吧

Inventory1 inv = (Inventory1) sessionload(Inventory1class, 1, LockModeUPGRADE);

事务不能开太多，及时提交，因为事务没有提交时，其他程序是不能对表进行更新 *** 作，降低了数据库的性能。涉及到大量数据的插入和更新是建议使用批量更新的方法。查询提高性能的方法是给作为条件的字段加索引，但是变长的汉字最好不要加索引，它不能提高查询的效率，最好用联表查询，减少子查询。一个表里的索引不能多于4个，否则插入和更新的速度是很慢的。。。关于数据库还有很多适用的技巧，在此抛砖引玉啦，呵呵

如果两个用户进程分别锁定了不同的资源 接着又试图锁定对方所锁定的资源 就会产生死锁 此时 SQL Server将自动地选择并中止其中一个进程以解除死锁 使得另外一个进程能够继续处理 系统将回退被中止的事务 并向被回退事务的用户发送错误信息 大多数设计良好的应用都会在接收到这个错误信息之后重新提交该事务 此时提交成功的可能性是很大的 但是 如果服务器上经常出现这种情况 就会显著地降低服务器性能 为避免死锁 设计应用应当遵循一定的原则 包括 ▲ 让应用每次都以相同的次序访问服务器资源 ▲ 在事务期间禁止任何用户输入 应当在事务开始之前收集用户输入 ▲ 尽量保持事务的短小和简单 ▲ 如合适的话 为运行事务的用户连接指定尽可能低的隔离级别 [适用于 ]此外 对于SQL Server的死锁问题 下面是几则实践中很有用的小技巧 ■ 使用SQL Server Profiler的Create Trace Wizard运行 Identify The Cause of a Deadlock 跟踪来辅助识别死锁问题 它将提供帮助查找数据库产生死锁原因的原始数据 [适用于 ]■ 如果无法消除应用中的所有死锁 请确保提供了这样一种程序逻辑 它能够在死锁出现并中止用户事务之后 以随机的时间间隔自动重新提交事务 这里等待时间的随机性非常重要 这是因为另一个竞争的事务也可能在等待 我们不应该让两个竞争的事务等待同样的时间 然后再在同一时间执行它们 这样的话将导致新的死锁 [适用于 ]■ 尽可能地简化所有T SQL事务 此举将减少各种类型的锁的数量 有助于提高SQL Server应用的整体性能 如果可能的话 应将较复杂的事务分割成多个较简单的事务 [适用于 ]■ 所有条件逻辑 变量赋值以及其他相关的预备设置 *** 作应当在事务之外完成 而不应该放到事务之内 永远不要为了接受用户输入而暂停某个事务 用户输入应当总是在事务之外完成 [适用于 ]■ 在存储过程内封装所有事务 包括BEGIN TRANSACTION和MIT TRANSACTION语句 此举从两个方面帮助减少阻塞的锁 首先 它限制了事务运行时客户程序和SQL Server之间的通信 从而使得两者之间的任何消息只能出现于非事务运行时间（减少了事务运行的时间） 其次 由于存储过程强制它所启动的事务或者完成 或者中止 从而防止了用户留下未完成的事务（留下未撤销的锁） [适用于 ]■ 如果客户程序需要先用一定的时间检查数据 然后可能更新数据 也可能不更新数据 那么最好不要在整个记录检查期间都锁定记录 假设大部分时间都是检查数据而不是更新数据 那么处理这种特殊情况的一种方法就是 先选择出记录（不加UPDATE子句 UPDATE子句将在记录上加上共享锁） 然后把它发送给客户 如果用户只查看记录但从来不更新它 程序可以什么也不做 反过来 如果用户决定更新某个记录 那么他可以通过一个WHERE子句检查当前的数据是否和以前提取的数据相同 然后执行UPDATE 类似地 我们还可以检查记录中的时间标识列（如果它存在的话） 如果数据相同 则执行UPDATE *** 作 如果记录已经改变 则应用应该提示用户以便用户决定如何处理 虽然这种方法需要编写更多的代码 但它能够减少加锁时间和次数 提高应用的整体性能 [适用于 ]■ 尽可能地为用户连接指定具有最少限制的事务隔离级别 而不是总是使用默认的READ MITTED 为了避免由此产生任何其他问题 应当参考不同隔离级别将产生的效果 仔细地分析事务的特性 [适用于 ] ■ 使用游标会降低并发性 为避免这一点 如果可以使用只读的游标则应该使用READ_ONLY游标选项 否则如果需要进行更新 尝试使用OPTIMISTIC游标选项以减少加锁 设法避免使用SCROLL_LOCKS游标选项 该选项会增加由于记录锁定引起的问题 [适用于 ]■ 如果用户抱怨说他们不得不等待系统完成事务 则应当检查服务器上的资源锁定是否是导致该问题的原因 进行此类检查时可以使用SQL Server Locks Object: Average Wait Time (ms) 用该计数器来度量各种锁的平均等待时间 如果可以确定一种或几种类型的锁导致了事务延迟 就可以进一步探究是否可以确定具体是哪个事务产生了这种锁 Profiler是进行这类具体分析的最好工具 [适用于 ]■ 使用sp_who和sp_who （SQL Server Books Online没有关于sp_who 的说明 但sp_who 提供了比sp_who更详细的信息）来确定可能是哪些用户阻塞了其他用户 [适用于 ]■ 试试下面的一个或多个有助于避免阻塞锁的建议 ）对于频繁使用的表使用集簇化的索引 ）设法避免一次性影响大量记录的T SQL语句 特别是INSERT和UPDATE语句 ）设法让UPDATE和DELETE语句使用索引 ）使用嵌套事务时 避免提交和回退冲突 [适用于 ] lishixinzhi/Article/program/SQLServer/201311/22222

以上就是关于北大青鸟java培训：在Java程序中处理数据库超时与死锁全部的内容，包括:北大青鸟java培训：在Java程序中处理数据库超时与死锁、数据库中死锁是什么产生的、数据库为什么总是产生死锁等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！