1.5 观察死锁

如果两个事务不得不相互等待,就将会发生一次死锁。

首先创建一个测试表:

CREATE TABLE t_deadlock (
    id int
);


INSERT INTO t_deadlock
VALUES
    (1),
    (2);
事务1事务 2
BEGIN;BEGIN;
SELECT * FROM t_deadlock WHERE id = 1 FOR UPDATE;
SELECT * FROM t_deadlock WHERE id = 2 FOR UPDATE;
SELECT * FROM t_deadlock WHERE id = 2 FOR UPDATE;
等待事务2SELECT * FROM t_deadlock WHERE id = 1 FOR UPDATE;
等待事务2等待事务1
1秒(deadlock_timeout)以后死锁解除
【注1】
COMMIT;ROLLBACK;

一旦检测到死锁,将会报错如下:

ERROR:  deadlock detected
DETAIL:  Process 6864 waits for ShareLock on transaction 669; blocked by process 6830.
Process 6830 waits for ShareLock on transaction 670; blocked by process 6864.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (0,1) in relation "t_deadlock"

PostgreSQL会告诉我们哪一行导致了冲突。在本例中,根源是元组(0, 1),这里能看到的是一个ctid,它告诉我们一行在表中的物理位置,在这里是第一块(0)中的第一行。

【注1】:如果在此处执行如下查询,可得:

SELECT 
    pid, 
    state, 
    query 
FROM 
    pg_stat_activity 
WHERE pid in (6830, 6864);

 pid  |             state             |                       query
------+-------------------------------+---------------------------------------------------
 6830 | active                        | SELECT                                           +
      |                               |     pid,                                         +
      |                               |     state,                                       +
      |                               |     query                                        +
      |                               | FROM                                             +
      |                               |     pg_stat_activity                             +
      |                               | WHERE pid in (6830, 6864);
 6864 | idle in transaction (aborted) | SELECT
      |                               |     *                                            +
      |                               | FROM                                             +
      |                               |     t_deadlock                                   +
      |                               | WHERE id = 1 FOR UPDATE;                         +
(2 rows)

如果这一行对用户的事务还可见,甚至可以查询到这一行:

SELECT
    ctid,
    *
FROM
    t_deadlock
WHERE ctid = '(0, 1)';

  ctid  | id
--------+----
 (0,1) |  1
(1 row)

如果这一行已经被删除或者修改,这个查询是不会返回该行的。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
是指两个或多个进程在互斥地请求资源的时候,由于资源被占用而无法继续执行,导致所有进程都被阻塞的情况。在Spring Boot中,可能发生在多线程并发访问共享资源时,例如数据库连接池、缓存、等。 在给出解决方案之前,我们需要先排查问题。一种常用的排查问题的方法是使用jstack命令输出线程的堆栈信息。通过查看堆栈信息,我们可以定位到可能引起的代码行,并进行解决修复。 下面是一个示例代码,模拟了一个可能导致的场景: ```java package com.xz.springboottest.day1; public class DeadLock { private static final String ACTION_ONE = "拿起碗"; private static final String ACTION_TWO = "拿起筷子"; public static void main(String[] args) { // 哲学家小明 new Thread(() -> { synchronized (ACTION_ONE) { try { Thread.sleep(1000); synchronized (ACTION_TWO) { System.out.println("小明开始吃饭了。。。。。。"); } } catch (InterruptedException e) { e.printStackTrace(); } } }).start(); // 哲学家小张 new Thread(() -> { synchronized (ACTION_TWO) { try { Thread.sleep(1000); synchronized (ACTION_ONE) { System.out.println("小张开始吃饭了。。。。。。"); } } catch (InterruptedException e) { e.printStackTrace(); } } }).start(); } } ``` 以上代码模拟了哲学家就餐的场景,当只剩下一只碗和一双筷子时,可能出现的问题。 对于解决的方法,可以考虑以下几种方案: 1. 避免循环等待:为了避免,可以规定所有线程在请求资源时按照固定的顺序获取,从而避免循环等待。 2. 加顺序:在多个线程同时请求多个资源的情况下,为了避免,可以约定线程必须按照相同的顺序请求资源。 3. 设置超时时间:在获取的时候设置超时时间,如果超过一定时间还未获取到,可以放弃或者重试。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值