悲观锁一般用在事务中“独占的”持有一个资源，这样是为了在并发操作中保护数据一致性。悲观锁的使用非常常见，但是我们代码中对悲观锁的认识上存在不足，导致对异常的处理其实是不到位的，比如以下代码：
protected void lockInvoiceAndSet(ApInvoiceOperateContext context) {
ApInvoice invoice = apInvoiceRepository.lockByInvoiceId(context.getInvoiceId());
if (invoice == null) {
LoggerUtil.warn(logger, "锁定发票失败,", "发票id:", context.getInvoiceId());
throw new GFCenterException(GFCenterErrorCodeEnum.AP_INVOICE_LOCK_ERROR);
}
context.setOrigInvoice(invoice);
}这种代码很常见。思路无外乎是：1. 锁， 2.判， 3.决策。
1. “锁”，很直观，就是直接调用lock方法，这个方法要么是对select for update或者select for updat nowait/waitxxx的包装。
2. “判”，判什么？我觉得需要判两种可能：
· 锁失败：数据是存在于数据库中的，只是因为已经被其他资源占用无法获取独占锁。
· 锁不到：数据不存在于数据库中，select都select不到，更别说for update了。
1. “决策”，根据“判”出来的不同场景做不同的决策。根据实际需要或返回失败，或包装业务异常抛出去，或返回获取的业务资源，等等。
现在再看最初的代码有没有什么问题？我直接一点说结果，就不卖关子了。
· 问题1：没有判“锁失败”的场景。
· 问题2：对于“锁不到”的场景处理，是错误的。
为什么说没有判“锁失败”的场景？
因为这段代码根本没有搞清楚“锁失败”会发生什么，所以导致了在“锁不到”的场景中，做了“锁失败”的决策。——以为invoice == null就是“锁失败”，其实这是“锁不到”。
来看看真正锁失败的时候是什么样子：
对于“锁失败”真正的表现是会抛出CannotAcquireLockException(Springframework)，无论是尝试拿锁(select for update)失败，还是等待锁超时(select for updatenowait/wait xxx)失败，都会返回这个异常。
我们来看看Spring怎么解释这个异常的:
/**
* Exception thrown on failure to aquire a lock during an update,
* for example during a "select for update" statement.
*
* @author Rod Johnson
*/
public class CannotAcquireLockException extends PessimisticLockingFailureException {
/**
* Constructor for CannotAcquireLockException.
* @param msg the detail message
*/
public CannotAcquireLockException(String msg) {
super(msg);
}
/**
* Constructor for CannotAcquireLockException.
* @param msg the detail message
* @param cause the root cause from the data access API in use
*/
public CannotAcquireLockException(String msg, Throwable cause) {
super(msg, cause);
}
}
“当拿锁(selectfor update)失败时抛出此异常”——简单明了。
我们注意到CannotAcquireLockException继承自PessimisticLockingFailureException，中文名叫：“悲观锁失败异常”，好像很屌的样子，为啥同样是悲观锁失败，抛CannotAcquireLockException而不是PessimisticLockingFailureException呢？
来看一下代码：
/**
* Exception thrown on a pessimistic locking violation.
* Thrown by Spring's SQLException translation mechanism
* if a corresponding database error is encountered.
*
* <p>Serves as superclass for more specific exceptions, like
* CannotAcquireLockException and DeadlockLoserDataAccessException.
*
* @author Thomas Risberg
* @since 1.2
* @see CannotAcquireLockException
* @see DeadlockLoserDataAccessException
* @see OptimisticLockingFailureException
*/
public class PessimisticLockingFailureException extends ConcurrencyFailureException {
/**
* Constructor for PessimisticLockingFailureException.
* @param msg the detail message
*/
public PessimisticLockingFailureException(String msg) {
super(msg);
}
/**
* Constructor for PessimisticLockingFailureException.
* @param msg the detail message
* @param cause the root cause from the data access API in use
*/
public PessimisticLockingFailureException(String msg, Throwable cause) {
super(msg, cause);
}
}代码里发现PessimisticLockingFailureException有三个子类:
· CannotAcquireLockException
· CannotSerializeTransactionException
· DeadlockLoserDataAccessException
CannotSerializeTransactionException:这种是在串行(serialized)的事务隔离级别中，由于update竞争失败抛出来的异常（Exception thrown on failure to complete a transaction in serializedmode due to update conflicts）
DeadlockLoserDataAccessException:这种是在当前线程由于死锁失败，且事务已经被回滚的情况下抛出来的异常(Generic exception thrown when the current process was a deadlockloser, and its transaction rolled back)
所以总结下来“悲观锁失败异常”之下还有三个子类，他们分别代表着在不同的场景下悲观锁失败的异常。显然CannotAcquireLockException更加常见且通用；因为CannotSerializeTransactionException要求数据库的隔离级别要在“串行”(serialized)，这种隔离级别是数据库的最高事务隔离级别，以牺牲性能为代价完全避免了“脏读”、“幻读”和“不可重复读”，由于代价太高，实际应用场景中几乎不会选择这种。而一般较为常用的隔离级别仅仅是“读提交”(read committed)，也就是我们现在生产库中的事务隔离级别。
有点扯远了，回到原来的那段代码，看看如何完善:
/**
* 锁定发票放到上下文中
*
*a @param context AP发票处理上下文
*/
protected void lockInvoiceAndSet(ApInvoiceOperateContext context) {
ApInvoice invoice = null;
try {
invoice = apInvoiceRepository.lockByInvoiceId(context.getInvoiceId());
} catch (CannotAcquireLockException e) {
LoggerUtil.warn(logger, "锁定发票失败[并发锁失败]");
// do something else
}
if (invoice == null) {
LoggerUtil.warn(logger, "锁定发票失败[根据发票ID找不到发票], 发票id:", context.getInvoiceId());
throw new GFCenterException(GFCenterErrorCodeEnum.AP_INVOICE_LOCK_ERROR);
}
context.setOrigInvoice(invoice);
}以上代码修复了几个问题：
· 识别并处理“锁失败”
· 识别并正确处理“锁不到”
· 使用合理的日志级别，并修改了日记记录信息，表达更明确。
另外，我写完这篇总结，这里就可以大大方方的catch对应的异常，不用这么hack了:
