故障解析丨一次死锁问题的解决

MySQL报错「Deadlock found when trying to get lock」:事务隔离级别与锁等待超时的调优 核心治理原则分层防护:在应用层、数据库层、网络层实现多级死锁预防动态调优:基于监控数据动态调整隔离级别与超时时间灰度发布:新功能上线前在小流量环境验证锁行为。 阅读详情

背景

业务端遇到报错为"Deadlock found when trying to get lock; try restarting transaction"则表明有死锁发生

名称配置
数据库版本GreatSQL 8.0.26
隔离级别Read-Commited

innodb status 日志

greatsql> show engine innodb status\G
*************************** 1. row ***************************
  Type: InnoDB
  Name: 
Status: 
=====================================
2024-01-28 16:55:38 140737023727360 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 14 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 41 srv_active, 0 srv_shutdown, 17830 srv_idle
srv_master_thread log flush and writes: 0
----------
SEMAPHORES
----------
-------------
RW-LATCH INFO
-------------
Total number of rw-locks 132361
OS WAIT ARRAY INFO: reservation count 11180
OS WAIT ARRAY INFO: signal count 11177
RW-shared spins 0, rounds 0, OS waits 0
RW-excl spins 0, rounds 0, OS waits 0
RW-sx spins 0, rounds 0, OS waits 0
Spin rounds per wait: 0.00 RW-shared, 0.00 RW-excl, 0.00 RW-sx
------------------------
LATEST DETECTED DEADLOCK
------------------------
2024-01-28 16:53:40 140735053358848
*** (1) TRANSACTION:
TRANSACTION 37616, ACTIVE 8 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1192, 1 row lock(s), undo log entries 1
MySQL thread id 16, OS thread handle 140737023432448, query id 652 127.0.0.1 root update
insert into info values (50,11)

*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 26 page no 5 n bits 80 index uk_name of table `apple`.`info` trx id 37616 lock mode S waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 8000000b; asc     ;;
 1: len 4; hex 80000028; asc    (;;


*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 26 page no 5 n bits 80 index uk_name of table `apple`.`info` trx id 37616 lock mode S waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 8000000b; asc     ;;
 1: len 4; hex 80000028; asc    (;;


*** (2) TRANSACTION:
TRANSACTION 37615, ACTIVE 24 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1192, 2 row lock(s), undo log entries 2
MySQL thread id 15, OS thread handle 140737024022272, query id 653 127.0.0.1 root update
insert into info values (60,8)

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 26 page no 5 n bits 80 index uk_name of table `apple`.`info` trx id 37615 lock_mode X locks rec but not gap
Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 8000000b; asc     ;;
 1: len 4; hex 80000028; asc    (;;


*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 26 page no 5 n bits 80 index uk_name of table `apple`.`info` trx id 37615 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 8000000b; asc     ;;
 1: len 4; hex 80000028; asc    (;;

*** WE ROLL BACK TRANSACTION (1)
------------
TRANSACTIONS
------------

查看表结构

greatsql> show create table info \G
*************************** 1. row ***************************
       Table: info
Create Table: CREATE TABLE `info` (
  `id` int NOT NULL AUTO_INCREMENT,
  `name` int NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=61 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.01 sec)

梳理 innodb status 日志

  • 整理如下:
事务T1T2
操作insert into info values (50,11)insert into info values (60,8)
关联的对象表apple.info的唯一索引 uk_name表apple.info的唯一索引 uk_name
持有的锁lock mode S waitingheap no 7 11,40(十六进制为8,28)lock_mode X locks rec but not gapheap no 7 11,40(十六进制为8,28)
等待的锁lock mode S waitingheap no 7 11,40(十六进制为8,28)lock_mode X locks gap before rec insert intention waitingheap no 7 11,40(十六进制为8,28)
  • 首先事务T2获取到了uk_name中记录11的 lock x,rec not not gap 锁

  • 事务T1尝试获取uk_name中记录11的lock s, next key lock,由于T2持有了记录的独占锁,因此被T1堵塞

  • 事务T2尝试获取uk_name中记录11的lock x, gap before rec,insert intention,但被堵塞

获取业务历史SQL语句

通过系统表方式

通过performance_schema.threads、performance_schema.events_statements_history、performance_schema.events_statements_history_long等系统表获取历史SQL

  • 根据GreatSQL thread id获得线程id
greatsql> select PROCESSLIST_ID,THREAD_ID,THREAD_OS_ID from  performance_schema.threads where processlist_id in (15,16);
+----------------+-----------+--------------+
| PROCESSLIST_ID | THREAD_ID | THREAD_OS_ID |
+----------------+-----------+--------------+
|             15 |        61 |         5714 |
|             16 |        62 |         5719 |
+----------------+-----------+--------------+
2 rows in set (0.00 sec)
  • 根据线程id获得线程历史SQL
greatsql> select THREAD_ID,EVENT_ID,CURRENT_SCHEMA,SQL_TEXT,MESSAGE_TEXT,EVENT_NAME,SOURCE from performance_schema.events_statements_history where thread_id in (61,62) order by THREAD_ID,EVENT_ID;
+-----------+----------+----------------+---------------------------------+--------------------------------------------------------------------+--------------------------+---------------------------------+
| THREAD_ID | EVENT_ID | CURRENT_SCHEMA | SQL_TEXT                        | MESSAGE_TEXT                                                       | EVENT_NAME               | SOURCE                          |
+-----------+----------+----------------+---------------------------------+--------------------------------------------------------------------+--------------------------+---------------------------------+
|        61 |     3762 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        61 |     3807 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        61 |     3852 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        61 |     3897 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        61 |     3942 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        61 |     3987 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        61 |     4032 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        61 |     4077 | apple          | begin                           | NULL                                                               | statement/sql/begin      | init_net_server_extension.cc:94 |
|        61 |     4100 | apple          | insert into info values (40,11) | NULL                                                               | statement/sql/insert     | init_net_server_extension.cc:94 |
|        61 |     4569 | apple          | insert into info values (60,8)  | NULL                                                               | statement/sql/insert     | init_net_server_extension.cc:94 |
|        62 |     3215 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        62 |     3260 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        62 |     3305 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        62 |     3350 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        62 |     3395 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        62 |     3440 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        62 |     3485 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        62 |     3530 | apple          | NULL                            | NULL                                                               | statement/com/Field List | init_net_server_extension.cc:94 |
|        62 |     3575 | apple          | begin                           | NULL                                                               | statement/sql/begin      | init_net_server_extension.cc:94 |
|        62 |     3598 | apple          | insert into info values (50,11) | Deadlock found when trying to get lock; try restarting transaction | statement/sql/insert     | init_net_server_extension.cc:94 |
+-----------+----------+----------------+---------------------------------+--------------------------------------------------------------------+--------------------------+---------------------------------+
20 rows in set (0.00 sec)
  • 观察show engine innodb status中的GreatSQL thread id 16和GreatSQL thread id 15

  • 通过performance_schema.threads获取THREAD_ID

  • 通过performance_schema.events_statements_history获取THREAD_ID执行的历史SQL以及执行时间

最终可复现出如下业务SQL:

事务T1T2
语句begin;begin;
语句insert into info values (40,11);
语句insert into info values (50,11);
语句insert into info values (60,8);

通过解析binlog

$ mysqlbinlog -vv --base64-output=decode-rows bin.000030

SET @@SESSION.GTID_NEXT= 'e319a624-b2ce-11ee-9aac-00163e62ca8a:8696'/*!*/;
# at 10314
#240128 16:52:35 server id 1024  end_log_pos 10390 CRC32 0x59edb313         Query        thread_id=18        exec_time=0        error_code=0
SET TIMESTAMP=1706431955/*!*/;
BEGIN
/*!*/;
# at 10390
#240128 16:52:35 server id 1024  end_log_pos 10442 CRC32 0xc03dea61         Table_map: `apple`.`info` mapped to number 370
# at 10442
#240128 16:52:35 server id 1024  end_log_pos 10486 CRC32 0x670e0c66         Write_rows: table id 370 flags: STMT_END_F
### INSERT INTO `apple`.`info`
### SET
###   @1=30 /* INT meta=0 nullable=0 is_null=0 */
###   @2=30 /* INT meta=0 nullable=0 is_null=0 */
# at 10486
#240128 16:52:35 server id 1024  end_log_pos 10517 CRC32 0xab4e0d89         Xid = 598
COMMIT/*!*/;
# at 10517
#240128 19:22:12 server id 1024  end_log_pos 10596 CRC32 0x4f4cf08e         GTID        last_committed=30        sequence_number=36        rbr_only=yes        original_committed_timestamp=1706440932450590        immediate_commit_timestamp=1706440932450590 transaction_length=378
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1706440932450590 (2024-01-28 19:22:12.450590 CST)
# immediate_commit_timestamp=1706440932450590 (2024-01-28 19:22:12.450590 CST)
/*!80001 SET @@session.original_commit_timestamp=1706440932450590*//*!*/;
/*!80014 SET @@session.original_server_version=80026*//*!*/;
/*!80014 SET @@session.immediate_server_version=80026*//*!*/;
SET @@SESSION.GTID_NEXT= 'e319a624-b2ce-11ee-9aac-00163e62ca8a:8697'/*!*/;
# at 10596
#240128 16:53:16 server id 1024  end_log_pos 10672 CRC32 0xf222c003         Query        thread_id=15        exec_time=0        error_code=0
SET TIMESTAMP=1706431996/*!*/;
BEGIN
/*!*/;
# at 10672
#240128 16:53:16 server id 1024  end_log_pos 10724 CRC32 0x20cb8c86         Table_map: `apple`.`info` mapped to number 370
# at 10724
#240128 16:53:16 server id 1024  end_log_pos 10768 CRC32 0xd8f53958         Write_rows: table id 370 flags: STMT_END_F
### INSERT INTO `apple`.`info`
### SET
###   @1=40 /* INT meta=0 nullable=0 is_null=0 */
###   @2=11 /* INT meta=0 nullable=0 is_null=0 */
# at 10768
#240128 16:53:40 server id 1024  end_log_pos 10820 CRC32 0x23f22580         Table_map: `apple`.`info` mapped to number 370
# at 10820
#240128 16:53:40 server id 1024  end_log_pos 10864 CRC32 0x182ecdef         Write_rows: table id 370 flags: STMT_END_F
### INSERT INTO `apple`.`info`
### SET
###   @1=60 /* INT meta=0 nullable=0 is_null=0 */
###   @2=8 /* INT meta=0 nullable=0 is_null=0 */
# at 10864
#240128 19:22:12 server id 1024  end_log_pos 10895 CRC32 0x57fd1d3c         Xid = 650
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

根据binlog中部分SET @@SESSION.GTID_NEXT= 'e319a624-b2ce-11ee-9aac-00163e62ca8a:8697'该GTID的事务信息,可恢复T2,但T1执行的语句由于被回滚了,则不会记录到binlog,可开启general log日志获取排查

事务T1T2
语句begin;begin;
语句insert into info values (40,11);
语句insert into info values (50,11);
语句insert into info values (60,8);

分析死锁

  • T1、T2开启了一个事务

  • 随后T2执行了插入(40,11)的insert语句:insert into info values (40,11)

  • T1执行了插入(50,11)的insert语句:insert into info values (50,11) 进行唯一性冲突检查,尝试获取LOCK_S

  • 然后T1所在的连接会将T2中的隐式锁转换为显示锁,此时T2将获取Lock X, Rec_not_gap。由于T2的Lock X, Rec_not_gap与T1的LOCK S不兼容,因此T1被堵塞

  • 随后,T2又执行了(60,8)的insert语句:insert into info values (60,8) 由于其插入的唯一索引值是8,因此不存在主键冲突,直接执行乐观插入操作。执行乐观插入时,需要检查其它事务是否堵塞insert操作。其核心是获取待插入记录的下一个值(这里刚好是10),并获取该记录上的所有锁,与需要添加的锁判断是否存在冲突。

  • T1持有了记录11的LOCK_S锁与T2的LOCK_X、LOCK_INSERT_INTENTION不兼容,因此T2被T1堵塞

  • 死锁形成。

解决

• 适当的减少Unique索引

• 避免插入重复的值(唯一索引所在列)

Enjoy GreatSQL :)

关于 GreatSQL

GreatSQL是适用于金融级应用的国内自主开源数据库,具备高性能、高可靠、高易用性、高安全等多个核心特性,可以作为MySQL或Percona Server的可选替换,用于线上生产环境,且完全免费并兼容MySQL或Percona Server。

相关链接: GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区:

image

社区有奖建议反馈: https://greatsql.cn/thread-54-1-1.html

社区博客有奖征稿详情: https://greatsql.cn/thread-100-1-1.html

(对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~)

技术交流群:

微信&QQ群:

QQ群:533341697

微信群:添加GreatSQL社区助手(微信号:wanlidbc )好友,待社区助手拉您进群。

Deadlock found when trying to get lock(死锁)问题解决 今天压测用户中心的登录接口。发现这个接口在并发下几乎不可用,错误率70%。 查看后台日志全是: 登录接口出现死锁了。 看了下代码,登录中做了更新用户登录时间,插入用户log。查询数据库,发行用户更新和插入log都会lock wait 判断可能是在压测同一个用户登录时,某个请求中的事务读取到了另一个请求里事务未提交的数据。从而需要等待之前的事务提交。(幻读) 然后将事务隔离机制改成... 阅读详情

相关推荐

线程死锁报错Deadlock found when trying to get lock

在Java多线程编程中,线程死锁是一个常见问题,通常发生在多个线程互相等待对方释放锁时,导致系统抛出Deadlock found when trying to get lock错误。死锁的四个必要条件包括互斥条件、请求与保持条件、不可剥夺条件和循环等待条件。为了检测死锁,可以使用工具如jstack、VisualVM和JProfiler。解决死锁的方法包括避免嵌套锁、使用锁超时机制、利用高级并发工具(如ConcurrentHashMap和StampedLock)以及实施死锁检测与恢复策略。通过合理选择和应用这

shejizuopin的博客 1081

Mysql报Deadlock found when trying to get lock; try restarting transaction问题解决

mysql deadLock

a1k2l45k的博客 5万+

提示系统死锁问题?架构师教你分析和解决方法

结合多年的实战经验,我总结了以下死锁避免的最佳实践死锁的本质是多进程/线程对有限资源的竞争,当竞争达到一定程度(满足四个必要条件)时,就会发生死锁。解决死锁的核心是平衡资源利用率和系统安全性如果你需要高安全性(如医疗系统、金融系统),可以选择死锁预防(如统一锁顺序);如果你需要高资源利用率(如互联网系统、分布式系统),可以选择死锁避免(如银行家算法)或死锁检测与恢复(如数据库的自动死锁处理)。作为架构师,我们需要根据系统场景选择合适的死锁解决策略,并通过最佳实践。

项目管理的博客 957

【一次线上 MySQL 死锁问题的完整复盘与解析】

MySQL死锁问题分析及解决方案 本文详细分析了电商订单系统中出现的INSERT死锁问题。通过排查死锁日志发现,两个并发事务在向order_items表插入数据时,因同时等待对方释放idx_order_id索引上的间隙锁而导致死锁。深入分析表明,在RR隔离级别下,INSERT操作会触发间隙锁和插入意向锁的组合,当多个事务交叉请求这些锁时可能形成环形等待。文章提出了四种解决方案:1)实现事务自动重试机制;2)谨慎降低隔离级别;3)优化索引设计;4)采用批量插入和顺序提交策略。最后强调理解InnoDB锁机制和学

gjc592的博客 1731

面试常见运维故障排除问题总结

进程导致CPU爆满 首先 sar(top,ps等查看负载命令) 查看状态得到 pid 然后 lsof 查看打开的文件。 去文件中查看参数是否变动, 查看是否有死循环导致 程序中存在过度耗时且不可能完成的操作 或者是存在版本不兼容的问题 然后修改参数,改脚本或者去kill 掉进程 kill进程仍然开启 有两个原因 1.父进程不断fork 2.crontab 中有相应的配置。 所以关闭父进程或者更改crontab 访问的地址不是自己想要的地址 本地hosts文件错误 访问被劫持 访问网站速度过慢 1.检查本

thermal_life的博客 4478

MySQL 故障排查:从 `SHOW PROCESSLIST` 到死锁检测的完整流程

基础排查:通过 SHOW PROCESSLIST 快速识别慢查询、锁等待等异常会话状态,结合 information_schema.innodb_locks 分析阻塞源头。 锁机制解析:深入理解InnoDB行锁(S/X锁)、间隙锁等机制,利用 SHOW ENGINE INNODB STATUS 和错误日志捕获死锁详情,优化事务加锁顺序与索引设计。 查询优化:启用慢查询日志,结合 EXPLAIN 分析执行计划,避免全表扫描,缩短事务时间。

专栏 800

java 死锁 解决_Java死锁故障排除和解决

java 死锁 解决 JavaOne年度会议的一大优点是主题专家介绍了几个技术和故障排除实验室。 这些实验室之一尤其引起了我的关注:Java冠军Heinz Kabutz提出的“ HOL6500-查找和解决Java死锁 ”。 这是我在该主题上看到的最好的演示之一。 我建议您自己下载,运行和研究实验室。 本文将重温这个经典的线程问题,并总结提出的关键故障排除和解决方法。 我还将根据自己的多线程...

最佳 Java 编程 877

嵌入式中I2C 相关的硬件问题汇总及死锁解决办法

MCU 在开始信号后发送地址,得到从机设备响应,准备开始返回数据,在这个时候,从机将 SDA 信号拉为低电平,如果 MCU 异常复位,会导致总线上 SCL 停止发送时钟信号,从机等待 MCU 的时钟信号,产生钳住并且拉低 SDA 的现象。如果想要解锁 SDA,从机需要 9 个时钟信号,使得从机完成响应,释放 SDA。具体原因是从机设备在回数据,还没有发送完成,主机时钟消失,从机等待时钟信号, MCU重启,如果从机设备的电源没有复位,从机继续等待 MCU 时钟信号,数据一直被钳住,总线无法完成数据交互。

嵌入式技术开发 1866

深入理解MySQL8中死锁及线上故障解决

深入理解MySQL8中死锁及线上故障解决 一、什么是死锁 死锁是指两个或两个以上的事务在执行过程中,因争夺锁资源而造成的一种互相等待的现象。 若无外力作用,事务都将无法推进下去。 解决死锁问题最简单的方式是不要有等待, 将任何的等待都转化为回滚,并且事务重新开始。毫无疑问,这的确可以避免死锁问题的产生。 然而在线上环境中,这可能导致并发性能的下降,甚至任何一个事务都不能进行。 而这所带来的问题远比...

瘦子没有夏天 3351

Keil开发中CMSIS Driver API缺失问题的排查与解决

本文详细解析Keil开发中CMSIS Driver API缺失问题的根源与解决方案。针对版本不匹配、安装不完整等常见原因,提供在线与离线安装的对比及详细排查步骤,重点涵盖版本兼容性分析与项目配置验证,帮助开发者彻底解决API缺失错误并预防问题复发。

rust6ferris的博客 550

Delta并联机构运动学正逆解:从理论建模到Matlab实战

本文深入解析了Delta并联机构运动学正逆解的核心原理与实战方法。通过几何建模,清晰阐述了其“逆解简单、正解复杂”的特性,并详细推导了基于一元二次方程的逆解解析算法与采用牛顿-拉弗森迭代法的正解数值算法。文章结合完整的Matlab代码实例,从符号推导到数值求解,提供了从理论到实践的完整实现路径,助力机器人开发者掌握Delta并联机构的运动学分析。

weixin_29096377的博客 433

GaussDB运维问题解决:线程阻塞导致事务死锁

GaussDB数据库出现事务死锁问题,排查因Ustore存储引擎TD槽位竞争。调整init_td参数 值后问题解决。

Xiaoyi_CES的博客 1560

Windows下的Geant4安装教程

本教程将从0开始展示在Windows下如何安装Geant4,包括各种辅助工具(QT、Cmake、Visual Studio)的下载安装,环境变量的配置,以及example的生成等。

weixin_49065278的博客 4107

生产故障解决之Mysql数据库死锁

生产故障解决之Mysql数据库死锁

weigeshikebi的博客 453

浪涌电流测试仪的工作原理

浪涌电流脉冲形成的开始由同步电路 13 确定,该同步电路 13 发送命令以打开和第二开关 10 和 11,向发生器 14 发送控制命令以生成被测半导体器件 5 的控制信号和参考信号整形器 9 的触发脉冲。电流源的功率输出并联连接,以对流经被测半导体样品的电流求和。此外,使用数字控制扩展了测试仪的功能,能够产生各种形状的电流脉冲,例如梯形电流脉冲,以估计被测晶闸管的导通状态扩展时间。由于晶体管3的栅极是连接的,并且平衡电阻4包含在晶体管3的源中,因此通过每个晶体管3的电流脉冲大致相同,并重复参考信号的形状。

Jesse0257的博客 1256

VOF模型求解方法:从SIMPLEC到PISO的稳定性优化策略

本文深入探讨了VOF模型求解方法中SIMPLEC与PISO算法的稳定性优化策略,重点分析了两种算法在稳态和瞬态问题中的应用差异。通过对比PRESTO离散化方法与其他格式的优劣,提供了针对多相流模拟的实用设置建议和稳定性优化技巧,帮助工程师有效提升计算效率和精度。

yellow的专栏 1153

深入解析 Linux 死锁:原理、检测与解决方案

死锁是指两个或多个进程 / 线程因循环等待对方持有的资源而陷入永久阻塞的状态。必要条件核心机制Linux 系统实例互斥条件资源具有独占性,同一时间仅允许一个进程使用内核自旋锁(spinlock)在中断上下文的独占访问;文件系统写锁阻塞其他进程写操作持有并等待条件进程持有部分资源,同时等待其他资源线程 A 持有 mutex1 并申请 mutex2,线程 B 持有 mutex2 并申请 mutex1(ABBA 死锁)不可剥夺条件资源只能由持有者主动释放,不可强制剥夺。

zqmgx13291的博客 1280

Far planner 代码系列(14)

MatchContourWithNavGraph(3) this->EnclosePolygonsCheck(); //可能有些ctnode的is_contour_necessary属性变成了true // 这说明我的contour_graph是一个local层级的 才会从这里面 get new vertices new_convex_vertices.clear(); //! 把contour_graph_里符

博客 899

分布式锁,redisson是如何解决死锁问题

使用redis做分布式锁时大家可能都知道使用setnx容易发生死锁情况,大多数都会推荐使用redission来实现,那么redission是如何解决死锁问题的呢? 有关Redisson作为实现分布式锁,总的分3大模块来讲。 1. `1、Redisson实现分布式锁原理` 2. `2、Redisson实现分布式锁的源码解析` 3. `3、Redisson实现分布式锁的项目代码(可以用于实际项目中)` 一、高效分布式锁 当我们在设计分布式锁的时候,我们应该考虑分布式锁至少要满

luokn1995的博客 1万+

Python 爬虫实战:亚马逊商品评论 + 评分抓取(情感分析数据预处理)

在电子商务领域,用户评论是了解产品口碑和市场反馈的重要渠道。亚马逊作为全球领先的电商平台,拥有海量的商品评论数据。本文将详细介绍如何使用 Python 编写爬虫程序,从亚马逊网站抓取商品评论和评分数据,并进行情感分析的数据预处理。

yansideyucsdn的博客 769

4.2 多智能体系统的严格隔离机制:防止上下文污染与隐私数据脱敏实战

本文探讨了多智能体系统中上下文信息共享带来的安全风险与解决方案。研究发现,随着Agent数量增加,上下文信息泄露概率呈指数级上升,可能导致跨Agent错误传播、隐私泄露等问题。文章提出分层隔离架构,将上下文划分为全局共享和本地私有两部分,并通过命名空间隔离、递归压缩和隐私过滤技术确保数据安全。技术实现上,建议为每个子Agent创建独立状态空间,采用原子化更新和读写锁控制避免状态竞争。隐私保护方面,结合正则匹配和命名实体识别技术进行敏感数据过滤,确保符合GDPR等法规要求。这些措施共同构建了可靠、安全且合规的

公众号:AI前沿侦探 225

20.线程的活性故障:死锁

目录1.定义2.死锁产生的条件3.规避死锁的方法4.死锁的恢复 1.定义 死锁是线程的一种常见活性故障。如果两个或者更多的线程因相互等待对方而被永远暂停(线程的生命周期状态为 BLOCKED 或者 WAITING), 那么我们就称这些线程产生了死锁(Deadlock)。 由于产生死锁的线程的生命周期状态永远是非运行状态,因此这些线程所要执行的任务也永远无法进展。死锁产生的一种典型情形如下图。 2...

一枝会思想的芦苇的博客 331

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

MySQL 故障案例分析:从死锁到数据丢失的全面诊断指南

MySQL故障诊断与处理指南 本文系统分析了MySQL生产环境中的常见故障类型,重点探讨了死锁故障的排查与解决方案。 主要内容 MySQL故障全景分析: 性能故障(死锁阻塞、主从延迟等) 可用性故障(实例宕机、资源耗尽等) 数据故障(数据丢失、不一致等) 提供了故障严重程度评估矩阵 死锁案例深度解析: 通过电商订单系统案例还原死锁发生场景 详细分析死锁日志和诊断过程 提供多种解决方案: 应急处理(终止阻塞事务) 根本解决(统一操作顺序、减小事务粒度) 应用层优化(重试机制) 实用工具: 关键监控命令(SHO

qq_43414012的博客 1114

ET2012新版免狗免安装绿色软件

ET2012新版免狗免安祖昂绿色软件。,新界面,新视觉,

ssm框架搭建

这个是一个在idea上成功跑起来的ssm框架项目,保存在这里方便以后使用直接下载

Java面试题(二十二) 手写死锁+死锁故障定位排查

一. 手写死锁 1.死锁的定义: 死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象, 若无外力干涉那他们都将无法推进下去,如果系统资源充足,进程的资源请求都能够得到满足, 死锁出现的可能性就很低,否则就会因争夺有限的资源而陷入死锁。 通俗的讲:就是吃着碗里的,看着锅里的。 2.死锁产生的原因: 1.系统资源不足 2.进程运行推进的顺序不合适 3.资源分配不当 3.死锁产生原因图解: 4.代码模拟死锁: //资源类 class HoldLockThread impleme

w_x_A__l__l的博客 522

OV9734 DATASHEET,完整规格书

OV9734完整规格书,包括电气参数,尺寸规格,寄存器配置表等

SQL Server故障排查与解决方案全解析

本文系统介绍了SQL Server常见故障类型、排查工具及解决方案,帮助技术人员高效处理数据库异常。常见的故障类型包括性能问题(如高CPU使用率、内存不足、阻塞和死锁)、数据库备份与恢复问题(如备份失败、恢复失败)以及数据库损坏(如页面级损坏、系统表损坏)。针对这些问题,文中提供了详细的排查方法和SQL查询脚本,并给出了相应的解决方案。此外,还介绍了系统动态管理视图(DMV)和扩展事件(Extended Events)等高级排查工具,帮助用户深入分析数据库性能问题。通过这些工具和方法,技术人员可以快速识别并

冰茶的博客 2415
上一篇: NOT IN子查询中出现NULL值对结果的影响你注意到了吗
下一篇: 源码解析丨一次慢SQL排查
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值