并发情况下锁表问题讨论

最新推荐文章于 2021-10-09 12:24:17 发布

wbszlj

最新推荐文章于 2021-10-09 12:24:17 发布

阅读量288

点赞数

分类专栏：数据库文章标签：数据库 java

数据库专栏收录该内容

7 篇文章 0 订阅

订阅专栏

[url]http://www.yiben-tech.com[/url]

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

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

[img]http://dl.iteye.com/upload/picture/pic/135869/b8ee785a-dc37-37f6-8c73-7a14128c3a75.png[/img]

首先，假设我们不进行并发控制，按照一般的逻辑来进行处理。开启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的车票!
......

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

[img]http://dl.iteye.com/upload/picture/pic/135871/046d7c1c-7484-3b83-a21a-8b767217e827.png[/img]

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


成功购买从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的车票!
....

查看数据库中的内容：

[img]http://dl.iteye.com/upload/picture/pic/135873/815a5a78-0a27-37f8-8234-79bfac7a6381.png[/img]

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

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

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


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<Ticket> 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个用户买到车票！再查看数据库中的记录：

[img]http://dl.iteye.com/upload/picture/pic/135875/30e06b66-db9e-32d9-a9c1-bd412c39a52e.png[/img]

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

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


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

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