并发情况下锁表问题讨论

上周五的分享，主要针对项目中遇到的一些问题进行了技术讨论，以下是关于数据库锁问题的讨论。示例代码采用了JPA。

情境：车站售票系统，从A地到B地，还剩余5张车票。有30个用户同时购票，如何通过数据库锁解决并发问题。

新建t_ticket表，存入一条记录，起始地A，目的地B，剩余车票5，数据记录如下图：

首先，假设我们不进行并发控制，按照一般的逻辑来进行处理。开启30个线程模拟用户，根据起始地、目的地查询出数据库记录，获取amount字段的值，如果大于0，则将amount字段-1，再更新到数据库。

代码如下：

ExecutorService threadPool = Executors.newFixedThreadPool(30);

for(int i = 0; i <30; i++) {

    threadPool.execute(new Runnable() {

         public void run() {

               ticketService.buyTicket("A", "B");

         }

    });

}

threadPool.shutdown();

buyTicket方法：

public void buyTicket(String origin, String destination){

Ticket ticket = ticketDao.getTicket(origin, destination);

if(ticket!=null){

int amount = ticket.getAmount();

if(amount>0){

ticketDao.updateTicketAmount(ticket.getId(), amount-1);

System.out.println("成功购买从"+origin+"到"+destination+"的车票!");

}else{

System.out.println("票已售完!");

}

}else{

System.out.println("无此班次!");

}

}

执行线程，查看输出：

成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
......

提示全部成功购买车票！这显然是不合理的！再查看数据库中记录：

再重新测试，会发现输出内容如下：

成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
票已售完!
票已售完!
票已售完!
票已售完!
.....  
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
....

查看数据库中的内容：

说明执行的结果是不确定的，这取决于每个线程执行的速度等。

从上述测试结果可以看出，在类似的并发情况下，必须对数据库进行锁处理，每个线程执行时将对应的记录锁定，防止脏读出现。

1、采用PESSIMISTIC_WRITE ，即悲观写 获取记录，修改代码：

public Ticket getTicket(String origin, String destination) {

      StringBuilder sb = new StringBuilder(" from Ticket t where t.origin = : origin and t.destination = :destination ");  

      // Query query = entityManager.createQuery(sb.toString(), Ticket.class);

      Query query = entityManager.createQuery(sb.toString(), Ticket.class).setLockMode(LockModeType.PESSIMISTIC_WRITE);

      query.setParameter("origin", origin);

      query.setParameter("destination", destination);

      List ticketList = query.getResultList();

      if(ticketList!=null && ticketList.size()>0){

         return ticketList.get(0);

      }

      return null;

}

执行结果：

成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
成功购买从A到B的车票!
票已售完!
票已售完!
票已售完!
票已售完!
......

只有5个用户买到车票！再查看数据库中的记录：

多次执行，结果都是只有5个用户能够成功购票，符合预期结果。

2、采用PESSIMISTIC_READ ，即悲观读 获取记录， 会出现如下异常：

Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

原因：悲观读机制表示 只要事务读取db，管理器就会锁定db数据，直到事务提交时才解锁，所以在进行update的会发生异常！

由此可见，在类似的并发情况下，可以采用悲观写方式来进行处理。但是这种方法同样会存在问题，如果业务比较复杂，处理时间太长，可能会出现超时异常：

Caused by: org.hibernate.exception.LockTimeoutException: could not extract ResultSet

......
Caused by: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction

如果出现这种情况，就需要采取其他的方式来处理。比如 将数据库的操作通过存储过程来处理等等。

并发情况下锁表问题讨论