情境：车站售票系统，从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<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个用户买到车票！再查看数据库中的记录：
多次执行，结果都是只有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
如果出现这种情况，就需要采取其他的方式来处理。比如 将数据库的操作通过存储过程来处理等等。