golang sync.Mutex解读

最新推荐文章于 2024-05-17 10:04:07 发布
最新推荐文章于 2024-05-17 10:04:07 发布
阅读量115 收藏
点赞数
文章标签： golang
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_73129504/article/details/133840909
版权

golang sync.Mutex解读

Mutex 的结构体定义如下：

type Mutex struct {
    state int32
    sema  uint32
}

const (
    mutexLocked = 1 << iota // mutex is locked
    mutexWoken
    mutexStarving
    mutexWaiterShift = iota
    starvationThresholdNs = 1e6
)
  • mutexLocked ：值为 1，第一位为 1，表示 mutex 已经被加锁。根据 mutex.state & mutexLocked 的结果来判断 mutex 的状态：该位为 1 表示已加锁，0 表示未加锁。
  • mutexWoken：值为 2（二进制：10），第二位为 1，表示 mutex 是否被唤醒。根据 mutex.state & mutexWoken 的结果判断 mutex 是否被唤醒：该位为 1 表示已被唤醒，0 表示未被唤醒。
  • mutexStarving：值为 4（二进制：100），第三位为 1，表示 mutex 是否处于饥饿模式。根据 mutex.state & mutexWoken 的结果判断 mutex 是否处于饥饿模式：该位为 1 表示处于饥饿模式，0 表示正常模式。
  • mutexWaiterShift：值为 3，表示 mutex.state 右移 3 位后即为等待的 goroutine 的数量，也即表示统计阻塞在该mutex上的goroutine数目需要移位的数值。根据 mutex.state >> mutexWaiterShift 得到当前等待的 goroutine 数目
  • starvationThresholdNs：值为 1000000 纳秒，即 1ms，表示将 mutex 切换到饥饿模式的等待时间阈值。这个常量在源码中有大篇幅的注释，理解这段注释对理解程序逻辑至关重要

state

1111 1111 ...... 1111 1 1 1 1
|_________29__________| ↓ ↓ ↓
          ↓             ↓ ↓ \ 表示当前 mutex 是否加锁
          ↓             ↓ \ 表示当前 mutex 是否被唤醒
          ↓             \ 表示 mutex 当前是否处于饥饿状态
          ↓
  存储等待 goroutine 数量

饥饿模式和正常模式

  • 在正常模式下，是按照FIFO(先来先的)的顺序获取锁的，这样一个刚换醒的goroutine将会和新请求的锁进行竞争，并且大概率会失败，这个时候他会被放入一个等待队列中的头部，如果他等待了1ms还是没有获取锁，那么他会将锁转为饥饿模式
  • 饥饿模式下，锁会从unlock的goroutine直接转移到饥饿队列里面的第一个，并从饥饿队列中开始排序

如果一个等待的goroutine获取了锁，并且满足一以下其中的任何一个条件：（1）它是等待队列中的最后一个；（2）它等待的时候小于1ms。它会将锁的状态转换为正常状态。

相比于饥饿模式，正常模式有更好地性能，因为一个 goroutine 可以连续获得好几次 mutex，即使有阻塞的等待者。而饥饿模式可以有效防止出现位于等待队列尾部的等待者一直无法获取到 mutex 的情况。

加锁

1.判断 Goroutine 的状态，看是否能够进行自旋等锁；

func (m *Mutex) Lock() {
    // Fast path: grab unlocked mutex.
    // 查看 state 是否为0，如果是则表示可以加锁，将其状态转换为1，当前 goroutine 加锁成功，函数返回
    if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
        if race.Enabled {
            race.Acquire(unsafe.Pointer(m))
        }
        return
    }
    // Slow path (outlined so that the fast path can be inlined)
    m.lockSlow()
}

看看这把锁是不是空闲状态，如果是的话，直接原子性地修改一下 state 为已被获取就行了。大概了解一下，知道该方法是原子性的即可。

如果不是空闲状态：

func (m *Mutex) lockSlow() {
    var waitStartTime int64 // 用来存当前goroutine等待的时间
    starving := false // 用来存当前goroutine是否饥饿
    awoke := false // 用来存当前goroutine是否已唤醒
    iter := 0 // 用来存当前goroutine的循环次数
    old := m.state // 复制一下当前锁的状态
for {
    // 进入到这个循环的，有两种角色goroutine，一种是新来的goroutine。另一种是被唤醒的goroutine；
    // 所以它们可能在这个地方再一起竞争锁，如果新来的goroutine抢成功了，那另一个只能再阻塞着等待，
    // 但超过1ms后，锁会转换成饥饿模式。在这个模式下，所有新来的goroutine必须排在队伍的后面，没有抢锁资格。也即：
    // 如果是饥饿情况之下，就不要自旋了，因为锁会直接交给队列头部的goroutine
    // 如果锁是被获取状态，并且满足自旋条件（canSpin见后文分析），那么就自旋等锁
    if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
        // 通过了上面的检测，这时进行自旋是有意义的。
        // 通过把 mutexWoken 标识为 true，以通知 Unlock 方法就先不要叫醒其它阻塞着的 goroutine 了
        if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
        atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
            awoke = true
        }
        // 将当前 goroutine 标识为唤醒状态后，执行自旋操作，计数器加一，将当前状态记录到 old，继续循环等待
        runtime_doSpin()
        iter++
        old = m.state
        continue
    }
...

总的来说需要注意如果是饥饿模式则不进行自旋，因为锁的所有权会直接交给队列头部的goroutine，所以在这个饥饿状态下，无论如何都无法获得mutex。

需要了解的是自旋是一种多线程同步机制，当前的进程在进入自旋的过程中会一直保持 CPU 的占用，持续检查某个条件是否为真。在多核的 CPU 上，自旋可以避免 Goroutine 的切换，使用恰当会对性能带来很大的增益，但是使用的不恰当就会拖慢整个程序，所以 Goroutine 进入自旋的条件非常苛刻：

源码注释认为因为 sync.Mutex 是协作的，所以对于 Spin 我们应该要保守一些使用，使用 Spin 的条件还挺严苛，看看其需要满足什么条件：

  1. 旋次数小于active_spin（这里是4）次；
  2. 然后应该运行在多内核的机器上，且GOMAXPROCS的数目应该要大于1；（如果GOMAXPROCS不了解，可以看看 Goroutine相对应的 GMP 模型）
  3. 还有当前机器上至少存在一个正在运行的处理器 P 并且处理的运行队列为空；

2.通过自旋等待互斥锁的释放；

//go:linkname sync_runtime_doSpin sync.runtime_doSpin
//go:nosplit
func sync_runtime_doSpin() {
	procyield(active_spin_cnt)
}

3.计算互斥锁的最新状态

如果此时 Goroutine 不能进行自旋操作，则会进入剩余的代码逻辑；到了这一步， state的状态可能是：

  1. 锁还没有被释放，锁处于正常状态；
  2. 锁还没有被释放， 锁处于饥饿状态；
  3. 锁已经被释放， 锁处于正常状态；
  4. 锁已经被释放， 锁处于饥饿状态；
// new 复制 state的当前状态， 用来设置新的状态
// old 是锁当前的状态
new := old

// 如果old state状态不是饥饿状态, new state 设置锁， 尝试通过CAS获取锁,
// 如果old state状态是饥饿状态, 则不设置new state的锁，因为饥饿状态下锁直接转给等待队列的第一个。
if old&mutexStarving == 0 {
    // 非饥饿模式下，可以抢锁，将 new 的第一位设置为1，即加锁
    new |= mutexLocked
}

// 当 mutex 处于加锁状态或饥饿状态的时候，新到来的 goroutine 进入等待队列，将等待队列的等待者的数量加1。
// old & 0101 != 0，那么 old 的第一位和第三位至少有一个为 1，即 mutex 已加锁或处于饥饿模式。
if old&(mutexLocked|mutexStarving) != 0 {
    new += 1 << mutexWaiterShift
}

// 如果当前goroutine已经处于饥饿状态， 并且old state的已被加锁,
// 将new state的状态标记为饥饿状态, 将锁转变为饥饿状态。
// 但如果当前 mutex 未加锁，则不需要切换，Unlock 操作希望饥饿模式存在等待者
if starving && old&mutexLocked != 0 {
    new |= mutexStarving
}

// 如果说当前goroutine是被唤醒状态，我们需要reset这个状态，
// 因为goroutine要么是拿到锁了，要么是进入sleep了。
if awoke {
    // new设置为非唤醒状态
    new &^= mutexWoken
}
  • 如果是正常模式，直接加锁
  • 如果是已经被加锁｜｜是进入饥饿模式，那么就将当前的goroutine放入等待队列
  • 如果已经被加锁&&进入饥饿模式，那么将新的锁设置进入饥饿模式
  • 如果当前goroutine已经被唤醒，设置为非唤醒状态

3.通过CAS来尝试设置互斥锁的状态

// 调用 CAS 更新 state 状态
if atomic.CompareAndSwapInt32(&m.state, old, new) {
    // 如果说old状态不是饥饿状态也不是被获取状态
    // 那么代表当前goroutine已经通过CAS成功获取了锁
    // (能进入这个代码块表示状态已改变，也就是说状态是从空闲到被获取)
    if old&(mutexLocked|mutexStarving) == 0 {
        // 成功上锁
        break // locked the mutex with CAS
    }
    // 如果之前已经等待过了，那么就要放到队列头
    queueLifo := waitStartTime != 0
    // 如果说之前没有等待过，就初始化设置现在的等待时间
    if waitStartTime == 0 {
        waitStartTime = runtime_nanotime()
    }
    // 既然获取锁失败了，就使用sleep原语来阻塞当前goroutine
    // 通过信号量来排队获取锁
    // 如果是新来的goroutine，就放到队列尾部
    // 如果是被唤醒的等待锁的goroutine，就放到队列头部
    runtime_SemacquireMutex(&m.sema, queueLifo, 1)
    
    // 这里sleep完了，被唤醒

    // 如果当前 goroutine 等待时间超过starvationThresholdNs，mutex 进入饥饿模式
    starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
    
    // 再次获取一下锁现在的状态
    old = m.state
    // 如果说锁现在是饥饿状态，就代表现在锁是被释放的状态，当前goroutine是被信号量所唤醒的，
    // 也就是说，锁被直接交给了当前goroutine
    if old&mutexStarving != 0 {
        // 如果说当前锁的状态是被唤醒状态或者被获取状态，或者说等待的队列为空
        // 那么state是一个非法状态，因为当前状态肯定应该有等待的队列，锁也一定是被释放状态且未唤醒
        if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
            throw("sync: inconsistent mutex state")
        }
        // 当前的goroutine获得了锁，那么就把等待队列-1
        delta := int32(mutexLocked - 1<<mutexWaiterShift)
        // 如果不是饥饿模式或只剩一个等待者了，退出饥饿模式
        if !starving || old>>mutexWaiterShift == 1 {
            // 把状态设置为正常
            delta -= mutexStarving
        }
        // 设置新state, 因为已经获得了锁，退出、返回
        atomic.AddInt32(&m.state, delta)
        break
    }
    // 如果锁不是饥饿模式，就把当前的goroutine设为被唤醒，并且重置iter(重置spin)
    awoke = true
    iter = 0
} else {
    // 如果CAS不成功，重新获取锁的state, 从for循环开始处重新开始
    old = m.state
}

加锁过程总结

  1. 首先，它检查互斥锁的状态 m.state 是否为 0，即是否没有被锁住。如果是，则表示可以尝试加锁，使用 atomic.CompareAndSwapInt32 原子操作尝试将状态从 0 转换为 mutexLocked（1）。如果这一步成功，表示当前 goroutine 已成功获得锁，可以立即返回。
  2. 如果上述快速路径失败，即互斥锁的状态不是 0，或者 CAS 操作失败，那么会进入慢路径，调用 m.lockSlow() 方法来进一步尝试获得锁。
  3. m.lockSlow() 方法中的主要部分是一个 for 循环，它用来处理互斥锁的各种状态和竞争情况。
  4. 首先，它会检查锁的状态 m.state，并尝试在锁被获取或处于饥饿状态的情况下自旋等待锁。这是为了避免不必要的等待和系统调用。
  5. 如果自旋等待条件满足，并且之前没有唤醒过其他等待的 goroutine，那么当前 goroutine 将设置 mutexWoken 标志为 true，以通知 Unlock 方法不要唤醒其他等待的 goroutines。接着，它会执行自旋操作，继续尝试获取锁。
  6. 如果自旋操作失败，它会更新迭代计数器 iter，复制当前锁的状态到 old，然后再次循环进行尝试。这个迭代计数器有助于限制自旋等待的次数。
  7. 如果上述条件不满足，它会计算新的状态 new，有四种，尝试通过 CAS 更新state状态
  8. 如果之前已等待过，将当前 goroutine 放入等待队列的头部（LIFO），否则初始化等待的起始时间。
  9. 使用系统调用（sleep）阻塞当前 goroutine，通过信号量来排队等待获取锁。新到来的 goroutine 放在队列的尾部，被唤醒的等待锁的 goroutine 放在队列的头部。
  10. 如果等待时间超过 starvationThresholdNs，锁进入饥饿模式，新到来的 goroutines 不再有机会竞争锁。
  11. 如果当前 goroutine被唤醒后，再次尝试获取锁并检查锁的状态，如果是饥饿模式，直接把锁交给队头，当前的goroutine获得了锁，那么就把等待队列-1，设置新的state
  12. 如果 CAS 操作不成功，重新获取当前锁的状态，重新开始循环

解锁

过程会先使用 AddInt32 函数快速解锁，这时会发生下面的两种情况：

  • 如果该函数返回的新状态等于 0，当前 Goroutine 就成功解锁了互斥锁；
  • 如果该函数返回的新状态不等于 0，这段代码会调用 sync.Mutex.unlockSlow 方法开始慢速解锁：

其源码片段如下：

func (m *Mutex) Unlock() {
    if race.Enabled {
        _ = m.state
        race.Release(unsafe.Pointer(m))
    }

	// mutex 的 state 减去1，加锁状态 -> 未加锁，并保存到 new
    new := atomic.AddInt32(&m.state, -mutexLocked)
    if new != 0 {
        // Outlined slow path to allow inlining the fast path.
        // To hide unlockSlow during tracing we skip one extra frame when tracing GoUnblock.
        m.unlockSlow(new)
    }
}

func (m *Mutex) unlockSlow(new int32) {
    // 如果state不是处于锁的状态, 那么就是Unlock根本没有加锁的mutex, panic
    if (new+mutexLocked)&mutexLocked == 0 {
        throw("sync: unlock of unlocked mutex")
    }
    // 非饥饿模式，也即正常模式
    if new&mutexStarving == 0 {
        old := new
        for {
            // 没有被阻塞的goroutine。直接返回
            // 有阻塞的goroutine，但处于woken模式，直接返回
            // 有阻塞的goroutine，但被上锁了，可能发生在此for循环内，第一次CAS不成功。因为CAS前可能被新的goroutine抢到锁。直接返回
            // 有阻塞的goroutine，但锁处于饥饿模式，可能发生在被阻塞的goroutine不是被唤醒调度的，而是被正常调度运行的。直接返回
            if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
                return
            }
            // 等待者数量减 1，并将唤醒位改成 1
            new = (old - 1<<mutexWaiterShift) | mutexWoken
            // 设置新的state, 这里通过信号量会唤醒一个阻塞的goroutine去获取锁.
            if atomic.CompareAndSwapInt32(&m.state, old, new) {
                // 唤醒一个阻塞的 goroutine，但不是唤醒第一个等待者
                runtime_Semrelease(&m.sema, false, 1)
                return
            }
            old = m.state
        }
    } else {
        // 饥饿模式：将 mutex 所有权传递给下个等待者。
        // 注意：mutexLocked 没有设置，等待者将在被唤醒后设置它。
        // 在此期间，如果有新的 goroutine来请求锁， 因为 mutex 处于饥饿状态，mutex还是被认为处于锁状态，
        // 新来的 goroutine 不会把锁抢过去.
        runtime_Semrelease(&m.sema, true, 1)
    }
}

解锁总结

  • 当互斥锁已经被解锁时，那么调用 sync.Mutex.Unlock 会直接抛出异常；
  • 当互斥锁处于饥饿模式时，会直接将锁的所有权交给队列中的下一个等待者，等待者会负责设置 mutexLocked 标志位，等待队列中的 goroutine 将负责互斥锁的解锁操作。这样，互斥锁的解锁操作并不需要显式的执行者（unlocker），因为等待队列中的下一个等待者会负责释放锁的状态。
  • 当互斥锁处于普通模式时，如果没有 Goroutine 等待锁的释放或者已经有被唤醒的 Goroutine 获得了锁，就会直接返回；在其他情况下会通过csa更新state状态，然后 sync.runtime_Semrelease 唤醒对应的 Goroutine；

参考

https://dongxiem.github.io/2020/06/05/golang-sync-bao-yuan-ma-pou-xi-1-sync.mutex/

Xian-dayandnight
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
Golang sync.Mutex源码分析
_____________________________________simanstar____
01-30 758
sync.Mutex是一个不可重入的排他锁。 这点和Java不同，golang里面的排它锁是不可重入的。当一个 goroutine 获得了这个锁的拥有权后， 其它请求锁的 goroutine 就会阻塞在 Lock 方法的调用上，直到锁被释放。 数据结构与状态机 　　sync.Mutex由两个字段 state 和 sema 组成。其中 state 表示当前互斥锁的状态，而 sema 是用于控制锁状态的信号量。 type Mutex struct { state int32 sem...
Golang sync.Mutex 与 sync.RWMutex
Dablelv 的博客专栏。
05-23 3621
Golang中sync包实现了两种锁，Mutex（互斥锁）和RWMutex（读写锁），其中RWMutex是基于Mutex实现的。 1.sync.Mutex type Mutex struct { // contains filtered or unexported fields } func (m *Mutex) Lock() func (m *Mutex) Unlock() sync.Mu...
golang学习笔记——互斥锁sync.Mutex、计数器sync.WaitGroup、读写锁sync.RWMutex
e891377的专栏
12-07 591
临界区总是需要通过同步机制进行保护的，否则就会产生竞态条件，导致数据不一致。
golang 中 sync.Mutex 和 sync.RWMutex
learn8more的博客
12-13 214
介绍 golang 中的 sync 包实现了两种锁： Mutex：互斥锁 RWMutex：读写锁，RWMutex 基于 Mutex 实现 Mutex（互斥锁） Mutex 为互斥锁，Lock() 加锁，Unlock() 解锁 在一个 goroutine 获得 Mutex 后，其他 goroutine 只能等到这个 goroutine 释放该 Mutex 使用 Lock() 加锁后，不能...
golang中sync.RWMutex和sync.Mutex
疯狂的鸭血
10-25 787
介绍 sync 包实现了两种锁： 1. Mutex：互斥锁 type Mutex struct { // 包含隐藏或非导出字段 } Mutex是一个互斥锁，可以创建为其他结构体的字段；零值为解锁状态。Mutex类型的锁和线程无关，可以由不同的线程加锁和解锁。 注意： 在一个 goroutine 获得 Mutex 后，其他 goroutine 只能等到这个 goroutine 释放该 ...
Go语言中sync.Mutex和sync.WaitGroup的用法
浮尘笔记
05-17 579
Go 并发编程中存在的难题：并发编程不像是传统的串行编程，程序的运行存在着很大的不确定性。Go语言中使用sync.Mutex实现互斥锁，使用sync.RWMutex实现读写互斥锁，使用sync.WaitGroup是用来做任务编排的，要解决的就是并发等待的问题。互斥锁 sync.Mutex 是一个结构体类型，属于值传递，因此使用的时候会产生副本。
不得不知道的Golang之sync.Map解读！
QcloudCommunity的博客
06-13 2112
导语| 本文结合源码，分析sync.Map的实现思路和原理，希望为更多感兴趣的开发者提供一些经验和帮助。一、背景项目中遇到了需要使用高并发的map的场景，众所周知golang官方的原生map是不支持并发读写的，直接并发的读写很容易触发panic。解决的办法有两个：自己配一把锁（sync.Mutex），或者更加考究一点配一把读写锁（sync.RWMutex）。这种方案简约...
sync.Mutex源码解读
一个菜鸟的博客
07-04 231
正常的期望值应该是1000;但是由于我们没有进行加锁,goroutineA在写的同时,goroutineB也在写,同时的去读,会有两个goroutine读到一样的值,然后去执行x++,导致最后数据不正确只有983
Golang的sync.Map源码解读
qq_30341855的博客
02-25 287
sync.Map源码解读 说明： 在map中，内部有两个map结构dirty和read.m 在查询过程中会优先从read.m中查询,并且对缺失计数misses加一。当misses达到dirty的长度时，会用dirty来替换read，并重置dirty为nil和misses为0。我称这个过程为缺失处理 再所有操作中，都会优先访问read.m再访问dirty type Map struct { read atomic.Value // readOnly,存放一个readOnly mu Mut
Golang中的sync.WaitGroup用法实例
09-21
主要介绍了Golang中的sync.WaitGroup用法实例,WaitGroup的用途,它能够一直等到所有的goroutine执行完成,并且阻塞主线程的执行,直到所有的goroutine执行完成,需要的朋友可以参考下
golang中使用sync.Map的方法
09-16
主要介绍了golang中使用sync.Map的方法，本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
go-pool:更好的通用池（sync.Pool）
05-26
此程序包是对sync程序包提供的Pool的精简包装。 Pool是必不可少的程序包，可通过减少内存分配数量来获得最佳性能。 额外功能 使池中的项目无效（因此它将不再被使用） 设置池的最大项目数 返回池中的项目数（空闲...
golang中sync.Map并发创建、读取问题实战记录
09-20
主要给大家介绍了关于golang中sync.Map并发创建、读取问题的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
Golang：二进制数据的Base64编码和解码操作
最新发布
彭世瑜的博客
05-17 167
Base64可以将二进制数据编码为文本数据，比如将二进制格式的图片编码为文本存储。前面的部分，是存储了二进制数据的格式，并非base64编码后的结果。这个文本格式可以在浏览器中直接打开。
golang template: “xxx.html“ is an incomplete or empty template 解决方法
05-15 139
这个异常一般是因为在使用 template.New("xxx.html") 时这里的名称非真实存在的视图文件名导致， 这个地方有点坑， 明明ParseFiles函数已经指定了视图路径了，而这里的New里面的名字居然还必须是你后面指定的视图路径中的文件名！
Go 语言IO操作(文件&文件内容增、删、改、查、复制。。。)
qq_39335595的博客
05-14 1029
O_RDONLY: 以只读方式打开文件。文件指针可定位于文件的任意位置。当尝试写入时，会返回错误。O_WRONLY: 以只写方式打开文件。即使文件已存在，它也会被截断为零长度，除非同时使用了O_APPEND标志。文件指针总是在文件的开始位置。O_RDWR: 以读写方式打开文件。文件指针可定位于文件的任意位置。同时具有读写能力。O_APPEND: 设置文件指针于文件末尾。所有写入操作都会在文件末尾添加数据，而不是覆盖现有内容。O_CREATE: 如果文件不存在，则创建一个新文件。与O_TRUNC。
【go从入门到精通】使用 pprof 在 Go 中进行分析
网易搬砖选手
05-14 334
当你看到有reflect.unsafe_NewArray的时候，你要小心，这里可能存在一些内存泄露或者不安全的使用方式， 我们可以使用traces reflect.unsafe_NewArray来查看使用的地方都有哪些.越大的盒子总是会对应它的使用情况，无论是CPU、内存等，所以在上面的例子中，我们看到的。通过此基本设置，在运行应用程序时，pprof 将公开您可以与之交互的端点，以开始收集应用程序上的配置文件。命令显示特定函数的配置文件数据摘要，包括其消耗的总 CPU 时间的百分比以及调用的次数。
Golang开发：编写测试用例
arslan-robot
05-15 430
在Go语言中，编写测试用例是一种很好的实践，用于确保代码的正确性和可维护性。Go提供了一个内建的testing包，它提供了编写和运行测试用例的基础功能。当你运行go test命令时，Go会查找当前包中所有以Test开头且接收一个*testing.T参数的函数，并将它们作为测试用例运行。每个测试用例都会在一个新的goroutine中执行，因此它们是并发的。如果测试用例中的任何t.Errorf被调用，那么该测试用例将失败，并且错误消息将被打印出来。你可以使用t.Log。
golang sync.Mutex
05-25
`sync.Mutex` 是 Go 语言中的一个互斥锁。它可以用于保护共享资源，以确保在同一时刻只有一个 goroutine 可以访问资源。当一个 goroutine 获得了 Mutex 后，其他 goroutine 就不能再获得这个 Mutex，直到该 ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值