Java Lock最佳实践

在进行并发操作时，通常需要加锁操作来保证一致性。Java类库中提供了几种用于替代synchronized的锁，比如ReentrantLock，具体实现可能还有基于Redis等其他形式的锁，在JDK官方文档中，给出了加锁的最佳实践：

正确加锁操作

Lock l = ...;
l.lock();
try {
  // access the resource protected by this lock
} finally {
  l.unlock();
}

unlock操作放在finally无可厚非，这里主要思考为什么lock操作要在try语句之前，即为什么不能这样做：

错误加锁操作

Lock l = ...;
try {
  l.lock();
  // access the resource protected by this lock
} finally {
  l.unlock();
}

lock操作放在try之后主要有以下几点弊端：

1. lock操作可能失败，实际并未加锁。根据try-finally语句块的设定，此时将会执行unlock操作，没有加锁而尝试解锁，会导致进一步出现异常（对于ReentrantLock来说，是抛出IllegalMonitorStateException异常）。此外，新的异常覆盖加锁失败的异常，导致异常丢失，影响问题定位。
2. 根据锁的具体实现，1中的场景可能还会unlock掉其他线程加的锁，造成数据访问的不一致问题。

但是在try语句之前执行lock也存在风险，如果已经锁定，但是还没进入try语句块就发生异常，那么就没法执行finally中的解锁操作，这就要看 lock() 具体实现是否是单一职责了, 是否是仅仅只完成加锁这一单一职责, 即 lock() 若抛出任何异常都将始终保证未保持锁状态(或者已撤回锁状态), 反之, 加锁成功程序继续执行。另外为了防止这种现象的发生，lock() 操作应紧跟try语句，中间不要进行其他操作。

参考资料：

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Lock.html

https://stackoverflow.com/questions/31058681/java-locking-structure-best-pattern

https://github.com/alibaba/p3c/issues/287

《阿里巴巴Java开发手册》