【MySQL08】【死锁】

news2024/11/14 13:51:09

文章目录

  • 一、前言
  • 二、查看事务加锁情况
    • 1. 使用 information_schema 数据库中表获取锁信息
      • 1.1 INNODB_TRX
      • 1.2 INNODB_LOCKS
      • 1.3 INNODB_LOCK_WAITS
    • 2. 使用 SHOW ENGIN INNODB STATUS 获取锁信息
  • 三、死锁
  • 四、参考内容

一、前言

最近在读《MySQL 是怎样运行的》、《MySQL技术内幕 InnoDB存储引擎 》，后续会随机将书中部分内容记录下来作为学习笔记，部分内容经过个人删改，因此可能存在错误，如想详细了解相关内容强烈推荐阅读相关书籍。

系列文章内容目录：

  1. 【MySQL00】【 杂七杂八】
  2. 【MySQL01】【 Explain 命令详解】
  3. 【MySQL02】【 InnoDB 记录存储结构】
  4. 【MySQL03】【 Buffer Pool】
  5. 【MySQL04】【 redo 日志】
  6. 【MySQL05】【 undo 日志】
  7. 【MySQL06】【MVCC】
  8. 【MySQL07】【锁】
  9. 【MySQL08】【死锁】

二、查看事务加锁情况

1. 使用 information_schema 数据库中表获取锁信息

1.1 INNODB_TRX

INNODB_TRX 存储了 InnoDB 当前正在执行的事务信息，包括事务id（如果没有分配事务id，则显示当前事务对应的内存结构的指针）、事务状态（比如事务正在运行还是在等待获取某个锁、事务正在执行的语句、事务是何时开启的）等。如下：

  1. 开启一个事务 T1
    mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM hero WHERE number = 8 FOR UPDATE;
+--------+-------+---------+
| number | name  | country |
+--------+-------+---------+
|      8 | c曹操 | 魏      |
+--------+-------+---------+
1 row in set (0.00 sec)
  2. 在另一个会话中查询 INNODB_TRX 表：
    mysql> SELECT * FROM  information_schema.INNODB_TRX\G
*************************** 1. row ***************************
                    trx_id: 195617
                 trx_state: RUNNING
               trx_started: 2024-06-27 09:51:28
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 2
       trx_mysql_thread_id: 10
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 1
          trx_lock_structs: 2
     trx_lock_memory_bytes: 1136
           trx_rows_locked: 1
         trx_rows_modified: 0
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
1 row in set (0.00 sec)

从执行结果可以看到，当前系统中有一个事务id为 195617 的事务，它的状态为 “正在运行”（RUNNING），隔离级别为 REPEATABLE READ。这里主要关注下面几个属性：

  • trx_tables_locked ：表示当前事务加了多少表级锁
  • trx_rows_locked ：表示当前事务加了多少行级锁
  • trx_lock_structs ：表示当前事务生成了多少内存中的锁结构。

1.2 INNODB_LOCKS

INNODB_LOCKS 记录了一些锁信息，主要包括：

  • 如果一个事务想要获取锁但是未获取到，则记录该锁信息
  • 如果一个事务获取到了某个所，但是这个锁阻塞了别的事务，则记录该锁信息。

  1. INNODB_LOCKS 表只有在系统中发生某个事务获取不到锁而被阻塞时才会有记录，因此我们需要再执行一个事务 T2

    mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM hero WHERE number = 8 FOR UPDATE;
+--------+-------+---------+
| number | name  | country |
+--------+-------+---------+
|      8 | c曹操 | 魏      |
+--------+-------+---------+
1 row in set (0.00 sec)

  2. 查询 INNODB_LOCKS 表记录，如下

    mysql> SELECT * FROM  information_schema.INNODB_LOCKS;
+-----------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+-----------+
| lock_id         | lock_trx_id | lock_mode | lock_type | lock_table    | lock_index | lock_space | lock_page | lock_rec | lock_data |
+-----------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+-----------+
| 195619:2432:3:8 | 195619      | X         | RECORD    | `demo`.`hero` | PRIMARY    |       2432 |         3 |        8 | 8         |
| 195617:2432:3:8 | 195617      | X         | RECORD    | `demo`.`hero` | PRIMARY    |       2432 |         3 |        8 | 8         |
+-----------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+-----------+
2 rows in set, 1 warning (0.00 sec)

可以看到 trx_id 为 195617 和 195619两个事务存在记录，但是上述内容无法区分是到底谁获取到其他事务的需要的锁，以及谁因为没有获取到锁而阻塞。可以通过 INNODB_LOCK_WAITS 表获取到

1.3 INNODB_LOCK_WAITS

INNODB_LOCK_WAITS 表明每个阻塞的事务是因为获取不到哪个事务持有的锁而阻塞。继续上面的情况，执行如下语句

mysql> SELECT * FROM  information_schema.INNODB_LOCK_WAITS;
+-------------------+-------------------+-----------------+------------------+
| requesting_trx_id | requested_lock_id | blocking_trx_id | blocking_lock_id |
+-------------------+-------------------+-----------------+------------------+
| 195619            | 195619:2432:3:8   | 195617          | 195617:2432:3:8  |
+-------------------+-------------------+-----------------+------------------+
1 row in set, 1 warning (0.00 sec)

其中：

  • requesting_trx_id ：表示因为获取不到锁而被阻塞的事务的事务id；本例中表示事务T2 的id
  • blocking_trx_id ：表示因为获取到别的事务需要的锁而导致其被阻塞的事务的事务id；本地中表示事务T1的id

需要注意的是：INNODB_LOCKS 和 INNODB_LOCK_WAITS 已经被标记过时，在MySQL 8.0 中就已经被移除。

2. 使用 SHOW ENGIN INNODB STATUS 获取锁信息

  1. 以下面SQL为例

    mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM hero FORCE INDEX(idx_name) WHERE name > 'c曹操' AND name <= 'x荀彧' AND country != '吴' ORDER BY name DESC FOR UPDATE;
+--------+-------+---------+
| number | name  | country |
+--------+-------+---------+
|     15 | x荀彧 | 魏      |
|      1 | l刘备 | 蜀      |
+--------+-------+---------+
2 rows in set (0.00 sec)

    该SQL的加锁流程在 【MySQL07】【锁】有过分析，其加锁结构如下：
    在这里插入图片描述

  2. 执行 SHOW ENGINE INNODB STATUS，如下：

    mysql> SHOW ENGINE INNODB STATUS\G
*************************** 1. row ***************************
... 省略部分信息
------------
TRANSACTIONS
------------
# 下一个待分配的事务id信息
Trx id counter 195622
# 一些关于 purge 信息
Purge done for trx's n:o < 195295 undo n:o < 0 state: running but idle

# 每个回滚段中有一个 History 链表，这些链表的总长是 1933
History list length 1933

# 每个事务的具体信息
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 283969552689208, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283969552688336, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283969552687464, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283969552686592, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283969552685720, not started
0 lock struct(s), heap size 1136, 0 row lock(s)

# 事务id为 195621 的事务，处于活跃状态 139s
---TRANSACTION 195621, ACTIVE 139 sec
# 该事务有4个锁结构， 9 个行锁
4 lock struct(s), heap size 1136, 9 row lock(s)

# 执行该事务的线程在 MySQL 中的编号为 9，操作系统中的线程号是 19744, 本次查询的编号是 255,,客户端主机名为 localhost, 用户名四 root
MySQL thread id 9, OS thread handle 19744, query id 255 localhost ::1 root cleaning up

... 忽略剩余内容

1 row in set (0.00 sec)

    上面输出的结构无法看出到底哪个事务对哪些记录加了哪些锁，因此可以将 innodb_status_output_locks 设置为 on 然后再输出日志，如下(这里只保存了 TRANSACTIONS 部分的日志，上述SQL 重新执行了，所以下面的事务ID 有了变化，本次事务id 195625)：

    # 设置 innodb_status_output_locks = ON
mysql> SET GLOBAL innodb_status_output_locks = ON;
Query OK, 0 rows affected (0.00 sec)

# 再次执行 SHOW ENGINE INNODB STATUS语句
mysql> SHOW ENGINE INNODB STATUS\G
*************************** 1. row ***************************
... 省略部分信息
------------
TRANSACTIONS
------------
Trx id counter 195625
Purge done for trxs n:o < 195623 undo n:o < 0 state: running but idle
History list length 1934
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 283969552690080, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283969552689208, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283969552688336, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283969552687464, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283969552686592, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283969552685720, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 195624, ACTIVE 51 sec
4 lock struct(s), heap size 1136, 9 row lock(s)
MySQL thread id 9, OS thread handle 19744, query id 264 localhost ::1 root cleaning up
# 表明事务id = 195624 的事务对 hero 表加了 IX 锁（意向独占锁）。
TABLE LOCK table `demo`.`hero` trx id 195624 lock mode IX
# 表示一个锁结构，这个锁结构的 Space ID 为 2432, Page No 为 4, n_bits 为 80, 对应的索引是 idx_name, 这个锁结构存放的锁的类型是 X 型 gap 锁
RECORD LOCKS space id 2432 page no 4 n bits 80 index idx_name of table `demo`.`hero` trx id 195624 lock_mode X locks gap before rec
# 上面锁结构加锁的详细信息(就是 name = z诸葛亮的 二级索引记录)
Record lock, heap no 6 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 10; hex 7ae8afb8e8919be4baae; asc z         ;;
 1: len 4; hex 80000003; asc     ;;
# 表示一个锁结构，这个锁结构的 Space ID 为 2432, Page No 为 4, n_bits 为 80, 对应的索引是 idx_name, 这个锁结构存放的锁的类型是 X 型 next-key 锁
RECORD LOCKS space id 2432 page no 4 n bits 80 index idx_name of table `demo`.`hero` trx id 195624 lock_mode X
# 上面锁结构加锁的详细信息(就是name = l刘备、c曹操、x荀彧、s孙权)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 7; hex 63e69bb9e6938d; asc c      ;;
 1: len 4; hex 80000008; asc     ;;

Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 7; hex 6ce58898e5a487; asc l      ;;
 1: len 4; hex 80000001; asc     ;;

Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 7; hex 73e5ad99e69d83; asc s      ;;
 1: len 4; hex 80000014; asc     ;;

Record lock, heap no 5 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 7; hex 78e88d80e5bda7; asc x      ;;
 1: len 4; hex 8000000f; asc     ;;

Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
 0: len 7; hex 67e585b3e7bebd; asc g      ;;
 1: len 4; hex 8000001e; asc     ;;
# 表示一个锁结构，这个锁结构的 Space ID 为 2432, Page No 为 3, n_bits 为 80, 对应的索引是 PRIMARY, 也就是聚簇索引，这里存放的锁的类型是 X 型正经记录锁（lock_mode X locks rec but not gap）
RECORD LOCKS space id 2432 page no 3 n bits 80 index PRIMARY of table `demo`.`hero` trx id 195624 lock_mode X locks rec but not gap
# 上面锁结构加锁的详细信息(就是id = 1,15,20 的记录)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000001761e; asc     v ;;
 2: len 7; hex 3c000002c10110; asc <      ;;
 3: len 7; hex 6ce58898e5a487; asc l      ;;
 4: len 3; hex e89c80; asc    ;;

Record lock, heap no 4 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 8000000f; asc     ;;
 1: len 6; hex 000000017634; asc     v4;;
 2: len 7; hex a90000011d0110; asc        ;;
 3: len 7; hex 78e88d80e5bda7; asc x      ;;
 4: len 3; hex e9ad8f; asc    ;;

Record lock, heap no 10 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000014; asc     ;;
 1: len 6; hex 000000017642; asc     vB;;
 2: len 7; hex 30000001e81fb2; asc 0      ;;
 3: len 7; hex 73e5ad99e69d83; asc s      ;;
 4: len 3; hex e590b4; asc    ;;
 
... 省略部分信息

1 row in set (0.00 sec)

三、死锁

执行顺序事务 T1事务T2
1BEGIN;
2BEGIN;
3SELECT * FROM hero WHERE number = 1 FOR UPDATE;
4SELECT * FROM hero WHERE number = 3 FOR UPDATE;
5SELECT * FROM hero WHERE number = 1 FOR UPDATE; （阻塞）
6SELECT * FROM hero WHERE number = 1 FOR UPDATE;（阻塞）

上述流程比较清楚：

  1. 事务T1 获取到了 number = 1 的行锁，对该记录加了X 锁；
  2. 事务T2 获取到了 number = 3 的行锁，对该记录加了X 锁；
  3. 事务T1 获取 number = 3 的行锁，但是因为该行记录锁被 T2 持有因此陷入等待；
  4. 事务T2 获取 number = 1 的行锁，但是因为该行记录锁被 T1 持有因此陷入等待，陷入死锁。

InnoDB 有个死锁检测机制，当检测到死锁发生时，会选择一个较小的事务（在事务执行过程中插入、更新、删除记录条数更少的记录）进行回滚，并提示客户端信息：

Deadlock found when trying to get lock; try restarting transaction

可以通过 SHOW ENGINE INNODB STATUS 语句来查看最近发生的一次死锁信息，

SHOW ENGINE INNODB STATUS 只会显示最近一次发生的死锁信息，如果死锁频繁出现，可以将全局系统变量 innodb_print_all_deadlocks 设置为 ON，这样可以将死锁发生时的信息都记录在 MySQL 的错误日志中。

如下：

mysql> SHOW ENGINE INNODB STATUS\G
*************************** 1. row ***************************

... 忽略部分信息

# 最近一次死锁
------------------------
LATEST DETECTED DEADLOCK
------------------------
# 死锁发生时间， 0x3d08 是操作系统为当前会话分配的线程的线程编号。
2024-06-27 13:55:20 0x29ec
# 死锁发生的第一个事务的有关信息
*** (1) TRANSACTION:
# 为事务分配的id是 195635， 事务处于 ACTIVE 状态 7s了，事务当前做的操作是 " starting index read"
# 该事务的id 比第二个事务的id 小，也就说明当前事务是先执行的，即 事务 T1
TRANSACTION 195635, ACTIVE 7 sec starting index read
# 此事务当前执行的语句使用了一个表，为一个表上了锁
mysql tables in use 1, locked 1
# 此事务处于 LOCK WAIT 状态，拥有3个锁结构，2个行锁
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
# 执行此事务的线程信息
MySQL thread id 22, OS thread handle 15624, query id 461 localhost ::1 root statistics
# 发生死锁时执行的语句
SELECT * FROM hero WHERE number = 3 FOR UPDATE
# 此事务当前在等待获取的锁
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2432 page no 3 n bits 80 index PRIMARY of table `demo`.`hero` trx id 195635 lock_mode X locks rec but not gap waiting
Record lock, heap no 9 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000003; asc     ;;
 1: len 6; hex 00000001763c; asc     v<;;
 2: len 7; hex ad000001210110; asc     !  ;;
 3: len 10; hex 7ae8afb8e8919be4baae; asc z         ;;
 4: len 3; hex e89c80; asc    ;;

# 死锁发生时第二个事务的信息
*** (2) TRANSACTION:
# 为事务分配的id是 195636， 事务处于 ACTIVE 状态 5s了，事务当前做的操作是 " starting index read"
# 该事务的id 比第一个事务的id 大，也就说明当前事务是后执行的， 也就是事务T2
TRANSACTION 195636, ACTIVE 5 sec starting index read, thread declared inside InnoDB 5000
# 此事务当前执行的语句使用了一个表，为一个表上了锁
mysql tables in use 1, locked 1
# 此事务拥有3个锁结构，2个行锁
3 lock struct(s), heap size 1136, 2 row lock(s)
# 执行此事务的线程信息
MySQL thread id 21, OS thread handle 10732, query id 460 localhost ::1 root statistics
# 发生死锁时执行的语句
SELECT * FROM hero WHERE number = 1 FOR UPDATE
# 此事务已经获取的锁
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 2432 page no 3 n bits 80 index PRIMARY of table `demo`.`hero` trx id 195636 lock_mode X locks rec but not gap
Record lock, heap no 9 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000003; asc     ;;
 1: len 6; hex 00000001763c; asc     v<;;
 2: len 7; hex ad000001210110; asc     !  ;;
 3: len 10; hex 7ae8afb8e8919be4baae; asc z         ;;
 4: len 3; hex e89c80; asc    ;;
 
# 此事务等待的锁
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2432 page no 3 n bits 80 index PRIMARY of table `demo`.`hero` trx id 195636 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000001761e; asc     v ;;
 2: len 7; hex 3c000002c10110; asc <      ;;
 3: len 7; hex 6ce58898e5a487; asc l      ;;
 4: len 3; hex e89c80; asc    ;;
 
# InnoDB 决定回滚 第二个事务
*** WE ROLL BACK TRANSACTION (2)

... 忽略部分信息

1 row in set (0.00 sec)

四、参考内容

书籍：《MySQL是怎样运行的——从根儿上理解MySQL》、《MySQL技术内幕 InnoDB存储引擎 》
https://blog.csdn.net/filling_l/article/details/112854716

如有侵扰，联系删除。 内容仅用于自我记录学习使用。如有错误，欢迎指正

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2103274.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

GPU版pytorch安装（win/linux）

GPU版pytorch安装（win/linux）

参考&#xff1a; Pytorch环境配置——cuda、、cudnn、torch、torchvision对应版本&#xff08;最全&#xff09;及安装方法-CSDN博客 Previous PyTorch Versions | PyTorch 法1&#xff1a;命令安装 如&#xff1a; conda install pytorch2.1.0 torchvision0.16.0 torchau…
阅读更多...
Leetcode面试经典150题-63.不同路径II

Leetcode面试经典150题-63.不同路径II

解法都在代码里&#xff0c;不懂就留言或者私信 class Solution {/**本题是典型的动态规划&#xff0c;但是需要注意的是这个网格中是有障碍的&#xff0c;障碍不能走所以其实还是一样的&#xff0c;计算所有点到(m-1,n-1)有多少种方式&#xff0c;返回(0,0)位置的解就行了 */…
阅读更多...
Python | Leetcode Python题解之第393题UTF-8编码验证

Python | Leetcode Python题解之第393题UTF-8编码验证

题目&#xff1a; 题解&#xff1a; class Solution:def validUtf8(self, data: List[int]) -> bool:MASK1, MASK2 1 << 7, (1 << 7) | (1 << 6)def getBytes(num: int) -> int:if (num & MASK1) 0:return 1n, mask 0, MASK1while num & m…
阅读更多...
Python文件自动分类

Python文件自动分类

假如这样的步骤全部手动做下来耗时是6秒&#xff0c;在文件数量不多的情况下&#xff0c;比如10个文件&#xff0c;总共耗时一分钟其实是能够接受的。 但当文件数量特别多时&#xff0c;或者这个操作特别频繁每天都要做十几二十次时&#xff0c;手动操作就会变得耗时又繁琐…
阅读更多...
哪款宠物空气净化器能更好的清除浮毛？希喂、范罗士测评

哪款宠物空气净化器能更好的清除浮毛？希喂、范罗士测评

七年前开始养了第一只小猫咪&#xff0c;没想到从此家里就开始一直养&#xff0c;到现在都已经养了5只。之前第一只的时候&#xff0c;就觉得很可爱&#xff0c;而且当时刚毕业&#xff0c;算是一时上头才养了它&#xff0c;后面发现我们经常是要出门上班、出差、游玩&#xff…
阅读更多...
冲击大厂算法面试=＞链表专题【链表反转之局部反转升级版】

冲击大厂算法面试=＞链表专题【链表反转之局部反转升级版】

目录标题 多重局部反转之K 个一组翻转链表上代码题解呀实在不会的时候记住 多重局部反转之K 个一组翻转链表 上代码 整个函数通过不断地检查剩余节点数量和进行局部反转&#xff0c;实现了链表的分组反转&#xff0c;最后返回反转后的链表。这种方法有效地利用了额外的 pre 和…
阅读更多...
VBA学习(71)：Excel VBA 访问带密码保护的Access数据库/用户窗体设置/EXCEL用户+密码登录界面（Access版）

VBA学习(71)：Excel VBA 访问带密码保护的Access数据库/用户窗体设置/EXCEL用户+密码登录界面（Access版）

前两天我们分享了一个用户密码登录EXCEL的案例【Excel VBA 用户窗体设置/一步一步代你设计EXCEL用户密码登录界面】&#xff0c;文中提及数据存储在Access中的情况&#xff0c;今天我就来把数据表&#xff08;tb用户&#xff09;移到Access中&#xff0c;修改一下代码&#xff…
阅读更多...
使用jmeter压测数据库

使用jmeter压测数据库

写在文章开头 除了wrk以外，jmeter一直是笔者比较喜欢的一个压测工具，从使用场景和功能范围来看，算是一款比较全面且上手快速的压测工具，本文将基于MySQL数据库为读者演示一下如何通过jmeter压测数据库，希望对你有帮助。 Hi，我是 sharkChili ，是个不断在硬核技术上作死的…
阅读更多...
FreeRTOS学习笔记—②RTOS的认识（持续更新中）

FreeRTOS学习笔记—②RTOS的认识（持续更新中）

由于正在学习韦东山大佬的RTOS课程&#xff0c;结合了网上的一些资料&#xff0c;整理记录了下自己的感悟&#xff0c;用于以后自己的回顾。如有不对的地方请各位大佬纠正。 课程链接&#xff1a;https://www.bilibili.com/video/BV1844y1g7ud/?spm_id_from333.337.search-car…
阅读更多...
Postman环境变量：简化API测试的利器

Postman环境变量：简化API测试的利器

引言 在当今快速发展的互联网时代&#xff0c;API&#xff08;应用程序接口&#xff09;的重要性不言而喻。无论是内部系统间的通信还是对外服务的提供&#xff0c;API都扮演着至关重要的角色。然而&#xff0c;在API的开发与测试过程中&#xff0c;经常需要处理各种各样的配置…
阅读更多...
Java语言程序设计基础篇_编程练习题**17.21 (十六进制编辑器)

Java语言程序设计基础篇_编程练习题**17.21 (十六进制编辑器)

目录 题目&#xff1a;**17.21 (十六进制编辑器) 代码示例 结果展示 题目&#xff1a;**17.21 (十六进制编辑器) 编写一个 GUI 应用程序&#xff0c;让用户在文本域输入一个文件名&#xff0c;然后按回车键&#xff0c;在文本域显示它的十六进制表达形式。用户也可以修改十六…
阅读更多...
SEO之网站结构优化（十四-内部链接及权重分配3）

SEO之网站结构优化（十四-内部链接及权重分配3）

初创企业搭建网站的朋友看1号文章&#xff1b;想学习云计算&#xff0c;怎么入门看2号文章谢谢支持&#xff1a; 1、我给不会敲代码又想搭建网站的人建议 2、“新手上云”能够为你开启探索云世界的第一步 博客&#xff1a;阿幸SEO~探索搜索排名之道 7、锚文字分布及变化 前面…
阅读更多...
不可不知的WPF形状（Shape）

不可不知的WPF形状（Shape）

在WPF开发中经常需要进行绘制图形&#xff0c;可以利用Shape类型绘制基本的形状&#xff0c;而且Shape派生自FrameworkElement&#xff0c;属于UI元素范畴&#xff0c;可以直接利用XAML进行绘制。本文通过一些简单的小例子&#xff0c;简述如何通过Shape类绘制形状&#xff0c;…
阅读更多...
SMB攻击利用之-设置远程mimikatz程序为定时任务流量数据包分析

SMB攻击利用之-设置远程mimikatz程序为定时任务流量数据包分析

SMB协议作为windows环境下最为常见的一种协议&#xff0c;在历史上出现过无数的通过SMB协议进行网络攻击利用的案例&#xff0c;包括针对SMB协议本身以及通过SMB协议实施网络攻击。 本文将介绍一种SMB协议的常见利用方式&#xff0c;即通过windows的服务调用将远程主机上的mim…
阅读更多...
MySQL数据库安装（详细）—＞Mariadb的安装（day21）

MySQL数据库安装（详细）—＞Mariadb的安装（day21）

该网盘链接有效期为7天&#xff0c;有需要评论区扣我&#xff1a; 通过网盘分享的文件&#xff1a;mariadb-10.3.7-winx64.msi 链接: https://pan.baidu.com/s/1-r_w3NuP8amhIEedmTkWsQ?pwd2ua7 提取码: 2ua7 1 双击打开安装软件 本次安装的是mariaDB&#xff0c;双击打开mar…
阅读更多...
【STM32开发】GPIO最全解析及应用实例

【STM32开发】GPIO最全解析及应用实例

目录 【1】GPIO概述 GPIO的基本概念 GPIO的应用 【2】GPIO功能描述 1.IO功能框图 2.知识补充 3.功能详述 浮空输入 上拉输入 下拉输入 模拟输入 推挽输出 开漏输出 复用开漏输出和复用推挽输出 【3】GPIO常用寄存器 相关寄存器介绍 4个32位配置寄存器 2个32位数据寄存器 1个32位…
阅读更多...
Linux【1】基础

Linux【1】基础

目录 cd ​编辑 Linux的粘贴是Ctrlshiftv&#xff0c;复制、剪切&#xff1a; pwd打印当前路径 cat 文件目录 读取 ↑ 可以调取之间输过的命令 mv A B 把文件名A改成B #掐头%去尾 touch 文件名 mkdir创建目录​编辑 删除rm 只能删除文件 终端命令格式 帮助 man命…
阅读更多...
vant 动态查询下拉菜单（可用）

vant 动态查询下拉菜单（可用）

动态查询item项 <van-form submit"onSubmit" ref"formRef"><Title title"企业信息" title-line title-size"19" class"ml-[18px] mb-[18px]"></Title><van-cell-group inset class"py-[18px]&quo…
阅读更多...
springblade-JWT认证缺陷漏洞CVE-2021-44910

springblade-JWT认证缺陷漏洞CVE-2021-44910

漏洞成因 SpringBlade前端通过webpack打包发布的&#xff0c;可以从其中找到app.js获取大量接口 然后直接访问接口&#xff1a;api/blade-log/api/list 直接搜索“请求未授权”&#xff0c;定位到认证文件&#xff1a;springblade/gateway/filter/AuthFilter.java 后面的代码…
阅读更多...
【数据分享】2021-2024年我国主要城市逐月轨道交通客运量数据

【数据分享】2021-2024年我国主要城市逐月轨道交通客运量数据

以地铁为代表的轨道交通是大城市居民的主要交通出行方式之一&#xff0c;轨道交通的客运量数据是评估城市轨道交通系统运行效率、承载能力和服务水平的重要指标。本次我们为大家带来的是2021-2024年我国主要城市的逐月轨道交通客运量数据&#xff01;数据更新到2024年7月份。 …
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023