【Golang】并发编程之三大问题:原子性、有序性、可见性

目录

  • 一、前言
  • 二、概念理解
    • 2.1 有序性
    • 2.2 原子性
      • 后果1:其它线程会读到中间态结果:
      • 后果2:修改结果被覆盖
    • 2.3 可见性
      • 1)store buffer(FIFO)引起的类似store-load乱序现象
      • 2)store buffer(非FIFO)引起的类似store-store乱序现象
  • 三、CPU级别的解决方案 - 内存屏障
    • 3.1 sfence(Store Barrier)
    • 3.2 lfence(Load Barrier)
    • 3.3 mfence(Full Barrier)
      • 问题1:为什么mfence != sfence + lfence?
    • 3.4 用LOCK前缀修饰指令
      • 问题1:LOCK前缀指令跟mfence之间的区别是什么?
  • 四、高级语言级别的解决方案 - 内存模型
    • 4.1 内存模型
    • 4.2 happens-before规则
    • 4.3 同步事件
      • 问题1:sync.Mutex和sync.atomic的区别?
      • 问题2:sync.atomic的happens-before 语义是什么?
  • 五、没有正确同步的代码示例及修复方法
  • 六、参阅

一、前言

在并发编程中会出现的问题可以归结为三大类:有序性、原子性、可见性。

说到并发,可能会有部分小伙伴认为只有在多线程环境中,才会有并发问题,但其实不是的,在单线程多协程的环境中也会有。只要多个对象对同一个共享变量进行读写(至少有一个是写),且没有做任何的同步(Synchronization)措施,那么不管这多个对象是线程还是协程或是其它东西,不管CPU是单核的还是多核的,都会造成竞态(Race Condition)的产生,从而引发并发问题,这点一定要记住。

单线程多协程:这里
单核CPU多线程:这里

建议在阅读本文前,先了解一些基本知识点,例如现代CPU缓存架构、MESI一致性协议、store buffer、invalidate queue等,可以阅读此文了解。

如文章内容有错误,欢迎指出,共同学习进步,谢谢:)

二、概念理解

2.1 有序性

顾名思义,有序性就是确保代码按照正确顺序运行,但在计算机中却不容易做到,例如:

a = 1
b = 2

我们预期是先执行a = 1,再执行b = 1,但实际的执行过程有可能会发生乱序,即两个语句的执行顺序跟代码书写顺序不同。

乱序来自两个方面,一个是编译器优化,一个是CPU优化,两者都有可能为了提高执行效率,对指令的执行顺序进行调整,这种行为称为指令重排(Instruction Reordering)

  • 编译器优化导致的乱序称为编译器指令重排(Compiler Reordering),也叫编译期指令重排;
  • CPU优化导致的乱序称为CPU指令重排(CPU Reordering),也叫运行时指令重排。

但编译器和CPU也不是随便进行指令重排的,它们只会对没有依赖关系的指令进行重排,例如这种指令就不会重排:

a = 1
b = a + 1

b的值依赖于a,所以不能改变执行顺序,否则就会出问题了。

在无并发(单线程/单协程)的环境中,指令重排不会影响程序最终的执行结果,这是编译器和CPU给的保证。但一旦到了并发环境(多线程/多协程),假设线程B的执行依赖于线程A的执行顺序,这时候如果对线程A进行指令重排就有可能导致线程B的执行结果出现问题,但编译器、CPU是无法识别出这种多线程之间的依赖关系的,所以需要另外的手段来解决。

下面看一个例子:

var a string
var done boolfunc setup() {a = "hello, world"done = true
}func main() {go setup()for !done {}print(a)
}

main协程期望done变为true的时候,就结束循环输出a变量(期望输出值是hello, world)。

这种期望能实现的前提是:a要在done完成赋值前完成赋值,也就是说,main协程输出正确的结果,依赖于setup协程的代码执行顺序。但可惜因为有指令重排序的存在,这个前提不一定能满足,有可能会发生:

  1. [setup协程] :执行done = true
  2. [main协程] :结束 for 循环,执行print(a); // a还没赋值,输出空字符串
  3. [setup协程] :执行a = "hello, world"

setup协程的代码执行顺序被打乱,导致main协程输出的a变量是一个空字符串,与预期不符。

问:如果指令没有重排,完全按照书写顺序执行,那还会输出空字符串吗?
答:还是会有可能,具体见下文2.3可见性章节

这段代码除了有重排序的问题,还有可见性的问题,for !done {}有可能会陷入死循环,具体见下文2.3可见性章节(1)。

CPU的操作指令可以分为store、load两类,例如 a = 1这种就属于store指令,所以归纳起来,乱序类型有四种:

  • store-load乱序:load操作先比store操作完成
  • store-store乱序(store1-store2):store2操作先比store1操作完成
  • load-load乱序(load1-load2):load2操作先比load1操作完成
  • load-store乱序:store操作先比load操作完成

按照可能会出现的乱序类型数量来划分,CPU的内存一致性模型大概有以下几种:

  • 顺序存储模型(sequential consistency model,简写SC),没有任何乱序
  • 完全存储定序(total store order,简写TSO),会出现store-load乱序
  • 部分存储定序(part store order,简写PSO),会出现store-load、store-store乱序
  • 宽松存储模型(relax memory order,简写RMO),四种乱序类型都会出现

在这里插入图片描述

我们常用的x86架构CPU,属于TSO一致性模型,仅存在store-load乱序。

除了CPU有内存模型,高级语言也会有自己的内存模型。

但要注意的是,即使CPU没有对指令进行重排序,最终也仍有可能会出现乱序现象。例如CPU严格按照 store -> load 的顺序执行指令,但因为有 store buffer 的存在,store操作有可能会延迟一段时间才刷出到cache,而MESI一致性协议的作用范围是各级cache,不包括store buffer,只有刷出到cache其它CPU才能读到新的值,因此从cache的视角看,事件顺序有可能会变成 load -> store,具体见下文2.3可见性章节。

通过本节,我们知道:

  • 编译器、CPU有可能会为了提高性能,对指令的执行顺序进行调整
  • 在单线程环境下,指令乱序执行不会影响程序最终结果,但在多线程环境下就不保证了
  • CPU只会对没有依赖关系的指令进行重排序
  • 影响指令执行顺序的因素有很多,编译器优化策略、CPU优化策略、CPU架构等等
  • 即使不对指令进行重排序,仍有可能会出现类似重排序的现象

2.2 原子性

原子性指的是一个或多个操作要么全部执行成功,要么全部执行失败,而且其它线程不能读取到中间态结果。

先看看如果一个操作不是原子性的,会发生什么后果。

后果1:其它线程会读到中间态结果:

type UserInfo struct {Name string
}var instance *UserInfofunc main() {instance = &UserInfo{Name: "tim"}
}

instance = &UserInfo{Name: "tim"}这句代码看起来只有一句,但实际执行起来并不是原子性的,它分为多个步骤:

  1. 先 new 一个 UserInfo
  2. 然后设置 Name="tim"
  3. 最后把 new 的对象赋值给instance

既然不是原子性的,那么就给“指令重排”提供了机会,上面的执行步骤可能会重排成:

  1. 先 new 一个 UserInfo
  2. 然后把 new 的对象赋值给instance
  3. 最后设置 Name="tim"

假设这段代码是线程A在执行,在执行完第2个步骤后,突然线程B来访问这个instance,这时候线程B读取到的instance.Name将会是个空字符串(因为线程A的第3步还没执行),线程B读取到了一个中间态的结果。

后果2:修改结果被覆盖

假设有变量count,现在我们要对其执行count++操作,它也不是原子性的,分为三个步骤:

  1. 读取变量count所在的cache line到CPU寄存器
  2. 执行+1操作
  3. +1后的结果回写到L1缓存的cache line(不考虑store buffer)

这个过程称为 RMW (Read-Modify-Write),假设现在有两个线程同时执行count++操作:
在这里插入图片描述

可见,最后count的值并不是预期的2,而是1

上面是两个线程并行(两个线程在不同的CPU核心上运行)的结果,如果让他们变成并发(两个线程在同一个CPU核心运行),由于CPU是抢占式调度线程的,在线程A执行到一半的时候,可能会被切换去执行线程B,所以最终仍会导致同样的结果。

思考下,如果我们要解决上述原子性问题,至少要做哪些工作?

i++举例,让它原子化至少要确保:

  1. 计算开始前,要读取到最新的i
  2. i所在的cache区域要独占,如果其它CPU核心有相同的cache副本,要让它们变为无效
  3. 从开始到结束期间,其它线程不能读写i所在的cache区域(类似加互斥锁),即各个原子操作要串行化
  4. 计算结束后,要把新的值刷出到cache,然后借助MESI一致性协议,让其它CPU核心能看到新的值

下面第三章讲述的LOCK前缀指令能实现这些要求,所以LOCK前缀指令可以帮我们实现原子操作。

2.3 可见性

可见性问题是由 store buffer 和 invalidate queue引出的。

store buffer的引入,使得Store操作的结果不能及时被其它CPU核心发现,这种称为可见性问题

而 invalidate queue 的引入则更加加剧了这种现象,导致即使CPU已经将store buffer全部刷出到cache,其它CPU核心依然有可能发现不了新的值。

  • store buffer 和 invalidate queue 只有本地核心可以访问,其它CPU核心访问不到
  • 从缓存中读取cache line时,会优先检索本地store buffer中有没有相同的cache line,有的话直接从store buffer获取(这种优化策略称为Store-Buffer Forwarding),但不会优先检索invalidate queue
  • 如果cache line在缓存里的状态是独占(M或者E),则CPU会直接将结果写入到cache,而不是先写入到store buffer
  • 如果将结果写入store buffer,则会广播invalidate消息(cache line的状态暂时不变),收到各个核心的invalidate ack响应后,才会将store buffer里的暂存结果刷出到cache(状态改为M)
  • 将结果写入cache时,如果cache line已经失效,会重新读取cache line(发起read invalidate请求),读取后将结果写入,状态改为M

问:既然store buffer不与其它CPU核心共享,那线程A写入store buffer后,被系统调度到其它核心运行了,此时怎么同步store buffer到其它核心?
答:这种情况不需要程序员担心,操作系统会帮我们处理好数据的同步。参阅这里

1)store buffer(FIFO)引起的类似store-load乱序现象

在这里插入图片描述

从时间线上来看,我们看到是先发生了store操作(将a修改为1),然后才发生的load操作(读取b)。但是因为有store buffer的存在,a = 1是在load操作后面才写入到L1缓存的(写入到缓存后其它CPU核心才能读取到新的值),假设我们设定“写入到缓存”才算真正的完成store操作,那么从cache的视角看,此时就发生了store-load乱序:load操作先比store操作完成了。

注意,这里CPU和编译器并没有对指令进行重排序,但还是出现了重排序的现象,这种称为内存重排序(Memory Reordering),要注意跟其它两种重排序区分(CPU重排序、编译器重排序)

因 store buffer 和 invalidate queue 产生的可见性问题,一般不会持续太久,因为store buffer终究会刷出到cache,invalidate queue终究会被消费清空。

比较可怕的是编译器的激进优化,例如上文2.1章节第一个代码示例中的for !done {}这个循环,编译器可能会优化成:读取done变量到CPU寄存器后,就一直使用寄存器里的值,即使你在其它线程将donefalse修改为true,CPU也不会从cache里重新读取新的值,导致循环不会终止。

2)store buffer(非FIFO)引起的类似store-store乱序现象

上一个例子里的store buffer是FIFO(first in first out)的,如果改成非FIFO,会多出一种store-store乱序现象。
在这里插入图片描述
从时间线上来看,是先发生store1操作(a = 1),然后再发生store2操作(b = 1)。但是因为store buffer非FIFO的特性,导致store2操作先写入到了缓存,然后才写入store1。从cache的视角看,发生了类似store-store乱序的现象。

三、CPU级别的解决方案 - 内存屏障

要解决CPU的各种乱序、可见性问题,需要用到硬件级别的内存屏障(Memory Barrier)

内存屏障的作用:

  • 防止屏障前后的指令越过屏障,导致重排序
  • 保证数据的可见性

不同架构的CPU会提供不同的内存屏障指令,比如 Intel x86架构的CPU就提供了以下四种内存屏障指令。

3.1 sfence(Store Barrier)

  • sfence 前面的 store 操作不会被调度到 sfence 后面
  • sfence 后面的 store 操作不会被调度到 sfence 前面
  • 清空store buffer,全部刷出到主内存(注意是主内存,不是cache),使 sfence 前面的所有store操作变成全局可见

3.2 lfence(Load Barrier)

  • lfence 前面的 load 操作不会被调度到 lfence 后面
  • lfence 后面的 load 操作不会被调度到 lfence 前面
  • 清空 invalidate queue,使得 lfence 后面的 load 操作可以读到最新的cache值

3.3 mfence(Full Barrier)

  • mfence 前面的 store 操作不会被调度到 mfence 后面,后面的 store 操作不会被调度到 mfence 前面
  • mfence 前面的 load 操作不会被调度到 mfence 后面,后面的 load 操作不会被调度到 mfence 前面
  • 清空store buffer,全部刷出到主内存(注意是主内存,不是cache),使 mfence 前面的所有store操作变成全局可见
  • 清空 invalidate queue,使得 mfence 后面的 load 操作可以读到最新的cache值

问题1:为什么mfence != sfence + lfence?

因为 sfence 和 lfence 本身就有可能乱序,例如:

mov addr, eax // 将eax寄存器中的数据保存到内存地址addr,属于store操作
sfence
lfence
mov eax, addr // 将内存地址addr的数据加载到eax寄存器中,属于load操作

最终的执行顺序有可能会变成:

lfence
mov eax, addr // loadmov addr, eax // store
sfence

可见,lfence 和 sfence 在此处已经发挥了它的作用,store操作没有跑到 sfence 的后面去,load操作也没有跑到 lfence 的前面去,但是 store-load 的执行顺序却变成了load-store,产生了乱序,因此,阻止 store-load 乱序只能用 mfence

3.4 用LOCK前缀修饰指令

在一条指令前面添加LOCK前缀,可以使这条指令的执行具有原子性,支持使用LOCK前缀的指令有ADD/OR/AND/SUB/INC/NOT等,另外XCHG/XADD自带LOCK效果。

具体做法是在执行指令前,向CPU发出LOCK#信号,CPU接收到LOCK#信号后,会锁定总线,锁定期间其它CPU均不能通过总线访问内存,性能开销比较大。

后来又增加了只锁定cache line的功能,开销相比锁定总线小了很多,但是锁定cache line要符合一定的条件,如果不符合条件,会降级为锁定总线。

锁定流程见下图:
在这里插入图片描述

锁定总线或cache line后:

  • 其它线程不可再读写已锁定的内存区域,直至锁定结束,可以确保指令执行的原子性;
  • 禁止该指令前后的指令重排序,类似mfence内存屏障的作用,可以确保指令执行的有序性;
  • 锁定结束后,还会将store buffer刷出到cache,确保变量修改后的可见性;

问题1:LOCK前缀指令跟mfence之间的区别是什么?

mfence要求修改过的值必须要写回到主内存,仅写回到cache是不行的,这样才能做到全局可见(不仅仅是CPU各个核心可见,还要求其它设备可见,比如显卡);
而LOCK前缀指令结束后,修改后的新值写回到cache就可以,没有强制要求写回到主内存。

Golang的 sync.atomic 包里的方法就用到了LOCK前缀指令,不要看到atomic这个单词,就以为这些方法只能确保原子性,其实它还能确保有序性、可见性。

除了CPU级别的内存屏障,还有编译器级别的内存屏障

四、高级语言级别的解决方案 - 内存模型

4.1 内存模型

我们从上一章节得知,单单x86架构的CPU就有4种内存屏障指令,如果加上其它架构的,各种指令就五花八门了,如果让程序员直接使用CPU级别的内存屏障的话,学习成本会很高,很难写出跨平台的程序。因此 Golang 给我们设计了一套内存模型,内存模型屏蔽了底层CPU的细节,优点:

  • 免去程序员使用内存屏障的心智负担,更加容易开发出跨平台的程序;
  • Golang在底层会帮我们合理正确的使用内存屏障,在保障有序性、原子性、可见性的同时,对程序性能也不会有太大的影响;

内存模型定义了在什么情况下,可以确保协程B可以读取到协程A对共享变量v写入的值,这里的“什么情况”指的是 happens-before 规则,我们只需要写出满足 happens-before 规则的代码,剩下的其它什么有序性、可见性问题内存模型会帮我们处理好。

4.2 happens-before规则

单纯看字面意思,happens-before是用于描述两件事的发生顺序的,但其实它还暗含着可见性的规定,这一点一定要注意。

举例,事件e1 happens-before e2,它的含义是:

  • e1事件发生在e2事件之前(有序性)
  • e1事件的操作结果,对于e2可见(可见性)

happens-before还有传递性的特点,如果用>符号表示happens-before,那么有以下关系:
如果 A < B,C < D,且 B < C,那么 A < D

在这里插入图片描述

happens-before下面又细分为 sequenced-before 和 synchronized-before 两种类型,同一协程内的 happens-before 称为 sequenced-before,不同协程间的 happens-before 称为 synchronized-before,见上图。

在只有一个 Go协程的内部,sequenced-before的顺序就是代码的书写顺序。当协程不止一个时,例如协程1协程2共同读写一变量v协程1负责读(事件r),协程2负责写(事件w),要想确保协程1能读到协程2写入的值,需要满足:

  • w synchronized-before r
  • wr之间不允许有其它对同一变量v写入的事件发生

4.3 同步事件

Golang的内存模型已经为我们定义好了一些同步事件,例如channel、Locks、Atomic Values等等,同时Golang承诺这些同步事件遵守 hanppens-before 规则,我们只需应用好这些事件即可。

这些事件不再详细赘述,网上资料较多,可参阅这些文章:

  • Golang 并发编程核心—内存可见性
  • The Go Memory Model
  • Memory Order Guarantees in Go

问题1:sync.Mutex和sync.atomic的区别?

相同点:

  • 两者均能保证原子性、有序性、可见性

差异点:

  • atomic只能保护单个变量修改的原子性,而Mutex可用于保护一段代码(临界区)的原子性
  • atomic使用的是LOCK前缀指令(CPU级别的锁)来确保原子性,而Mutex是语言级别的高级锁,实现中也使用到了atomic
  • 一般来说,atomic的性能要比Mutex高

参阅Understanding Golang’s Atomic Package and Mutexes

问题2:sync.atomic的happens-before 语义是什么?

Since Go 1.19, the Go 1 memory model documentation formally specifies that all atomic operations executed in Go programs behave as though executed in some sequentially consistent order. If the effect of an atomic operation A is observed by atomic operation B, then A is synchronized before B.

五、没有正确同步的代码示例及修复方法

后面补充…

六、参阅

  • X86 平台 volatile 与 StoreLoad 乱序描述与验证
  • Why is (or isn’t?) SFENCE + LFENCE equivalent to MFENCE?
  • 聊聊原子变量、锁、内存屏障那点事
  • Locks实现:背后不为人知的故事
  • Lock前缀指令带来的缓存行锁定有什么作用?

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

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Netty学习——实战篇4 Netty开发Http服务实战、ByteBuf使用、开发群聊系统 备份

1 Netty开发Http服务实战 &#xff08;1&#xff09;Netty服务器监听8000端口&#xff0c;浏览器发出请求“http://localhost:8000” &#xff08;2&#xff09;服务器可以回复消息给客户端&#xff0c;“你好&#xff0c;我是服务器”,并对特定请求资源进行过滤。 HttpServer…

冯诺依曼与进程【Linux】

文章目录 冯诺依曼体系结构&#xff08;从硬件的角度描述&#xff09;冯诺依曼体系结构&#xff08;从软件的角度描述&#xff09;操作系统&#xff08;软件&#xff09;理解管理系统调用和库函数进程查看进程的两种方式 通过系统调用获取进程的PID和PPID通过系统调用创建进程-…

Linux之 USB驱动框架-USB总线核心和主控驱动(4)

一、USB设备描述符 一个USB设备描述符中可以有多个配置描述符&#xff0c;即USB设备可以有多种配置&#xff1b;一个配置描述符中可以有多个接口描述符&#xff0c;即USB设备可以支持多种功能&#xff08;接口&#xff09;&#xff1b;一个接口描述符中可以有多个端点描述符。 …

SpringBoot项目创建及简单使用

目录 一.SpringBoot项目 1.1SpringBoot的介绍 1.2SpringBoot优点 二.SpringBoot项目的创建 三.注意点 一.SpringBoot项目 1.1SpringBoot的介绍 Spring是为了简化Java程序而开发的&#xff0c;那么SpringBoot则是为了简化Spring程序的。 Spring 框架&#xff1a; Spring…

linux 自定义命令/别名

参考资料 Linux(Ubuntu)自定义命令的使用Linux/Ubuntu系统自定义Shell命令Ubuntu/Linux 操作系统 自定义命令 目录 一. 为路径取别名二. 修改.profile文件2.1 .profile简介2.2 需求2.3 修改.profile文件 三. 创建软链接 一. 为路径取别名 ⏹需求&#xff1a;有一个work文件夹…

Unity 获取RenderTexture像素颜色值

拿来吧你~ &#x1f9aa;功能介绍&#x1f32d;Demo &#x1f9aa;功能介绍 &#x1f4a1;不通过Texture2D 而是通过ComputerShader 提取到RenderTexture的像素值&#xff0c;效率有提升哦&#xff01; &#x1f4a1;通过扩展方法调用&#xff0c;方便快捷&#xff1a;xxxRT.G…

GTX312L【超强抗干扰、12通道电容式触摸芯片】

GTX312L是韩国GreenChip推出的一款12通道电容式触摸IC&#xff0c;具备自动灵敏度校准、超强抗干扰能力&#xff0c;可抗特斯拉&#xff08;小黑盒&#xff09;线圈干扰&#xff0c;可完美Pin to Pin替换TSM12&#xff1b;支持单键/多点触控。 产品描述&#xff1a; 该芯片供…

PHP反序列化命令执行+PHP反序列化POP大链 +PHP反序列化基础

[题目信息]&#xff1a; 题目名称题目难度PHP反序列化命令执行1 [题目考点]&#xff1a; 反序列化命令执行&#xff0c;获取题目flag。[Flag格式]: SangFor{t5euvZ_OB8Jd_h2-}[环境部署]&#xff1a; docker-compose.yml文件或者docker tar原始文件。 docker-compose up …

HADOOP大数据处理技术9-JavaSe

心若有阳光 你便会看见这个世界有那么多美好值得期待和向往 ​ 2024/4/9 13.static 用于修饰属性和方法 static属性通过类名访问 1&#xff09;static实现内存共享 bean1和bean2的内存是互相独立的 怎么实现内存共享呢&#xff1f; 共享内存​public class Comm { public…

Java中的装箱和拆箱

本文先讲述装箱和拆箱最基本的东西&#xff0c;再来看一下面试笔试中经常遇到的与装箱、拆箱相关的问题。 目录&#xff1a; 装箱和拆箱概念 装箱和拆箱是如何实现的 面试中相关的问题 装箱和拆箱概念 Java为每种基本数据类型都提供了对应的包装器类型&#xff0c;至于为…

git报错

这里写自定义目录标题 git报错Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 有一个原因就是在github上设置对应密钥时&#xff0c;有一个key获取应该设置为…

在Debian 12系统上安装Docker

Docker 在 Debian 12 上的安装 安装验证测试更多信息 引言 在现代的开发环境中&#xff0c;容器技术发挥着至关重要的作用。Docker 提供了快速、可靠和易于使用的容器化解决方案&#xff0c;使开发人员和 DevOps 专业人士能够以轻松的方式将应用程序从一个环境部署到另一个环…

Ubuntu20从0开始选择合适版本手动安装cuda,torch-geometric,jax

一个全新的ubuntu20台式机&#xff0c;在Additional Drivers安装nvidia-470-server&#xff08;一开始安装450&#xff0c;cunda版本只能到11.0&#xff0c;torch有些库用不了&#xff0c;可以直接切换点击Apply Changes重启就行&#xff09; nvidia-smi查看CUDA Version可到…

Docker之自定义镜像上传至阿里云

一、Alpine介绍 Alpine Linux是一个轻量级的Linux发行版&#xff0c;专注于安全、简单和高效。它采用了一个小巧的内核和基于musl libc的C库&#xff0c;使得它具有出色的性能和资源利用率。 Alpine Linux的主要特点包括&#xff1a; 小巧轻量&#xff1a;Alpine Linux的安装…

Android 自定义SwitchPreference

1. 为SwitchPreference 添加背景&#xff1a;custom_preference_background.xml <?xml version"1.0" encoding"utf-8"?> <selector xmlns:android"http://schemas.android.com/apk/res/android"><item><shape android:s…

计算机视觉动作识别——YOWO用于实时时空动作定位与识别的算法解析

摘要 时空动作定位要求将两种信息源整合到设计的架构中&#xff1a;(1) 来自先前帧的时间信息和(2) 来自关键帧的空间信息。当前的最先进方法通常使用单独的网络提取这些信息&#xff0c;并使用额外的机制进行融合以获得检测结果。YOWO是一个用于视频流中实时时空动作定位的统…

rk3588 安卓调试

rknn装上了android系统&#xff0c;用type-c usb连接上电脑&#xff0c;设备管理器发现了rk3588&#xff0c;但是Android Studio没有发现设备 后来怀疑是驱动没有安装&#xff0c;我用的驱动下载地址&#xff1a; 瑞芯微Rockchip驱动安装助手(适用于RK3308 RK3399等) Mcuzone…

【TensorRT】TensorRT C# API 项目更新 (1):支持动态Bath输入模型推理(下篇)

4. 接口应用 关于该项目的调用方式在上一篇文章中已经进行了详细介绍&#xff0c;具体使用可以参考《最新发布&#xff01;TensorRT C# API &#xff1a;基于C#与TensorRT部署深度学习模型》&#xff0c;下面结合Yolov8-cls模型详细介绍一下更新的接口使用方法。 4.1 创建并配…

Java SpringBoot基于微信小程序的高速公路服务区充电桩在线预定系统,附源码

博主介绍&#xff1a;✌IT徐师兄、7年大厂程序员经历。全网粉丝15W、csdn博客专家、掘金/华为云//InfoQ等平台优质作者、专注于Java技术领域和毕业项目实战✌ &#x1f345;文末获取源码联系&#x1f345; &#x1f447;&#x1f3fb; 精彩专栏推荐订阅&#x1f447;&#x1f3…

中国传媒网CEO徐晓艺:第六届世界布商大会启幕 共探全球纺织业转型与合作

日前,2023国际纺织制造商联合会中国绍兴柯桥大会、2023第六届世界布商大会在浙江绍兴柯桥启幕,来自全球55个国家和地区的纺织行业代表围绕“绿色、循环、数字化——纺织工业新动源”主题,共探全球纺织业转型与合作。 “当前,纺织服装行业进入变革期,以数字、绿色为特征的产业变…