数据库锁机制

一、什么是锁机制？数据库为要有锁机制？

       数据库是一个多用户使用的共享资源，当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。如果对并发操作不加以控制的话，就可能会出现读取或存储错误数据的现象，从而破坏数据库数据的一致性。

        加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。枷锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。

二、锁的基本类型

       锁包括：行级锁、表级锁。

       (1) 行级锁，是一种排他锁，防止其他事务修改此行数据；在使用以下语句时，Oracle会自动应用行级锁：insert \ update \ delete \ select ... for update[of columns] [wait n | nowait]；select ... for update语句允许用户一次锁定多条记录进行更新；

            使用 commit 或者 rollback 语句释放锁；

       (2) 表级锁，分为五类：

            ① 行共享 (row share) ：禁止排他锁定表；

            ② 行排他 (row exclusive) ：禁止使用排他锁和共享锁；

            ③ 共享锁 (share) ：锁定表，对记录只读不写，多个用户可以同时在同一个表上应用此锁；

            ④ 共享行排他 (share row exclusive) ：比共享锁更多的限制，禁止使用共享锁及更高的锁；

            ⑤ 排他 (excluesive) ：限制最强的表锁，仅允许其他用户查询该表的行。禁止修改和锁定表；

三、乐观锁和悲观锁

        行级锁和表级锁是根据锁的粒度来区分的，行记录、表都是资源，锁是作用在这些资源上的。如果粒度比较小 (如行级锁)，可以增加系统的并发量，但需要较大的系统开销，会影响到性能，出现死锁，因为粒度小则操作的锁的数量会增加； 而如果作用在表上，粒度大，开销小，维护的锁少，不会出现死锁，但是并发是相当昂贵的，因为锁定了整个表就限制了其他事务对这个表中其他数据记录的访问。

       (1) 悲观锁：是基于数据库机制实现的。

       Pessimistic Lock，它是指对数据被外界 (包括本系统当前的其他事务，以及来自外部系统的事务处理) 修改持保守悲观态度，事务每次去操作数据的时候都假设有其他事务会修改需要访问的数据，所以在访问之前都要求上锁；行锁、表锁等，读锁、写锁等，都是在做操作之前先上锁，因此，在整个数据处理过程中，将数据处于锁定状态。

        悲观锁的实现，往往依靠数据库提供的锁机制 (也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据)。

        一个典型的依赖数据库的悲观锁调用：  select * from Table_A where column_N="xxxx" for update；

        这条sql语句锁定了Table_A表中所有符合检索条件 (column_N="xxxx") 的记录。本次事务提交之前 (事务提交时会释放事务过程中的锁)，外界无法修改这些记录。

        在业务逻辑实现过程中，往往需要保证数据访问的排他性。如在金融系统的日结算处理中，希望针对某个cut-off时间点的数据进行处理，而不希望在结算进行过程中(可能是几秒，也可能是几个小时)，数据再发生变化。此时，就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改，这样的机制在这里，也就是所谓的“锁”；即，给我们选定的目标数据上锁，使其无法被其他程序修改。

       Hibernate 悲观锁实现：基于数据库锁机制

Query query = Session.createQuery("select * from User where username='Hellen'");
query.setLockMode("User", LockMode.UPGRADE);    //加锁； User是用户实体类的别名
List<User> ps = query.list();

       执行以上sql语句，Hibernate的悲观锁通过数据库的 for update 实现。

       LockMode.NONE：无锁机制；

       LockMode.WRITE：insert、update 记录时自动获取悲观锁；

       LockMode.READ：在读取数据时，自动获取悲观锁；

       LockMode.UPGRADE：利用数据库的 for update 子句加锁；

       LockMode.UPGRADE_NOWAIT：Oracle特定实现；用Oracle的 for update nowait 子句加锁；

       (2) 乐观锁：

        相对于悲观锁而言，乐观锁机制采用了更加宽松的加锁机制。悲观锁大多数情况下依靠数据的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

       Optimistic Lock，即乐观锁，和悲观锁相反，事务每次操作数据之前，都假设其他事务不会修改这些需要访问的数据，所以在访问之前不需要上锁，只是在进行更新修改操作的时候判断一下在访问的期间有没有其他人修改数据了。它使用于多读的应用类型，冲突真的发生比较少的时候就比较好，这样省去了系统资源开销，可以提高吞吐量；但是如果是真的经常要发生冲突的，那每次还要去判断进行retry，反倒减低的了性能，这个时候悲观锁比较好。数据库如果提供类似于 write_condition机制的其实都是提供的乐观锁。

        如，一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时(如更改用户账户金额)，若是采用悲观锁机制，也就意味着整个操作过程中(从操作员读出数据、开始修改，直到提交修改结果的全过程，甚至还包括操作员中途因事离开的时间)，数据库记录始终处于加锁状态，可想而知，若有成百上千个并发，这样的情况将导致怎样的后果。

       乐观锁机制在一定程度上解决了这个问题。乐观锁大多是基于数据版本记录机制实现的。

       所谓的数据版本是指，数据增加一个版本标记，在基于数据表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加1。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

        例如，数据库账户信息表中有个version字段，当前值为1；而当前账户余额字段 balance为 1000。

                   1. 操作员A此时将其读出 (version=1)，并从其账户余额中扣除200 (1000 - 200)；

                   2. 在操作员A操作的过程中，操作员B也读出此用户信息 (version=1)，并从其账户中扣除 300；

                   3. 操作员完成了修改工作，将数据版本号增加1 (version=2)，连同账户扣除后金额 (balance=800)提交到数据库进行了更新，此时由于提交数据版本大于数据库记录的当前版本，数据被更新，数据库记录version更新为2；

                   4. 操作员B完成了操作，也将版本号增加1 (version=2)，试图向数据库提交数据(balance=700)，但此时进行数据库记录版本发现，操作员B提交的数据版本号为2，数据库记录当前版本号也为2！！不满足 “提交版本必须大于记录当前版本才能执行更新”的乐观锁策略，因此，操作员B的提交将被驳回。这样，就避免了操作员B用基于version=1的就数据修改的结果覆盖操作A的操作结果的可能。

        从以上案例可看出，乐观锁机制避免了长事务中的数据库加锁开销(操作员A和操作员B操作过程中，都没有对数据库数据加锁)，大大提升了大并发量下的系统整体性能表现。需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性。如在上面的例子中，由于乐观锁机制实在系统实现的，来自外部系统的用户余额更新操作不受当前系统的控制，因此也可能会造成脏数据被更新到数据中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应的调整(如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开)。

       Hibernate在其数据访问引擎中内置了乐观锁实现，如果不用考虑外部系统对数据库的更新操作，利用Hibernate提供的透明化乐观锁实现，将会大大提升我们的生产力。Hibernate中可以通过class描述的optimistic-lock属性结合version描述符指定：

<hibernate-mapping>
    <class name="com.packaging.entity.User" table="user_t" optimistic-lock="version"></class>
</hibernate-mapping>

      optimisttic-lock属性的可选择值包括：

       ① none：无乐观锁；

       ② version：通过版本机制实现乐观锁；

       ③ dirty：通过检查发生过变动的属性实现乐观锁；

       ④ all：通过检查所有属性实现乐观锁；

四、Java中的锁机制

       一段synchronized代码被一个线程执行前，它要先拿到执行这段代码的权限，在Java中就是拿到某个同步对象的锁(一个对象只有一把锁)；若此时同步对象的锁被其他线程拿走了，那么当前线程就只能等待了，即当前线程被阻塞在锁池等待队列中。取到对象锁之后，线程就开始执行同步代码(被synchronized所修饰的代码)；线程执行完同步代码后立即将同步锁归还给同步对象，其他在锁池中等待的线程就可以获取锁对象继而执行同步代码了。这就保证了同步代码在同一时刻只有一个线程在执行。

        在Java多线程编程中，一个非常重要的问题就是线程的同步问题；关于线程同步，一般有以下解决方案：

       ① 在需要同步的方法的方法签名中加入 synchronized 关键字；即将需要同步的方法定义为同步方法；

       ② 使用 synchronized 代码块对需要进行同步的代码段进行同步；即将需要同步的代码定义为同步代码块；

       另外，为了解决多个线程对同一变量进行访问时可能发生的安全性问题，不仅可以采用同步机制，也可以通过JDK1.2中加入的ThreadLocal来保证更好的并发性。

      1. 在Java多线程程序当中，当多个线程竞争同一个资源的时候，怎样保证不会产生相互干扰的问题；即需要是使用同步机制。一个线程一旦进入某一过程，必须等待正常的返回，并退出这一过程；下一个线程才能开始这个过程。也就是说，多线程的线程同步机制实际上是靠锁的概念来控制的，那么在Java程序中，锁时怎样体现的？

首先，从JVM的角度来看锁的概念：在Java程序运行时环境中，JVM需要对两类线程共享的数据进行协调：

       ① 保存在堆中的实例变量；     ② 保存在方法区中的类变量；

这两类数据是被所有线程共享的；( 线程不需要协调保存在Java栈当中的数据。因为这些数据是属于拥有该栈的线程所私有的)

       在Java虚拟机中，每个对象和类在逻辑上都是和一个监视器相关联的；

       对于一个对象来说，相关联的监视器保护对象的实例变量。

       对于类来说，监视器保护类的类变量。

       如果一个对象没有实例变量，或者一个类没有变量，相关联的监视器就什么也不监视。为了实现监视器的排他性监视能力，Java虚拟机为每个对象和类都关联一个锁。代表任何时候只允许一个线程拥有的特权。线程访问实例变量或类变量不需锁。

       但如果线程获取了锁，那么在它释放这个锁之前，就没有其他线程可以获取同样数据的锁了。锁住了一个对象就是获取对象相关联的监视器。

       类锁实际上用对象锁来实现。当虚拟机装载一个class文件的时候，它就会创建一个java.lang.Class类的实例。当锁住一个对象的时候，实际上锁住的是那个类的class对象。

       一个线程可以多次对同一个对象上锁。对于每一个对象，Java虚拟机维护一个加锁计数器，线程每获得一次该对象，计数器就加1，每释放一次，计数器就减1；当计数器值为0时，锁就会被完全释放了。

       Java编程人员不需要自己动手加锁，对象锁是Java虚拟机内部使用的。在Java程序中，只需要使用 synchronized 代码块或者 synchronized 方法就可以标志一个监视区域。当每次进入一个监视区域时，Java虚拟机都会自动锁上对象或者类。

      需要时刻牢记的是：当一个有限资源被多个线程共享的时候，为了保证对共享资源的互斥访问，一定要给他们排出先来后到。而要做到这一点，对象锁在这里起着非常重要的作用。

      2. 对于同步静态方法，对象锁就是该静态方法所在的类的Class实例，由于在JVM中，所有被加载的类都有唯一的类对象。

         ① 对于同步的方法或者代码块来说，必须获得对象锁才能进入同步方法或者代码块进行操作；

         ② 如果采用method级别的同步，则对象锁即就是method所在类的对象；如果是静态方法，对象锁即指method所在的Class对象(唯一);

         ③ 对于代码块，对象锁即指synchronized(obj)中的obj；

         ④ 如果是同步代码块，则对象锁需要开发人员自己指定，一般有些代码为synchronized(this)只有在单例模式才生效；

         ⑤ 如果是同步方法，则分为静态和非静态两种；静态方法则一定会同步；非静态方法需要在单例模式才会生效；推荐使用静态方法，不必担心是否单例。

 所以说，在Java多线程中，最常见的synchronized关键字实际上是依靠对象锁的机制来实现线程同步的。