事务04之死锁，锁底层和隔离机制原理

news2025/2/2 0:24:28

死锁和事务底层原理

文章目录

  • 死锁和事务底层原理
    • 一：MySQL中的死锁现象
      • 1：何为死锁
        • 1.1：死锁的概念
        • 1.2：死锁产生的四个必要条件：
      • 2：MySQL的死锁
        • 2.1：死锁的触发
        • 2.2：MySQL的死锁如何解决的
    • 二：锁机制的底层实现原理
      • 1：锁的内存结构
      • 2：InnoDB的锁优化实现
      • 3：MySQL获取锁的过程
    • 三：事务隔离机制的底层实现
      • 1：读未提交RU的底层实现
      • 2：读已提交RC的底层实现
      • 3：可重复读RR的底层实现
      • 4：序列化的底层实现
      • 5：总结

一：MySQL中的死锁现象

对于多线程与锁而言，存在一个100%会出现的偶发问题，即死锁问题。

1：何为死锁

1.1：死锁的概念

所谓死锁：就是多个进程之间由于资源的竞争而造成的阻塞现象，如果没有外力作用，这些进程将无法继续推进

和死锁相似的概念是饥饿：等待时间过长以至于给进程推进和响应造成了明显的影响，“饿而不死”

死锁产生的原因：系统的资源竞争、进程推进顺序非法

1.2：死锁产生的四个必要条件：
  • 互斥条件：共享资源的排他性访问（互斥是基本前提）
  • 不剥夺条件：访问时该共享资源不会被剥夺，而是需要共享资源的进程主动释放（不能蛮横的抢）
  • 请求并保持：保持当前的资源而请求另外的资源（不放弃自己的）
  • 循环等待条件：存在共享资源的循环等待链（A -> B -> C -> A）

在这里插入图片描述

2：MySQL的死锁

2.1：死锁的触发

MySQL与Redis、Nginx这类单线程工作的程序不同，它属于一种内部采用多线程工作的应用，因而不可避免的就会产生死锁问题

举一个简单的转账的例子：

在这里插入图片描述
T1等待T2释放锁、T2等待T1释放锁，双方各自等待对方释放锁，一直如此僵持下去，最终就引发了死锁问题

MySQL面对死锁怎么办呢？模拟一下呗：

1：先创建一个表，注意这个表的主键一定要设置成为一会儿update中的where字段

CREATE TABLE `springboot`.`cuihaida_account`  (
`user_name` varchar(255) NOT NULL COMMENT '姓名',
`account` int NOT NULL COMMENT '账户',
PRIMARY KEY (`user_name`) # 因为MySQL记录锁的特性，只有条件命中索引的时候才加的是行锁，否则是表锁
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci;


# 插入两条数据
insert into `cuihaida_account` values ('张三', 100);
insert into `cuihaida_account` values ('李四', 100);

2：开启两个终端，准备进行测试
在这里插入图片描述
因此，当死锁问题出现时，MySQL会自动检测并介入，强制回滚结束一个“死锁的参与者（事务）”，从而打破死锁的僵局，让另一个事务能继续执行

2.2：MySQL的死锁如何解决的

对于解决死锁问题可以从多个维度出发，比如预防死锁、避免死锁、解除死锁等，当死锁问题出现后一般只有两种方案：

  • 锁超时机制：事务/线程在等待锁时，超出一定时间后自动放弃等待并返回。
  • 外力介入打破僵局：第三者介入，将死锁情况中的某个事务/线程强制结束，让其他事务继续执行。

锁超时机制

在InnoDB中其实提供了锁的超时机制，也就是一个事务在长时间内无法获取到锁时，就会主动放弃等待，抛出相关的错误码及信息，然后返回给客户端

时间限制到底是多久呢？可以通过如下命令查询：

SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';

在这里插入图片描述
在50s内未获取到锁的事务，会自动结束并返回。

那也就意味着当死锁情况出现时，这个死锁过程最多持续50s，然后其中就会有一个事务主动退出竞争，释放持有的锁资源

但实际业务中，仅依赖超时机制去解除死锁是不够的，毕竟高并发情况下，50s时间太长了，会导致越来越多的事务阻塞。

这个参数调小会好吗？

参数调小之后确实能确保死锁发生后，在很短的时间内可以自动解除

但改掉了这个参数之后，也会影响正常事务等待锁的时间，也就是大部分未发生死锁，但需要等待锁资源的事务，在等待短时间之后，就会立马报错并返回

这显然并不合理，毕竟容易误伤“友军”。

死锁检测算法(wait-for graph)

这种算法是专门用于检测死锁问题的，在该算法中会对于目前库中所有活跃的事务生成等待图，例如：【可以类比os死锁中的死锁定理中的资源分配图】

在这里插入图片描述
当MySQL发现了这种等待闭环时，就会强制介入，回滚结束其中一个事务，强制打破该闭环，从而解除死锁问题。

wait-for graph是怎么工作的？[了解下即可]

wait-for graph算法被启用后，会要求MySQL收集两个信息：

  • 锁的信息链表：目前持有每个锁的事务是谁。
  • 事务等待链表：阻塞的事务要等待的锁是谁。

每当一个事务需要阻塞等待某个锁时，就会触发一次wait-for graph算法

该算法会以当前事务作为起点，然后从「锁的信息链表」中找到对应中锁信息。再去根据锁的持有者（事务），在「事务等待链表」中进行查找，看看持有锁的事务是否在等待获取其他锁，如果是，则再去看看另一个持有锁的事务，是否在等待其他锁…，经过一系列的判断后，再看看是否会出现闭环，出现的话则介入破坏。就形成了类似于下面的这张图：

在这里插入图片描述
此时当T3事务需要阻塞等待获取X1锁时，就会触发一次wait-for graph算法，流程如下：

  1. 先根据T3要获取的X1锁，在「锁的信息链表」中找到X1锁的持有者T1。
  2. 再在「事务等待链表」中查找，看看T1是否在等待获取其他锁，此时会得知T1等待X2。
  3. 再去「锁的信息链表」中找到X2锁的持有者T2，再看看T2是否在阻塞等待获取其他锁。
  4. 再在「事务等待链表」中查找T2，发现T2正在等待获取X3锁，再找X3锁的持有者。

经过上述一系列算法过程后，最终会发现X3锁的持有者为T3，而本次算法又正是T3事务触发的，此时又回到了T3事务，也就代表着产生了“闭环”，因此也可以证明这里出现了死锁现象，所以MySQL会强制回滚其中的一个事务，来抵达解除死锁的目的。

出现死锁问题时，MySQL会选择哪个事务回滚呢？

当一个事务在执行SQL更改数据时，都会记录在Undo-log日志中

Undo量越小的事务，代表它对数据的更改越少，同时回滚的代价最低，因此会选择Undo量最小的事务回滚

如若两个事务的Undo量相同，会选择回滚触发死锁的事务

🎉 可以通过innodb_deadlock_detect=on|off这个参数，来控制是否开启死锁检测机制。

在这里插入图片描述
⚠️死锁检测机制在MySQL后续的高版本中是默认开启的，但实际上死锁检测的开销不小，当阻塞的并发事务越来越多时，检测的效率也会呈线性增长

如何避免死锁产生

因为死锁的检测过程较为耗时，所以尽量不要等死锁出现后再去解除，而是尽量调整业务避免死锁的产生，一般来说可以从如下方面考虑：

  • 合理的设计索引结构，使业务SQL在执行时能通过索引定位到具体的几行数据，减小锁的粒度。
  • 业务允许的情况下，也可以将隔离级别调低，因为级别越低，锁的限制会越小。
  • 调整业务SQL的逻辑顺序，较大、耗时较长的事务尽量放在特定时间去执行（如凌晨对账…）。
  • 尽可能的拆分业务的粒度，一个业务组成的大事务，尽量拆成多个小事务，缩短一个事务持有锁的时间。
  • 如果没有强制性要求，就尽量不要手动在事务中获取排他锁，否则会造成一些不必要的锁出现，增大产生死锁的几率。
  • …

🎉 简单来说，在业务允许的情况下，尽量缩短一个事务持有锁的时间、减小锁的粒度以及锁的数量。

⚠️ 当MySQL运行过程中产生了死锁问题，那这个死锁问题以后绝对会再次出现，当死锁被MySQL自己解除后，一定要记住去排除业务SQL的执行逻辑，找到产生死锁的业务，然后调整业务SQL的执行顺序，这样才能从根源上避免死锁产生

二：锁机制的底层实现原理

1：锁的内存结构

在Java中，Synchronized锁是基于Monitor实现的，而ReetrantLock又是基于AQS实现的，那MySQL的锁是基于啥实现的呢？

在这里插入图片描述

锁的事务信息

其中记录着当前的锁结构是由哪个事务生成的，记录的是指针，指向一个具体的事务。

索引信息

这个是行锁的特有信息，对于行锁来说，需要记录一下加锁的行数据属于哪个索引、哪个节点，记录的也是指针

锁粒度信息

对于不同粒度的锁，其中存储的信息也并不同：

  • 如果是表锁，其中就记录了一下是对哪张表加的锁，以及表的一些其他信息。

  • 如果锁粒度是行锁，其中记录的信息更多，有三个较为重要的：

    • Space ID：加锁的行数据，所在的表空间ID。

    • Page Number：加锁的行数据，所在的页号。

    • n_bits：使用的比特位，对于一页数据中，加了多少个锁（后续结合讲）。

锁类型信息

对于锁结构的类型，在内部实现了复用，采用一个32bit的type_mode来表示

这个32bit的值可以拆为lock_mode、lock_type、rec_lock_type三部分

在这里插入图片描述

lock_mode：表示锁的模式，使用低四位。

  • 0000/0：表示当前锁结构是共享意向锁，即IS锁。
  • 0001/1：表示当前锁结构是排他意向锁，即IX锁。
  • 0010/2：表示当前锁结构是共享锁，即S锁。
  • 0011/3：表示当前锁结构是排他锁，即X锁。
  • 0100/4：表示当前锁结构是自增锁，即AUTO-INC锁。

lock_type：表示锁的类型，使用低位中的5~8位。

  • LOCK_TABLE：当第5个比特位是1时，表示目前是表级锁。
  • LOCK_REC：当第6个比特位是1时，表示目前是行级锁。

rec_lock_type：表示行锁的具体类型，使用其余位。

  • LOCK_ORDINARY：当高23位全零时，表示目前是临键锁。
  • LOCK_GAP：当第10位是1时，表示目前是间隙锁。
  • LOCK_REC_NOT_GAP：当第11位是1时，表示目前是记录锁。
  • LOCK_INSERT_INTENTION：当第12位是1时，表示目前是插入意向锁。
  • .....：内部还有一些其他的锁类型，会使用其他位。

is_waiting：表示目前锁处于等待状态还是持有状态，使用低位中的第9位。

  • 0：表示is_waiting=false，即当前锁无需阻塞等待，是持有状态。
  • 1：表示is_waiting=true，即当前锁需要阻塞，是等待状态。

在这里插入图片描述
例如上面这个图，表示一个阻塞等待的行级排他临键锁结构。

其他信息

这个所谓的其他信息，也就是指一些用于辅助锁机制的信息，例如wait-for graph中的两个辅助链表

锁的比特位

与其说是锁的比特位，不如说是数据的比特位，好比举个例子：

student_idnamesexheight
1xx男111
2xxx女111
3xxxx女112
4xxxxx男112
5xxxxxx男122
6xxxxxxx女112
7xxxxxxxx男122

学生表中有七条数据，此时就会形成一个比特数组：000000000

明明只有七条数据，为啥会有9个比特位呢？

因为行锁中，间隙锁可以锁定无穷小、无穷大这两个间隙，因此这组比特中，首位和末位即表示无穷小、无穷大两个间隙。

好比此时T1事务，对ID=2、3、6这三条数据加锁了，此时这个比特数组就会变为001100100，表示T1事务同时锁定了三条数据。

而之前聊到的n_bits，它就会记录一下在这组比特中，多少条记录被上锁了。

2：InnoDB的锁优化实现

如果一个事务同时需要对表中的1000条数据加锁，会生成1000个锁结构吗？

MySQL是基于事务实现的锁，当下面述四点条件被满足时，符合条件的行记录会被放入到同一个锁结构中

  • 目前对表中不同行记录加锁的事务是同一个。（同事务）
  • 需要加锁的记录在同一个页面中。（同页）
  • 目前事务加锁的类型都是相同的。（同类型）
  • 锁的等待状态也是相同的。（同等待状态）

假设加锁的1000条数据分布在3个页面中，同时表中没有其他事务在操作，加的都是同一类型的锁。

此时依据上述的前提条件，那在内存中仅会生成三个锁结构，能够很大程度上减少锁结构的数量

3：MySQL获取锁的过程

当一个事务需要获取某个行锁时，首先会看一下内存中是否存在这条数据的锁结构

如果存在则生成一个锁结构，将其is_waiting对应的比特位改为1，表示目前事务在阻塞等待获取该锁

当其他事务释放锁后，会唤醒当前阻塞的事务，然后会将其is_waiting改为0，接着执行SQL。

事务获取锁时，是如何在内存中，判断是否已经存在相同记录的锁结构呢？

还记得锁结构中会记录的一个信息嘛？也就是「锁粒度信息」，如果是表锁，会记录表信息，如果是行锁，会记录表空间、页号等信息。在事务获取锁时，就是去看内存中，已存在的锁结构的这个信息，来判断是否存在其他事务获取了锁。

释放锁的过程也比较简单，这个工作一般是由MySQL自己完成的，当事务结束后会自动释放，释放的时候会去看一下，内存中是否有锁结构，正在等待获取目前释放的锁，如果有则唤醒对应的线程/事务。

三：事务隔离机制的底层实现

  • RU/读未提交级别：要求该隔离级别下解决脏写问题。
  • RC/读已提交级别：要求该隔离级别下解决脏读问题。
  • RR/可重复读级别：要求该隔离级别下解决不可重复读问题。【其实这里已经解决了幻读问题，就是临键锁 + MVCC】
  • Serializable/序列化级别：要求在该隔离级别下解决幻读问题。

1：读未提交RU的底层实现

RU级别要求一个事务可以读到其他事务未提交的数据，但同时要求解决脏写（更新覆盖）问题

假设没有加锁

在这里插入图片描述
因此，对于解决脏写问题，RU采取的是读取的时候不加锁，写入的时候加入排他锁，防止其他事务的写覆盖掉自己的写

在这里插入图片描述

2：读已提交RC的底层实现

RC级别要求解决脏读问题，也就是一个事务中，不允许读另一个事务还未提交的数据

RC级别的底层实现，对于写操作会加排他锁，而读操作会使用MVCC机制。

但由于每次select时都会生成ReadView快照，此时就会出现下述问题：

在这里插入图片描述
此时观察这个案例，明明是在一个事务中查询同一条数据，结果两次查询的结果并不一致，这也是所谓的不可重复读的问题。

3：可重复读RR的底层实现

在RC级别中，虽然解决了脏读问题，但依旧存在不可重复读问题，而RR级别中，就是要确保一个事务中的多次读取结果一致，即解决不可重复读问题

两种方案：

  • 查询时，对目标数据加上临键锁，即读操作执行时，不允许其他事务改动数据
  • MVCC机制的优化版：一个事务中只生成一次ReadView快照

在这里插入图片描述

4：序列化的底层实现

在这个级别中，要求解决所有可能会因并发事务引发的问题

序列化就是所有写操作加临键锁（具备互斥特性），所有读操作加共享锁。

由于所有写操作在执行时，都会获取临键锁，所以写-写、读-写、写-读这类并发场景都会互斥

由于读操作加的是共享锁，因此在Serializable级别中，只有读-读场景可以并发执行。

5：总结

  • U级别：读操作不加锁，写操作加排他锁。
  • RC级别：读操作使用MVCC机制，每次SELECT生成快照，写操作加排他锁。
  • RR级别：读操作使用MVCC机制，首次SELECT生成快照，写操作加临键锁。
  • 序列化级别：读操作加共享锁，写操作加临键锁。
级别/场景读-读读-写/写-读写-写
RU级别并行执行并行执行串行执行
RC级别并行执行并行执行串行执行
RR级别并行执行并行执行串行执行
序列化级别并行执行串行执行串行执行

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

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

相关文章

Golang 并发机制-2：Golang Goroutine 和竞争条件

Golang 并发机制-2：Golang Goroutine 和竞争条件

在今天的软件开发中，我们正在使用并发的概念，它允许一次执行多个任务。在Go编程中，理解Go例程是至关重要的。本文试图详细解释什么是例程，它们有多轻，通过简单地使用“go”关键字创建它们，以及可能出现的竞…
阅读更多...
【4Day创客实践入门教程】Day0 创想启程——课程与项目预览

【4Day创客实践入门教程】Day0 创想启程——课程与项目预览

Day0 创想启程——课程与项目预览 目录 Day0 创想启程——课程与项目预览前言学习内容基本的单片机开发技能简单的焊接技能简单的MicroPython程序 后记 Day1 工具箱构建——开发环境的构建Day2 探秘微控制器——单片机与MicroPython初步Day3 实战演练——桌面迷你番茄钟Day4 迈…
阅读更多...
洛谷P3372 【模板】线段树 1以及分块

洛谷P3372 【模板】线段树 1以及分块

【模板】线段树 1 题目描述 如题，已知一个数列，你需要进行下面两种操作： 将某区间每一个数加上 k k k。求出某区间每一个数的和。 输入格式 第一行包含两个整数 n , m n, m n,m，分别表示该数列数字的个数和操作的总个数。 …
阅读更多...
（动态规划基础 打家劫舍）leetcode 198

（动态规划基础 打家劫舍）leetcode 198

已知h2和h1&#xff0c;用已知推出未知 推是求答案&#xff0c;回溯是给答案 这里图片给出dfs暴力&#xff0c;再进行记录答案完成记忆化搜索&#xff0c;再转为dp数组 #include<iostream> #include<vector> #include<algorithm> //nums:2,1,1,2 //dp:2,2,…
阅读更多...
Python 梯度下降法（四）：Adadelta Optimize

Python 梯度下降法（四）：Adadelta Optimize

文章目录 Python 梯度下降法&#xff08;四&#xff09;&#xff1a;Adadelta Optimize一、数学原理1.1 介绍1.2 实现流程 二、代码实现2.1 函数代码2.2 总代码 三、优缺点3.1 优点3.2 缺点 四、相关链接 Python 梯度下降法&#xff08;四&#xff09;&#xff1a;Adadelta Opt…
阅读更多...
旅行的意义：“诗与远方”和在旅途中找寻真我

旅行的意义：“诗与远方”和在旅途中找寻真我

原文链接&#xff1a;旅行的意义&#xff1a;“诗与远方”和在旅途中找寻真我 困在格子间&#xff0c;心向远方 清晨&#xff0c;闹钟催促&#xff0c;打工人挣扎起床出门。地铁拥挤&#xff0c;工作繁忙&#xff0c;加班成常态&#xff0c;下班时夜幕已深&#xff0c;满心疲惫…
阅读更多...
leetcode——将有序数组转化为二叉搜索树（java）

leetcode——将有序数组转化为二叉搜索树（java）

给你一个整数数组 nums &#xff0c;其中元素已经按 升序 排列&#xff0c;请你将其转换为一棵 平衡 二叉搜索树。 示例 1&#xff1a; 输入&#xff1a;nums [-10,-3,0,5,9] 输出&#xff1a;[0,-3,9,-10,null,5] 解释&#xff1a;[0,-10,5,null,-3,null,9] 也将被视为正确答…
阅读更多...
前端js高级25.1.30

前端js高级25.1.30

原型&#xff1a;函数的组成结构 通过这个图我们需要知道。 假设我们创建了一个Foo函数。 规则&#xff1a;Function.protoType是函数显示原型。__proto__是隐式对象。 Function、Object、Foo函数的__proto__指向了Function.protoType说明。这三个都依托function函数来创建。…
阅读更多...
【后端开发】字节跳动青训营之性能分析工具pprof

【后端开发】字节跳动青训营之性能分析工具pprof

性能分析工具pprof 一、测试程序介绍二、pprof工具安装与使用2.1 pprof工具安装2.2 pprof工具使用 资料链接&#xff1a; 项目代码链接实验指南pprof使用指南 一、测试程序介绍 package mainimport ("log""net/http"_ "net/http/pprof" // 自…
阅读更多...
云原生（五十二） | DataGrip软件使用

云原生（五十二） | DataGrip软件使用

文章目录 DataGrip软件使用 一、DataGrip基本使用 二、软件界面介绍 三、附件文件夹到项目中 四、DataGrip设置 五、SQL执行快捷键 DataGrip软件使用 一、DataGrip基本使用 1. 软件界面介绍 2. 附加文件夹到项目中【重要】 3. DataGrip配置 快捷键使用&#xff1a;C…
阅读更多...
FreeRTOS学习 --- 任务调度

FreeRTOS学习 --- 任务调度

开启任务调度器 作用&#xff1a;用于启动任务调度器&#xff0c;任务调度器启动后&#xff0c; FreeRTOS 便会开始进行任务调度 该函数内部实现&#xff0c;如下&#xff1a; 1、创建空闲任务&#xff08;优先级最低&#xff09; 2、如果使能软件定时器&#xff0c;则创建定…
阅读更多...
2025年人工智能技术：Prompt与Agent的发展趋势与机遇

2025年人工智能技术：Prompt与Agent的发展趋势与机遇

文章目录 一、Prompt与Agent的定义与区别（一）定义（二）区别二、2025年Prompt与Agent的应用场景（一）Prompt的应用场景（二）Agent的应用场景三、2025年Prompt与Agent的适合群体（一）Prompt适合的群体（二）Agent适合的群体四、2025年Prompt与Agent的发展机遇（一）Prompt的…
阅读更多...
区块链 智能合约安全 | 回滚攻击

区块链 智能合约安全 | 回滚攻击

视频教程在我主页简介和专栏里 目录&#xff1a; 智能合约安全 回滚攻击 总结 智能合约安全 回滚攻击 回滚攻击的本质是”耍赖” 举一个简单的例子,两个人玩石头剪刀布,输了的给对方10块钱,现在A输了,A说这把不算,重来 放在Solidity中,require()函数会检测其中的条件是否满…
阅读更多...
【JavaEE进阶】图书管理系统 - 壹

【JavaEE进阶】图书管理系统 - 壹

目录 &#x1f332;序言 &#x1f334;前端代码的引入 &#x1f38b;约定前后端交互接口 &#x1f6a9;接口定义 &#x1f343;后端服务器代码实现 &#x1f6a9;登录接口 &#x1f6a9;图书列表接口 &#x1f384;前端代码实现 &#x1f6a9;登录页面 &#x1f6a9;…
阅读更多...
TensorFlow 简单的二分类神经网络的训练和应用流程

TensorFlow 简单的二分类神经网络的训练和应用流程

展示了一个简单的二分类神经网络的训练和应用流程。主要步骤包括&#xff1a; 1. 数据准备与预处理 2. 构建模型 3. 编译模型 4. 训练模型 5. 评估模型 6. 模型应用与部署 加载和应用已训练的模型 1. 数据准备与预处理 在本例中&#xff0c;数据准备是通过两个 Numpy 数…
阅读更多...
docker安装Redis:docker离线安装Redis、docker在线安装Redis、Redis镜像下载、Redis配置、Redis命令

docker安装Redis:docker离线安装Redis、docker在线安装Redis、Redis镜像下载、Redis配置、Redis命令

一、镜像下载 1、在线下载 在一台能连外网的linux上执行docker镜像拉取命令 docker pull redis:7.4.0 2、离线包下载 两种方式&#xff1a; 方式一&#xff1a; -&#xff09;在一台能连外网的linux上安装docker执行第一步的命令下载镜像 -&#xff09;导出 # 导出镜像…
阅读更多...
Retrieval-Augmented Generation for Large Language Models: A Survey——(1)Overview

Retrieval-Augmented Generation for Large Language Models: A Survey——(1)Overview

Retrieval-Augmented Generation for Large Language Models: A Survey——(1)Overview 文章目录 Retrieval-Augmented Generation for Large Language Models: A Survey——(1)Overview1. Introduction&Abstract1. LLM面临的问题2. RAG核心三要素3. RAG taxonomy 2. Overv…
阅读更多...
LabVIEW透镜多参数自动检测系统

LabVIEW透镜多参数自动检测系统

在现代制造业中&#xff0c;提升产品质量检测的自动化水平是提高生产效率和准确性的关键。本文介绍了一个基于LabVIEW的透镜多参数自动检测系统&#xff0c;该系统能够在单一工位上完成透镜的多项质量参数检测&#xff0c;并实现透镜的自动搬运与分选&#xff0c;极大地提升了检…
阅读更多...
什么是Maxscript？为什么要学习Maxscript？

什么是Maxscript？为什么要学习Maxscript？

MAXScript是Autodesk 3ds Max的内置脚本语言，它是一种与3dsMax对话并使3dsMax执行某些操作的编程语言。它是一种脚本语言，这意味着您不需要编译代码即可运行。通过使用一系列基于文本的命令而不是使用UI操作，您可以完成许多使用UI操作无法完成的任务。 Maxscript是一种专有…
阅读更多...
Redis｜前言

Redis｜前言

文章目录 什么是 Redis&#xff1f;Redis 主流功能与应用 什么是 Redis&#xff1f; Redis&#xff0c;Remote Dictionary Server&#xff08;远程字典服务器&#xff09;。Redis 是完全开源的&#xff0c;使用 ANSIC 语言编写&#xff0c;遵守 BSD 协议&#xff0c;是一个高性…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023