锁、事务和同步看这篇就够了(1)

关于乐观锁、悲观锁、事务、synchronized，网上介绍的文章很多。但是，在实际使用中，我们经常要遇到需要组合使用这几种技术的场景。而这方面的文章却非常少，本文将着重介绍各种组合使用情况下的行为和问题。

并发下读写冲突的问题

在开发中我们经常会遇到需要对某个字段做自增操作，比如说你向银行存入一笔100元的，那么你的总金额就要增加100元。那么程序中就会使用如下代码

@Entity
@Table(name="test")
public class Test extends BaseModel{
    @Id
    @GeneratedValue(strategy= GenerationType.AUTO)
    @Column(name = "id",unique = true, nullable = false)
    private Long id;

    private Integer count;

    public Test() {
    }

    public Integer getCount() {
        return count;
    }

    public void setCount(Integer count) {
        this.count = count;
    }
}

@Transactionalpublic interface TestRepository extends BaseRepository { 
}   

@RestController
@RequestMapping(value = "/test", produces = "application/json")
public class TestController {
    @Autowired
    private TestRepository repository;

    public Test updateMoney() {
            Test test = repository.findOne(1L);
            test.setMoney(test.getMoney() + 1);
            repository.save(test);
            return test;
    }
}

这段代码并没有什么问题，事实上在大部分情况下也能正常工作。但是如果遇到高并发情况，就会发生总消费金额少了的情况。这是由于出现了以下的并发冲突情况：
假设当前总消费金额为100元

时间	线程1	线程2
T1	读取总金额，100元
T2	总金额增加100，200元
T3		读取总金额，100元
T4		总金额增加100，200元
T5	写入新的总金额，200元
T6		写入新的总金额，200元

明明执行了两次自增操作，但是金额只增加了100元。线程1的自增操作丢失了。

使用同步解决读写冲突

这个问题有很多解决方法，最简单的解决方案是在方法上增加一个同步：

    public synchronized Test updateMoney() {
            Test test = repository.findOne(1L);
            test.setMoney(test.getMoney() + 1);
            repository.save(test);
            return test;
    }

这样做的缺点也很明显：在实际代码中，一个方法可能要进行很多操作，直接对方法进行同步对性能的影响会比较大。我们可以将这个操作单独拆分成一个独立的方法，或者单独对这一段代码加同步：

public Test updateScore() {
  synchronized(this){
            Test test = repository.findOne(1L);
            test.setMoney(test.getMoney() + 1);
            repository.save(test);
            return test;
  }
}

看上去很简单，不是么？ 但是现实永远是残酷的。很多时候读取和写入并不总在一起。比如读取用户信息，之后我们要检查这个用户是否可以存取，存钱是否需要支付手续费等。总而言之，同步可以解决这个问题，但是很多时候是以降低代码性能为代价。

注意：这里说的性能损失是指代码，因为同步锁住的是代码。

既然同步锁住的是代码，那么另一个更严重的问题是出现了：分布式场景下，多个程序实例同时运行，同步就失效了。那怎么办呢？

使用数据库锁和事务解决读写冲突

锁的概念

首先需要明确一下锁的概念，本文中涉及到两个锁，一个是Java中的锁。它锁的是代码，其作用等同于synchronized。 第二种是锁数据的锁，它锁住的是数据库里的数据。它并不是数据库的一种机制，而是一种处理数据方式。当你使用hibernate来实现乐观或者悲观锁时，hibernate会自动创建一个锁的执行过程的SQL语句（类似于存储过程）

- SELECT iD, val1, val2 FROM theTable WHERE iD = @theId; 
- {code that calculates new values} 
- UPDATE theTable SET val1 = @newVal1, val2 = @newVal2 WHERE iD = @theId AND val1 = @oldVal1 AND val2 = @oldVal2; 
- {if AffectedRows == 1 } 
- {go on with your other code} 
- {else} 
- {decide what to do since it has gone bad... in your code} 
- {endif}

所以，本质上乐观锁和悲观锁依旧是一段代码，只是它们的目的是保证数据的同步。

乐观锁和悲观锁的使用

对于分布式环境，锁代码是没有用的。那么我们就必须使用乐观或者悲观锁去锁住数据库的数据。这样不管谁的程序来读取数据，都能保证数据不被其他程序篡改。

使用乐观锁
使用乐观锁，需要在数据库中指定一个字段作为版本控制字段。hibernate中提供了@Version注解用于指定某个或某几个字段用于版本控制。

我们在数据库中增加一个version字段

@Entity
@Table(name="test")
public class Test extends BaseModel{
    @Id
    @GeneratedValue(strategy= GenerationType.AUTO)
    @Column(name = "id",unique = true, nullable = false)
    private Long id;

    private Integer money;

    @Version
    private Integer version;

    public Test() {
    }

    public Integer getMoney() {
        return money;
    }

    public void setMoney(Integer money) {
        this.money = money;
    }

    public Integer getVersion() {
        return version;
    }

    public void setVersion(Integer version) {
        this.version = version;
    }
}

并且在controller中增加@Transactional

@RestController
@RequestMapping(value = "/test", produces = "application/json")
public class TestController {
    @Autowired
    private TestRepository repository;

    @Transactional
    public Test updateMoney() {
            Test test = repository.findOne(1L);
            test.setMoney(test.getMoney() + 1);
            repository.save(test);
            return test;
    }
}

这样乐观锁就被激活了，从读取数据开始到事务结束的代码都会在乐观锁的控制之中。特别要在注意的是，这里必须为方法加上@Transactional事务。否则乐观锁不会生效。

关于乐观锁的原理和执行过程，网上有很多资料就不再赘述了。当读写数据发生冲突时，乐观锁检测到版本冲突，会抛出异常

2016-12-29 14:29:06.806 ERROR 56302 --- [io-8089-exec-11] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.orm.ObjectOptimisticLockingFailureException: Object of class [com.baojinsuo.springboot.test.Test] with identifier [1]: optimistic locking failed; nested exception is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : [com.baojinsuo.springboot.test.Test#1]] with root cause

通过捕获异常，我们可以让程序再次尝试修改数据，或者直接抛出给用户。乐观锁性能较好，因为它并不是真正的锁住数据，而只是检测冲突，一旦发生冲突就会告知用户。如果程序并不经常遇到并发读写冲突，可以使用乐观锁提高性能。

使用悲观锁
如果希望经常发生读写冲突，又希望修改提交成功概率更高，那么可以使用悲观锁。悲观锁是真正的锁住数据。在释放之前，是不允许其他程序访问的。

要使用悲观锁，我们需要新增一个方法

@Transactional
public interface TestRepository extends BaseRepository {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select cb from Test as cb where cb.id = :id")
    Test findOneWithLock(@Param("id") Long id);
}

使用悲观锁，除非发生死锁，一般情况不会抛出异常。使用上较简便，但是性能没有乐观锁那么好，特别是在不经常发生读写冲突的情况下。

本篇介绍了锁、事务和同步的基本用法，后面会着重介绍在更复杂的代码环境中的使用。