有时您根本无法避免：通过SQL进行悲观锁定。 实际上，当您要在共享的全局锁上同步多个应用程序时，它是一个很棒的工具。
有些人可能认为这是在滥用数据库。 如果可以解决您遇到的问题，我们认为可以使用您拥有的工具。 例如， RDBMS可能是消息队列的完美实现 。
假设您确实有悲观的锁定用例，并且您确实想选择RDBMS。 现在，如何正确处理？ 因为产生死锁真的很容易。 想象一下以下设置（我正在为此使用Oracle）：
CREATE TABLE locks (v NUMBER(18));
INSERT INTO locks
SELECT level
FROM dual
CONNECT BY level <= 10;这将生成10条记录，我们将其用作10个不同的行级锁。
现在，让我们从两个sqlplus客户端连接到数据库：
实例1
SQL> SELECT *
2 FROM locks
3 WHERE v = 1
4 FOR UPDATE;
V
----------
1实例2
SQL> SELECT *
2 FROM locks
3 WHERE v = 2
4 FOR UPDATE;
V
----------
2现在，我们已经从两个不同的会话中获得了两个不同的锁。
然后，让我们反过来：
实例1
SQL> SELECT *
2 FROM locks
3 WHERE v = 2
4 FOR UPDATE;实例2
SQL> SELECT *
2 FROM locks
3 WHERE v = 1
4 FOR UPDATE;现在这两个会话都被锁定，幸运的是，Oracle将检测到这并使其中一个会话失败：
ORA-00060: deadlock detected while waiting for resource避免死锁
这是一个非常明确的示例，在此示例中，很容易看到它发生的原因以及潜在的避免方法。 避免死锁的一种简单方法是建立一条规则，即始终必须按升序获取所有锁。 如果您知道需要1号和2号锁，则必须按顺序购买它们。 这样，您仍然会产生锁定并因此产生争用，但是一旦负载减少，至少争用将最终（可能）得到解决。 这是一个示例，显示了当您有更多客户时会发生什么。 这次，编写为Java线程。
在示例中，我们将jOOλ用于更简单的lambda表达式（例如lambdas抛出检查的异常）。 当然，我们将大量滥用Java 8！
Class.forName("oracle.jdbc.OracleDriver");
// We want a collection of 4 threads and their
// associated execution counters
List<Tuple2<Thread, AtomicLong>> list =
IntStream
.range(0, 4)
// Let's use jOOλ here to wrap checked exceptions
// we'll map the thread index to the actual tuple
.mapToObj(Unchecked.intFunction(i -> {
final Connection con = DriverManager.getConnection(
"jdbc:oracle:thin:@localhost:1521:xe",
"TEST", "TEST");
final AtomicLong counter = new AtomicLong();
final Random rnd = new Random();
return Tuple.tuple(
// Each thread acquires a random number of
// locks in ascending order
new Thread(Unchecked.runnable(() -> {
for (;;) {
String sql =
" SELECT *"
+ " FROM locks"
+ " WHERE v BETWEEN ? AND ?"
+ " ORDER BY v"
+ " FOR UPDATE";
try (PreparedStatement stmt =
con.prepareStatement(sql)) {
stmt.setInt(1, rnd.nextInt(10));
stmt.setInt(2, rnd.nextInt(10));
stmt.executeUpdate();
counter.incrementAndGet();
con.commit();
}
}
})),
counter
);
}))
.collect(Collectors.toList());
// Starting each thread
list.forEach(tuple -> tuple.v1.start());
// Printing execution counts
for (;;) {
list.forEach(tuple -> {
System.out.print(String.format(
"%1s:%2$-10s",
tuple.v1.getName(),
tuple.v2.get()
));
});
System.out.println();
Thread.sleep(1000);
}在程序运行时，您可以看到它逐渐地继续运行，每个线程承担与其他线程大致相同的负载：
Thread-1:0 Thread-2:0 Thread-3:0 Thread-4:0
Thread-1:941 Thread-2:966 Thread-3:978 Thread-4:979
Thread-1:2215 Thread-2:2206 Thread-3:2244 Thread-4:2253
Thread-1:3422 Thread-2:3400 Thread-3:3466 Thread-4:3418
Thread-1:4756 Thread-2:4720 Thread-3:4855 Thread-4:4847
Thread-1:6095 Thread-2:5987 Thread-3:6250 Thread-4:6173
Thread-1:7537 Thread-2:7377 Thread-3:7644 Thread-4:7503
Thread-1:9122 Thread-2:8884 Thread-3:9176 Thread-4:9155 现在，为了论证，让我们来做禁忌和ORDER BY DBMS_RANDOM.VALUE
String sql =
" SELECT *"
+ " FROM locks"
+ " WHERE v BETWEEN ? AND ?"
+ " ORDER BY DBMS_RANDOM.VALUE"
+ " FOR UPDATE";用不了多长时间，您的应用程序就会爆炸：
Thread-1:0 Thread-2:0 Thread-3:0 Thread-4:0
Thread-1:72 Thread-2:79 Thread-3:79 Thread-4:90
Thread-1:72 Thread-2:79 Thread-3:79 Thread-4:90
Thread-1:72 Thread-2:79 Thread-3:79 Thread-4:90
Exception in thread "Thread-3" org.jooq.lambda.UncheckedException:
java.sql.SQLException: ORA-00060: deadlock detected while waiting for resource
Thread-1:72 Thread-2:79 Thread-3:79 Thread-4:93
Thread-1:72 Thread-2:79 Thread-3:79 Thread-4:93
Thread-1:72 Thread-2:79 Thread-3:79 Thread-4:93
Exception in thread "Thread-1" org.jooq.lambda.UncheckedException:
java.sql.SQLException: ORA-00060: deadlock detected while waiting for resource
Thread-1:72 Thread-2:1268 Thread-3:79 Thread-4:1330
Thread-1:72 Thread-2:3332 Thread-3:79 Thread-4:3455
Thread-1:72 Thread-2:5691 Thread-3:79 Thread-4:5841
Thread-1:72 Thread-2:8663 Thread-3:79 Thread-4:8811
Thread-1:72 Thread-2:11307 Thread-3:79 Thread-4:11426
Thread-1:72 Thread-2:12231 Thread-3:79 Thread-4:12348
Thread-1:72 Thread-2:12231 Thread-3:79 Thread-4:12348
Thread-1:72 Thread-2:12231 Thread-3:79 Thread-4:12348
Exception in thread "Thread-4" org.jooq.lambda.UncheckedException:
java.sql.SQLException: ORA-00060: deadlock detected while waiting for resource
Thread-1:72 Thread-2:13888 Thread-3:79 Thread-4:12348
Thread-1:72 Thread-2:17037 Thread-3:79 Thread-4:12348
Thread-1:72 Thread-2:20234 Thread-3:79 Thread-4:12348
Thread-1:72 Thread-2:23495 Thread-3:79 Thread-4:12348最后，由于死锁异常，除一个线程外，所有线程都被杀死了（至少在我们的示例中）。
不过要当心竞争
在显示悲观锁定（或一般来说锁定）的其他负面影响方面，上述示例也令人印象深刻：争用。 在“不良示例”中继续执行的单个线程几乎与之前的四个线程一样快。 我们使用随机锁定范围的愚蠢示例导致这样一个事实，即平均而言，几乎每次获取锁定的尝试至少都会产生一些阻塞 。 您如何解决这个问题？ 通过查找enq：TX –您会话中的行锁争用事件。 例如：
SELECT blocking_session, event
FROM v$session
WHERE username = 'TEST'上面的查询返回灾难性的结果，在这里：
BLOCKING_SESSION EVENT
-------------------------------------
48 enq: TX - row lock contention
54 enq: TX - row lock contention
11 enq: TX - row lock contention
11 enq: TX - row lock contention结论
结论只能是：谨慎使用悲观锁定，并始终期待意外发生 。 在进行悲观锁定时，死锁和大量争用都是您可能遇到的问题。 作为一般经验法则，请遵循以下规则（按顺序）：
- 如果可以，请避免悲观锁定
- 如果可以，请避免每个会话锁定多于一行
- 如果可以，请避免以随机顺序锁定行
- 避免去上班看看发生了什么
429
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
