数据库锁的产生缘由及解决办法

数据库和操做系统同样，是一个多用户使用的共享资源。当多个用户并发地存取数据 时，在数据库中就会产生多个事务同时存取同一数据的状况。若对并发操做不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。加锁是实现数据库并 发控制的一个很是重要的技术。在实际应用中常常会遇到的与锁相关的异常状况，当两个事务须要一组有冲突的锁，而不能将事务继续下去的话，就会出现死锁，严 重影响应用的正常执行。 
在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其余的事务不能对它读取和修改。加了共享锁的数据对象能够被其余事务读取，但不能修改。数据库利用这两 种基本的锁类型来对数据库的事务进行并发控制。 
死锁的第一种状况 
一个用户A 访问表A(锁住了表A),而后又访问表B；另外一个用户B 访问表B(锁住了表B)，而后企图访问表A；这时用户A因为用户B已经锁住表B，它必须等待用户B释放表B才能继续，一样用户B要等用户A释放表A才能继续，这就死锁就产生了。 
解决方法： 
这种死锁比较常见，是因为程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操做时，尽可能按照相同的顺序进 行处理，尽可能避免同时锁定两个资源，如操做A和B两张表时，老是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任什么时候刻都应该按照相同的顺序来锁定资源。 
死锁的第二种状况 
用户A查询一条纪录，而后修改该条纪录；这时用户B修改该条纪录，这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁，而用户B里的独占锁因为A 有共享锁存在因此必须等A释放掉共享锁，而A因为B的独占锁而没法上升的独占锁也就不可能释放共享锁，因而出现了死锁。这种死锁比较隐蔽，但在稍大点的项 目中常常发生。如在某项目中，页面上的按钮点击后，没有使按钮马上失效，使得用户会屡次快速点击同一按钮，这样同一段代码对数据库同一条记录进行屡次操 做，很容易就出现这种死锁的状况。 
解决方法： 
一、对于按钮等控件，点击后使其马上失效，不让用户重复点击，避免对同时对同一条记录操做。 
二、使用乐观锁进行控制。乐观锁大可能是基于数据版本（Version）记录机制实现。即为数据增长一个版本标识，在基于数据库表的版本解决方案中，通常是 经过为数据库表增长一个“version”字段来实现。读取出数据时，将此版本号一同读出，以后更新时，对此版本号加一。此时，将提交数据的版本数据与数 据库表对应记录的当前版本信息进行比对，若是提交的数据版本号大于数据库表当前版本号，则予以更新，不然认为是过时数据。乐观锁机制避免了长事务中的数据 库加锁开销（用户A和用户B操做过程当中，都没有对数据库数据加锁），大大提高了大并发量下的系统总体性能表现。Hibernate 在其数据访问引擎中内置了乐观锁实现。须要注意的是，因为乐观锁机制是在咱们的系统中实现，来自外部系统的用户更新操做不受咱们系统的控制，所以可能会造 成脏数据被更新到数据库中。 
三、使用悲观锁进行控制。悲观锁大多数状况下依靠数据库的锁机制实现，如Oracle的Select … for update语句，以保证操做最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销每每没法承受。如一个金融系统， 当某个操做员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），若是采用悲观锁机制，也就意味着整个操做过程当中（从操做员读 出数据、开始修改直至提交修改结果的全过程，甚至还包括操做员中途去煮咖啡的时间），数据库记录始终处于加锁状态，能够想见，若是面对成百上千个并发，这 样的状况将致使灾难性的后果。因此，采用悲观锁进行控制时必定要考虑清楚。 
死锁的第三种状况 
若是在事务中执行了一条不知足条件的update语句，则执行全表扫描，把行级锁上升为表级锁，多个这样的事务执行后，就很容易产生死锁和阻塞。相似的情 况还有当表中的数据量很是庞大而索引建的过少或不合适的时候，使得常常发生全表扫描，最终应用系统会愈来愈慢，最终发生阻塞或死锁。 
解决方法： 
SQL语句中不要使用太复杂的关联多表的查询；使用“执行计划”对SQL语句进行分析，对于有全表扫描的SQL语句，创建相应的索引进行优化。 
5．小结 
整体上来讲，产生内存溢出与锁表都是因为代码写的很差形成的，所以提升代码的质量是最根本的解决办法。有的人认为先把功能实现，有BUG时再在测试阶段进 行修正，这种想法是错误的。正如一件产品的质量是在生产制造的过程当中决定的，而不是质量检测时决定的，软件的质量在设计与编码阶段就已经决定了，测试只是 对软件质量的一个验证，由于测试不可能找出软件中全部的BUG。