Go面试看这里了~（五）-Mutex锁相关

最新推荐文章于 2025-04-13 17:17:27 发布
原创 最新推荐文章于 2025-04-13 17:17:27 发布 · 487 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#Go #mutex #面试

原文地址：Go面试看这里了~（五）

1、mutex的正常模式和饥饿模式？

正常模式（非公平锁）：所有等待锁的goroutine按先进先出的顺序等待，唤醒的goroutine不会直接拥有锁，而是回合新请求锁的goroutine竞争锁的拥有权，新请求锁的goroutine有优势（1、正在CPU上执行；2、可能同时拥有好几个锁），所以刚刚唤醒的goroutine很大可能在竞争锁时失败，此时，这个刚唤醒的goroutine会加入到等待队列的前面，如等待的goroutine等待时间超过1ms没获取到锁，此goroutine将会把锁转变为饥饿模式。

饥饿模式（公平锁）：是为了解决等待goroutine队列过长问题，此模式下，直接由unlock将锁交给队列中排在第一位的goroutine，同时，新进来的goroutine不会参与抢锁，也不会进入自旋状态，会直接进入队列尾部，如此就解决了老goroutine一直抢不到锁的场景。

饥饿模式的触发条件：

  1. goroutine等待锁时间超过1ms。

  2. 当前队列只剩下一个goroutine。

总结来看的话，正常模式下的性能是最好的，goroutine可连续多次获取锁，饥饿模式解决了取锁公平的问题，但是性能会下降，是性能和公平性的一个平衡模式。

2、mutex允许自旋的条件？

  1. 锁已被占用，且不处于饥饿模式。

  2. 积累的自旋次数小于最大自旋次数（active_spin=4）。

  3. CPU核数大于1。

  4. 有空闲的p。

  5. 当前goroutine所挂载的p下的本地待运行队列为空。

3、RWMutex的实现？

通过积累readerCount读锁数量来进行控制，当有一个写锁时，会将读锁数量设置为-1<<30，目的是让新进入的读锁等待写锁释放之后通知读锁，写锁也会等待之前的读锁释放完毕之后，才会进行后面的操作，写锁释放之后，会将值重新加上1<<30，并通知刚刚新进入的读锁（rw.readerSem），两者互相限制。

4、RWMutex的注意事项？

  1. RWMutex是单写多读锁，该锁可加多个读锁或一个写锁。

  2. 读锁占用情况下会阻止写，不阻止读，多个goroutine可同时获取读锁。

  3. 写锁会阻止其它goroutine（无论读写）进来，整个锁由该goroutine独占。

  4. 适用于读多写少场景。

  5. RWMutex类型变量的零值为未锁定状态的互斥锁。

  6. RWMutex首次被使用后就不能再被拷贝。

  7. RWMutex读锁或写锁在未锁定状态时，解锁会引发panic。

  8. RWMutex一个写锁去锁定临界区的共享资源，如临界区的共享资源已被锁定，进行此操作的goroutine将会被阻塞到解锁。

  9. RWMutex读锁不要用于递归调用，易产生死锁。

  10. RWMutex锁定状态与特定goroutine无关，一goroutine可RLock（Lock），另一goroutine可RUnlock（Unlock）。

  11. 写锁被解锁后，所有因操作锁定读锁而被阻塞的goroutine会被唤醒，并都可成功锁定读锁。

  12. 读锁被解锁后，在未被其它读锁锁定前提下，所有因操作锁定写锁而被阻塞的goroutine，其中等待时间最长的一个goroutine会被唤醒。

5、Cond是什么？

Cond实现一种条件变量，可用在多个reader等待共享资源的ready的场景（如只有一读一写，一个锁或channel就搞定），每个Cond都会关联一个Lock（*sync.Mutex或*sync.RWMutex），当修改条件或调用wait时，必须加锁，保护condition。

6、Broadcast和Signal的区别？

func (c *Cond) Broadcast()func (c *Cond) Signal()

Broadcast会唤醒所有等待C的goroutine，调用Broadcast可加锁，也可不加。

Signal只唤醒一个等待C的goroutin，调用Signal时可加锁，也可不加。

7、Cond中Wait的使用？

func (c *Cond) Wait()c.L.Lock()for !condition() { c.Wait()}... make use of condition ...c.L.Unlock()

wait会自动释放c.L并挂起调用者的goroutine，之后恢复执行，wait会在返回时对c.L加锁，除非被Broadcast或Signal唤醒，否则wait不会返回。

由于wait第一次恢复时，c.L并未加锁，所以当wait返回时，调用者不能假定条件为真，取而代之的是，调用者应在循环中调用wait。

简单来讲，想使用condition，就得加锁。

至此，本次分享就结束了，后期会慢慢补充。

以上仅为个人观点，不一定准确，能帮到各位那是最好的。

好啦，到这里本文就结束了，喜欢的话就来个三连击吧。

扫码关注公众号，获取更多优质内容。

Golang面试题三（互斥锁）
qq_22321199的专栏
04-15 2184
sync.Once是一种用于确保一段代码在整个程序生命周期中仅被执行一次的同步工具。通过封装待执行的代码为一个回调函数，并通过调用，可以确保即使在并发环境下，该回调函数也能安全、高效地仅被执行一次。sync.Once常用于实现单例模式、延迟初始化、一次性设置全局状态等场景数据结构m Mutex原子操作（Atomic Operation）是指在计算机科学中，一个操作在执行过程中不会被其他操作（包括来自其他线程、进程或处理器核心的干扰）中断，能够以不可分割的单位从开始到结束完整地执行完毕。
Go面试题(四)：锁的实现原理--sync.RWMutex 篇
小道哥的博客
11-27 936
Go面试题(四)：锁的实现原理–sync.RWMutex 篇 大家好，我是小道哥。 上一篇为大家介绍了Go中的sync.Mutex互斥锁的数据结构及实现原理，今天继续为大家介绍另外一种常用的锁，那就是sync.RWMutex读写锁。 读写锁的使用 读写互斥锁sync.RWMutex不限制对资源的并发读，但是读写，写写操作无法并行执行。 读写锁一共有四个函数： RLock(): 申请读锁 RUnlock(): 解除读锁 Lock(): 申请写锁 Unlock(): 解除写锁 实现原理 sync.RWMut
go面试题
gaoqiao1988的专栏
03-12 396
需要注意的是，不同资料对于Mutex的具体工作模式描述有所差异，尤其是关于饥饿模式的实现和触发条件，在不同的Go语言版本中可能有不同的机制。例如，有的资料提到在特定条件下（如等待时间超过某个阈值）进入饥饿模式，有的则表示在特定版本后调整了Mutex的行为以更好地防止饥饿情况。实际行为应参考最新的官方文档或源代码来确认。
GoLang之Mutex的正常模式和饥饿模式
weixin_52690231的博客
05-11 2926
GoLang之Mutex的正常模式和饥饿模式
go-mutex的模式
tsxylhs的博客
07-22 389
go-mutex的模式 go-mutex的模式 1. 正常模式 2. 饥饿模式 mutex是golang提供的基础并发原语，可以帮助我们处理多goruntine并发访问共享资源的问题。每个goruntine都要再获取到锁之后才能操作共享资源，完成操作释放锁，保证了共享资源的读写安全性。 但这种方式也可能带来一些问题：一些悲惨的goruntine一直获取不到锁，导致业务逻辑不能继续完...
自旋锁和互斥锁实例_Golang并发编程之互斥锁、读写锁详解
weixin_30000283的博客
12-27 382
点击上方 "程序员小乐"关注, 星标或置顶一起成长 每天凌晨00点00分, 第一时间与你相约 每日英文 It's so hard to tell someone how you really feel about them when you're too afraid of losing what you already have. 有时候，要坦白对某个人的感觉真的太难了，因为太害怕连现在这种关...
golang-锁机制 实现原理 如何检测死锁 mutex互斥锁、读写锁、sema、饥饿模式 可重入锁、cond等
最新发布
S_ZaiJiangHu的博客
04-13 1052
Go sync 包提供了两种锁类型：互斥锁 sync.Mutex 和读写互斥锁 sync.RWMutex，都属于悲观锁。
精选资源
桫哥-GOlang基础-x1_Go语言面试题_第1辑
06-12
在本资源"桫哥-GOlang基础-x1_Go语言面试题_第1辑"中，我们可以探索Go语言的基础知识和面试中常见的问题。Go语言，又称为Golang，是Google开发的一种静态类型的、编译式的、并发型且具有垃圾回收功能的编程语言。它...
【面试题】Golang 锁的相关问题(第七篇)
abclui的专栏
07-16 1335
Go语言的Mutex主要有锁定状态、未锁定状态、唤醒状态（在内部实现中可能用于通信）、饥饿状态以及等待者计数等几种状态。这些状态共同协作，确保了Mutex能够高效地控制对共享资源的访问，同时避免了死锁和条件竞争等并发问题。需要注意的是，上述状态是基于Go语言sync包中Mutex的通用实现和描述，不同版本的Go语言或不同的锁实现可能会有所差异。因此，在具体使用时，建议参考Go语言的官方文档或源代码以获取最准确的信息。正常模式和饥饿模式是Mutex在Go语言中提供的两种不同的工作模式，它们各有优缺点。
Go面试看这里了~（四）
luyaran的博客
11-16 867
原文地址：Go面试看这里了~（四） 1、map底层实现？ map底层实现是一个散列表，因此实现map的过程就是实现散列表的过程，其中主要有两个结构体，hmap和bmap，来看下源码： //map结构体是hmap，是hashmap的缩写type hmap struct { count int //元素个数，调用len(map)时直接返回 flags uint8 //标志map当前状态,正在删除元素、添加元素..... B
Golang 基于etcd的分布式锁 - 公平锁和非公平锁
Quiteeom的博客
06-27 1232
～目录～【Golang】基于 etcd 的分布式公平锁和非公平锁目的设想具体实现1. 首先把接口都定义好2. etcd 实现1. 存储的KV方案2. 租约方案3. TryLock 非公平2. TryLock 公平3. Lock 非公平4. Lock 公平5. 最终etcd实现代码运行结果公平锁非公平锁还有很多需要改进的地方 【Golang】基于 etcd 的分布式公平锁和非公平锁 Golang 学习笔记 目的 首先，要确认好希望实现的东西 希望实现一个分布式锁 可以实现公平锁和非公平锁 使用起来不
锁：可重入锁，可中断锁，公平锁，读写锁
Yu的博客
09-02 910
1.可重入锁： 如果锁具备可重入性，称为可重入锁。 Synchronized和ReentrantLock是可重入锁，可重入性表明了锁是基于线程的分配，而不是基于方法调用的分配。    2.可中断锁：  Synchronized是不可中断锁，Lock是可中断的锁。 如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等了，想先处理其他事情，可以让他
java并发库 Lock 公平锁和非公平锁
I will never let you go
11-26 423
          jdk1.5并发包中ReentrantLock的创建可以指定构造函数的boolean类型来得到公平锁或非公平锁，关于两者区别，java并发编程实践里面有解释 公平锁：   Threads acquire a fair lock in the order in which they requested it 非公平锁：a nonfair lock permits ba...
说一下公平锁/非公平锁？
qq_46138725的博客
06-14 139
1.公平锁是指多个线程按照申请顺序来获取锁 非公平锁是指多个线程获取所得顺序并不是按照申请锁顺序,有可能后申请的线程比先申请的线程优先获取锁,有可能,会造成优先级反转或者饥饿现象. 对于Java ReentrantLock而言,通过构造函数指定该锁是否为公平锁,默认是非公平锁.非公平锁的有点在于吞吐量比公平锁大. 4.对于Synchronized而言,也是一种非公平锁,由于其不像ReentrantLock是通过AQS来实现的线程调度,所以并没有任何办法使其变成公平锁 ...
007-Golang1.17源码分析之mutex
仟玑的博客
02-21 275
Golang1.17源码分析之mutex-007 Golang1.17 学习笔记007 源代码：sync/mutex.go 数据结构： const ( // 锁标识位(state的最后一位) // Mutex.state & mutexLocked==1表示已经上锁；Mutex.state & mutexLocked==0表示已经未锁 mutexLocked = 1 << iota // mutex is locked // 是否存在运行中的协程（
Golang Mutex 正常模式 vs 饥饿模式
m0_68251640的博客
04-08 448
在正常模式下，等待者以FIFO顺序排队，但是唤醒的等待者并不拥有锁，它与新到达的goroutine竞争所有权。新到达的goroutine具有优势——它们已经在CPU上运行，而且可能有很多个，因此被唤醒的等待者有很大的机会输掉竞争。正常模式的性能要比饥饿模式好得多，因为goroutine可以连续多次获取mutex，即使有阻塞的等待者。如果等待者接收到mutex的所有权并发现(1)它是队列中的最后一个等待者，或者(2)它等待的时间少于1毫秒，则将mutex切换回正常操作模式。
GoLang之Mutex底层系列一(锁、正常模式、饥饿模式)
weixin_52690231的博客
06-14 2081
GoLang之Mutex底层系列一(锁、正常模式、饥饿模式)
Golang基础-mutex的正常模式和饥饿模式2
qq_38609643的博客
01-07 1438
在正常的锁定模式下，
【Go】Mutex锁相关 ③
王大阳的博客
08-17 999
Mutex 就实现了这个接口，Lock请求锁，Unlock释放锁Locked：表示该 mutex 是否被锁定，0 表示没有，1 表示处于锁定状态；Woken：表示是否有协程被唤醒，0 表示没有，1 表示有协程处于唤醒状态，并且在加锁过程中；Starving：Go1.9 版本之后引入，表示 mutex 是否处于饥饿状态，0 表示没有，1 表示有协程处于饥饿状态；Waiter: 等待锁的协程数量。方法解析。
golang mutex 面试题
03-18
### Golang Mutex 面试题及相关答案 在并发编程领域，`sync.Mutex` 是 Go 中用于保护共享资源免受竞争条件影响的重要工具之一。以下是几个常见的关于 `Mutex` 的面试题及其解答： #### 1. **什么是互斥锁 (Mutex)，以及它在 Go 中的作用是什么？** 互斥锁是一种同步原语，用于防止多个 Goroutine 同时访问共享数据结构[^2]。Go 提供了 `sync.Mutex` 类型来实现这一功能。通过调用其方法 `Lock()` 和 `Unlock()` 可以分别获取和释放锁。 ```go var mu sync.Mutex mu.Lock() // 获取锁 // 访问共享资源 mu.Unlock() // 释放锁 ``` #### 2. **为什么需要使用 Mutex 来解决竞态条件问题？** 当多个 Goroutine 并发运行并尝试修改同一个变量时，可能会发生不可预测的行为。这种现象称为竞态条件[^3]。为了确保程序的一致性和正确性，在任何时间点只允许一个 Goroutine 修改该变量，这就是 Mutex 发挥作用的地方。 #### 3. **下面这段代码存在什么潜在问题？如何修复这个问题？** ```go package main import ( "fmt" ) func main() { var count int for i := 0; i < 1000; i++ { go func() { count++ }() } fmt.Println(count) } ``` 上述代码中的主要问题是未加锁的情况下对全局变量 `count` 进行操作可能导致竞态条件[^4]。可以通过引入 `sync.Mutex` 解决此问题: ```go package main import ( "fmt" "sync" ) func main() { var wg sync.WaitGroup var mu sync.Mutex count := 0 for i := 0; i < 1000; i++ { wg.Add(1) go func() { defer wg.Done() mu.Lock() count++ mu.Unlock() }() } wg.Wait() fmt.Println("Final Count:", count) } ``` 这里增加了 WaitGroup 确保主线程等待所有子线程完成执行后再打印最终计数值；同时利用 Mutex 锁定每次更新过程从而避免冲突。 #### 4. **RWMutex 和 Mutex 有什么区别？什么时候应该选择 RWMutex 而不是普通的 Mutex？** 标准库还提供了另一种类型的读写锁——`sync.RWMutex` ，它可以允许多个读者或者单个写者持有锁定状态[^5]。如果场景中有大量读取而很少写的操作，则可以考虑采用 RWMutex 提高性能。 - 使用普通 Mutex : 所有请求都需要排队等候独占权限。 - 使用 RWMutex ：支持多路并发读取而不阻塞其他读取动作直到某个写入开始为止。 示例对比两者差异如下所示 : ```go type Counter struct { mutex *sync.Mutex rwmtx *sync.RWMutex value int } func NewCounter(useRW bool) *Counter { if useRW { return &Counter{rwmtx: new(sync.RWMutex)} } else { return &Counter{mutex: new(sync.Mutex)} } } func (c *Counter) Inc() { if c.mutex != nil{ c.mutex.Lock(); defer c.mutex.Unlock(); }else{ c.rwmtx.Lock();defer c.rwmtx.Unlock(); } c.value +=1; } func (c *Counter) Get()int{ if c.mutex!=nil{ c.mutex.Lock();defer c.mutex.Unlock(); }else{ c.rwmtx.RLock();defer c.rwmtx.RUnlock(); } return c.value ; } ``` 在这个例子中定义了一个简单的计数器类，根据初始化参数决定是否启用 RW 版本的控制逻辑。 --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

luyaran

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值