「Golang」并发场景下的Map使用方式及避坑指南

最新推荐文章于 2024-04-18 18:26:00 发布
最新推荐文章于 2024-04-18 18:26:00 发布
阅读量3.5k 收藏 6
点赞数 4
分类专栏： Golang 新手教程 文章标签： golang go
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_37005831/article/details/111815704
版权

文章目录

非线程安全的map

map是一个在开发过程中常用的内建类型，也是各位很熟悉的一个数据结构，他可以很方便的让我们做一些关于针对某些key-value结构的CRUD操作，但是在官方设计中，内建类型的map并不是一个可以在并发场景下进行并发读写的线程安全类型，此时我们就需要考虑对其进行一些线程安全的改造，首先我们要了解一下为什么```map``是一个非线程安全的类型，首先看下列代码：

func main() {
	m := make(map[string]int, 2)
	m["dd"] = 22
	go func() {
		for {
			m["ff"] = 1
		}
	}()
	go func() {
		for {
			_ = m["dd"]
		}
	}()
	time.Sleep(1 * time.Hour)
}

// out:
// fatal error: concurrent map read and map write

上面的代码在运行期抛出了：fatal error: concurrent map read and map write异常，代表在读写过程中出现了同时读写的问题，那么为什么会出现这个问题呢？在map底层源代码的针对读和写的函数中有下列两段代码：


// runtime.mapassign 即在map进行写入操作时调用的函数
func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
	// ..............

	// 在写入时会对h.flags字段进行正在写入标记以防止并发读写
	h.flags ^= hashWriting
	// ..........
	
	// 检查是否有并发写的问题
	if h.flags&hashWriting == 0 {
		throw("concurrent map writes")
	}
	// 写入完毕回复标记字段
	h.flags &^= hashWriting
	//.........
}
// runtime.mapaccess1 在 value:=m[key]时调用的函数
func mapaccess1(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
	// .............
	// 检测标记字段 是否不等于0 如果不等于0则代表发生并发读写
	if h.flags&hashWriting != 0 {
		throw("concurrent map read and map write")
	}
	// .............
}
// runtime.mapaccess2 在 value,ok:=m[key]时调用的函数
func mapaccess2(t *maptype, h *hmap, key unsafe.Pointer) (unsafe.Pointer, bool) {
	// .............
	// 检测标记字段 是否不等于0 如果不等于0则代表发生并发读写
	if h.flags&hashWriting != 0 {
		throw("concurrent map read and map write")
	}
	// .............
}

上述源代码做了很大一部分的省略，仅留下了针对并发读写标记的设置、取消、以及检查的语句，在此能看出map的底层根据并发场景做了非线程安全的处理。

如何使得map变成线程安全

MutexMap的实现

上面讲了map在并发环境下非线程安全的例子以及原因，那么目前我们如何解决这个问题呢？从之前作者的文章：「Golang」 sync.Mutex源码讲解 中可以看到使用互斥锁可以使得在并发环境下某些对象只能在某些事件内只有一个goroutine持有对其进行CRUD操作，那么我们可以使用互斥锁对map对其进行封装，例子代码如下：

type MutexMap struct {
	lock sync.Mutex
	m    map[string]int
}

func (receiver *MutexMap) Get(key string) (int, bool) {
	receiver.lock.Lock()
	value, ok := receiver.m[key]
	receiver.lock.Unlock()
	return value, ok
}

func (receiver *MutexMap) Set(key string, value int) {
	receiver.lock.Lock()
	receiver.m[key] = value
	receiver.lock.Unlock()
}
func (receiver *MutexMap) Del(key string) {
	receiver.lock.Lock()
	delete(receiver.m, key)
	receiver.lock.Unlock()
}

上述代码中作者使用了一个结构体对sync.Mutex和map进行了封装，并且对外提供了一系列的方法以供使用，从上述方法中可以看到，在Get(),Set(),Del()方法中进行map操作前均对其进行了互斥锁加锁操作，这样使得该结构体对象可以在并发环境下保证只有一个goroutine持有对其map进行CRUD操作，这样也就消除了并发读写问题的影响。

MutexMap的优化，RWMutexMap的诞生

在上一节中，我们进行了MutexMap的实现，但是有一个问题也就产生了，由于互斥锁的特性，虽然可以提供线程安全的 map，但是在大量并发读写的情况下，锁的竞争会非常激烈。尤其在读的并发非常大的时候，互斥锁会严重影响读取的性能，因为在通过map底层源码发现，并发的读并不会产生panic只有并发读写时，才会发生，因此，互斥锁会导致整体读的效率下降很多，此时我们就应该使用读写锁来进行优化，读写锁相关解析请阅读: 「Golang」sync.RWMutex源码讲解，该文章中指出：

读写锁就是一个可以并发读但是不可以并发写的锁，由于互斥锁的特性，会导致将所有goroutine（下称协程）串行化，从而影响整体程序运行的性能，如果写的数量大于读的数量时，性能损耗暂且可以忽略不计（建议不要忽略），但是当读的数量大于写的数量时，互斥锁对性能的影响是很大的，所以此刻我们需要采用读写锁来进行读操作和写操作的分开。

现在我们就对MutexMap进行读写锁的优化，优化后的代码如下：

type RWMutexMap struct {
	lock sync.RWMutex
	m    map[string]int
}

func (receiver *RWMutexMap) Get(key string) (int, bool) {
	receiver.lock.RLock()
	value, ok := receiver.m[key]
	receiver.lock.RUnlock()
	return value, ok
}

func (receiver *RWMutexMap) Set(key string, value int) {
	receiver.lock.Lock()
	receiver.m[key] = value
	receiver.lock.Unlock()
}
func (receiver *RWMutexMap) Del(key string) {
	receiver.lock.Lock()
	delete(receiver.m, key)
	receiver.lock.Unlock()
}

上述代码中，将lock sync.Mutex字段替换成为了lock sync.RWMutex字段，并且将Get()方法转而使用读锁进行加锁，此时，当前的 RWMutexMap结构体就针对读多写少的并发情况有了很好的性能提升，

标准库的sync.Map

标准库中提供了一种官方实现的线程安全的map结构，即sync.Map，该包虽然是线程安全的，但是使用场景很少，这个 sync.Map并不是用来替换内建的 map类型的，它只能被应用在一些特殊的场景里。官方文档指出可以用在以下场景：

1.只会增长的缓存系统中，一个 key 只写入一次而被读很多次，即读多写少
2.多个 goroutine 为不相交的键集读、写和重写键值对，即多个goroutineCRUD操作不同的key-value

但是，最好在使用的时候根据场景首先进行性能测试后，再根据性能测试结果选用sync.Map或者RWMutexMap。
sync.Map的实现，其针对RWMutexMap做了下面几个优化。

  1. 空间换时间。通过冗余的两个数据结构（只读的 read 字段、可写的 dirty），来减少加锁对性能的影响。 对只读字段（read）的操作不需要加锁。
  2. 优先从 read 字段读取、更新、删除，因为对 read 字段的读取不需要锁。
  3. 动态调整。miss次数多了之后，将 dirty 数据提升为 read，避免总是从 dirty 中加锁读取。
  4. double-checking。加锁之后先还要再检查 read 字段，确定真的不存在才操作 dirty 字段。
  5. 延迟删除。删除一个键值只是打标记，只有在提升 dirty字段为 read 字段的时候才清理删除的数据。

既然sync.Map这么好，那么就来测试一下MutexMap，RWMutexMap，sync.Map的性能差距吧，下面我针对这两个结构体进行性能测试看看其在大量只读，只写，读写的情况下的性能如何（代码引用于goalng1.14不同场景下sync.Map、Mutex、RWMutex锁性能测试对比）：

package main

import (
	"fmt"
	"sync"
	"testing"
	"time"
)

var (
	num  = 1000 * 10
	gnum = 1000
)

func Test_main(t *testing.T) {
	count := 10000
	div := int(50) //抽样写比例 1/5
	fmt.Println("only read")
	testRwmutexReadOnly(count)
	testMutexReadOnly(count)
	//test sync.map
	testSyncMapReadOnly(count)

	fmt.Println("write and read")
	testRwmutexWriteRead(count, div)
	testMutexWriteRead(count, div)
	testSyncMapWriteRead(count, div)

	fmt.Println("write only")
	testRwmutexWriteOnly(count)
	testMutexWriteOnly(count)
	testSyncMapWriteOnly(count)

}

func testRwmutexReadOnly(count int) {
	var w = &sync.WaitGroup{}
	var rwmutexTmp = newRwmutex(count)
	w.Add(gnum)
	t1 := time.Now()
	for i := 0; i < gnum; i++ {
		go func() {
			defer w.Done()
			for in := 0; in < num; in++ {
				rwmutexTmp.get(in)
			}
		}()
	}
	w.Wait()
	fmt.Println("testRwmutexReadOnly cost:", time.Now().Sub(t1).String())
}

func testRwmutexWriteOnly(count int) {
	var w = &sync.WaitGroup{}
	var rwmutexTmp = newRwmutex(count)
	w.Add(gnum)
	t1 := time.Now()
	for i := 0; i < gnum; i++ {
		go func() {
			defer w.Done()
			for in := 0; in < num; in++ {
				rwmutexTmp.set(in, in)
			}
		}()
	}
	w.Wait()
	fmt.Println("testRwmutexWriteOnly cost:", time.Now().Sub(t1).String())
}

func testRwmutexWriteRead(count, div int) {
	var w = &sync.WaitGroup{}
	var rwmutexTmp = newRwmutex(count)
	w.Add(gnum)
	t1 := time.Now()
	for i := 0; i < gnum; i++ {
		if i%div != 0 {
			go func() {
				defer w.Done()
				for in := 0; in < num; in++ {
					rwmutexTmp.get(in)
				}
			}()
		} else {
			go func() {
				defer w.Done()
				for in := 0; in < num; in++ {
					rwmutexTmp.set(in, in)
				}
			}()
		}
	}
	w.Wait()
	fmt.Println("testRwmutexWriteRead cost:", time.Now().Sub(t1).String())
}

func testMutexReadOnly(count int) {
	var w = &sync.WaitGroup{}
	var mutexTmp = newMutex(count)
	w.Add(gnum)

	t1 := time.Now()
	for i := 0; i < gnum; i++ {
		go func() {
			defer w.Done()
			for in := 0; in < num; in++ {
				mutexTmp.get(in)
			}
		}()
	}
	w.Wait()
	fmt.Println("testMutexReadOnly cost:", time.Now().Sub(t1).String())
}

func testMutexWriteOnly(count int) {
	var w = &sync.WaitGroup{}
	var mutexTmp = newMutex(count)
	w.Add(gnum)

	t1 := time.Now()
	for i := 0; i < gnum; i++ {
		go func() {
			defer w.Done()
			for in := 0; in < num; in++ {
				mutexTmp.set(in, in)
			}
		}()
	}
	w.Wait()
	fmt.Println("testMutexWriteOnly cost:", time.Now().Sub(t1).String())
}

func testMutexWriteRead(count, div int) {
	var w = &sync.WaitGroup{}
	var mutexTmp = newMutex(count)
	w.Add(gnum)
	t1 := time.Now()
	for i := 0; i < gnum; i++ {
		if i%div != 0 {
			go func() {
				defer w.Done()
				for in := 0; in < num; in++ {
					mutexTmp.get(in)
				}
			}()
		} else {
			go func() {
				defer w.Done()
				for in := 0; in < num; in++ {
					mutexTmp.set(in, in)
				}
			}()
		}

	}
	w.Wait()
	fmt.Println("testMutexWriteRead cost:", time.Now().Sub(t1).String())
}

func testSyncMapReadOnly(count int) {
	var w = &sync.WaitGroup{}
	var mutexTmp = newSyncMap(count)
	w.Add(gnum)

	t1 := time.Now()
	for i := 0; i < gnum; i++ {
		go func() {
			defer w.Done()
			for in := 0; in < num; in++ {
				mutexTmp.Load(in)
			}
		}()
	}
	w.Wait()
	fmt.Println("testSyncMapReadOnly cost:", time.Now().Sub(t1).String())
}

func testSyncMapWriteOnly(count int) {
	var w = &sync.WaitGroup{}
	var mutexTmp = newSyncMap(count)
	w.Add(gnum)

	t1 := time.Now()
	for i := 0; i < gnum; i++ {
		go func() {
			defer w.Done()
			for in := 0; in < num; in++ {
				mutexTmp.Store(in, in)
			}
		}()
	}
	w.Wait()
	fmt.Println("testSyncMapWriteOnly cost:", time.Now().Sub(t1).String())
}

func testSyncMapWriteRead(count, div int) {
	var w = &sync.WaitGroup{}
	var mutexTmp = newSyncMap(count)
	w.Add(gnum)
	t1 := time.Now()
	for i := 0; i < gnum; i++ {
		if i%div != 0 {
			go func() {
				defer w.Done()
				for in := 0; in < num; in++ {
					mutexTmp.Load(in)
				}
			}()
		} else {
			go func() {
				defer w.Done()
				for in := 0; in < num; in++ {
					mutexTmp.Store(in, in)
				}
			}()
		}

	}
	w.Wait()
	fmt.Println("testSyncMapWriteRead cost:", time.Now().Sub(t1).String())
}

func newRwmutex(count int) *rwmutex {
	var t = &rwmutex{}
	t.mu = &sync.RWMutex{}
	t.ipmap = make(map[int]int, count)

	for i := 0; i < count; i++ {
		t.ipmap[i] = 0
	}
	return t
}

type rwmutex struct {
	mu    *sync.RWMutex
	ipmap map[int]int
}

func (t *rwmutex) get(i int) int {
	t.mu.RLock()
	defer t.mu.RUnlock()

	return t.ipmap[i]
}

func (t *rwmutex) set(k, v int) {
	t.mu.Lock()
	defer t.mu.Unlock()

	t.ipmap[k] = v
}

func newMutex(count int) *mutex {
	var t = &mutex{}
	t.mu = &sync.Mutex{}
	t.ipmap = make(map[int]int, count)

	for i := 0; i < count; i++ {
		t.ipmap[i] = 0
	}
	return t
}

func newSyncMap(count int) *sync.Map {
	var t = &sync.Map{}

	for i := 0; i < count; i++ {
		t.Store(i, 0)
	}
	return t
}

type mutex struct {
	mu    *sync.Mutex
	ipmap map[int]int
}

func (t *mutex) get(i int) int {
	t.mu.Lock()
	defer t.mu.Unlock()

	return t.ipmap[i]
}

func (t *mutex) set(k, v int) {
	t.mu.Lock()
	defer t.mu.Unlock()

	k = k % 100
	t.ipmap[k] = v
}
// only read
// testRwmutexReadOnly cost: 346.72604ms
// testMutexReadOnly cost: 1.56353484s
// testSyncMapReadOnly cost: 94.436269ms
// write and read
// testRwmutexWriteRead cost: 511.433544ms
// testMutexWriteRead cost: 1.439301381s
// testSyncMapWriteRead cost: 106.220371ms
// write only
// testRwmutexWriteOnly cost: 2.579502195s
// testMutexWriteOnly cost: 1.922190051s
// testSyncMapWriteOnly cost: 4.177583278s

结论：

只读场景：sync.map > rwmutex >> mutex
读写场景（边读边写）：rwmutex > mutex >> sync.map
读写场景（读80% 写20%）：sync.map > rwmutex > mutex
读写场景（读98% 写2%）：sync.map > rwmutex >> mutex
只写场景：sync.map >> mutex > rwmutex

使用环境不负责任推荐

关于MutexMap，RWMutexMap，sync.Map的选择问题，其实不一定只能看上述的测试结论，还需要根据应用场合以及实际情况来使用，根据我自己的情况来看的话，有以下几个方面可以考虑，只是我个人见解。

  1. 由于sync.Map的通用性的问题，所以返回的值均为interface{}类型，这样在我们进行一些操作的时候就会需要不断的去断言他，导致麻烦，此时如果性能要求不是特别高的情况下可以使用RWMutexMap用作专用性替换，这样可以免去了断言的一些性能损耗和麻烦。
  2. 之前看过一篇文章，RWMutexMap在并发量异常庞大的时候性能下降会很快，比如1000万，所以如果高并发的时候尽可能采用sync.Map
  3. 当读写均多的时候sync.Map就显得力不从心，因为其内部实现原因需要针对只读map进行适时更换，如果一旦写入过多，就会导致更换的过于频繁，但是RWMutexMap就不会产生这个问题，除扩容和写锁的性能下降外，基本上没有什么其他损耗。
  4. 如果map遍历情况过多请使用RWMutexMap，因为sync.Map的时间复杂度最低为O(n)，所以此时sync.Map的遍历性能就很差了。

我已开通自己的公众号【Echo的技术笔记】
日后的文章发布会主要在公众号上发布
希望各位关注一下
谢谢大家啦
在这里插入图片描述

_ Echo_
关注
专栏目录
Go语言高性能编程指南: Go语言高级特性介绍——协程池、channel缓冲区大小、defer语句、map的性能优化、HTTP框架benchmark性能、测试框架性能等
程序员光剑
07-28 1094
2009年9月，Google发布了Go语言，其具有快速编译器、高效执行性能和无需担心内存泄漏等特点，受到开发者的广泛关注。自发布至今，已经经过十多年的积累，Go语言已经成为事实上的主流编程语言。其成功带动了云计算、容器技术的发展，成为最热门的云计算语言之一。截止目前，Go语言已经发展到了版本v1.16。在这篇文章中，我将通过Go语言高性能编程指南对Go语言进行全面的剖析，包括介绍语言特性、面向对象的特性、内存模型、并发编程模型、调度器、垃圾回收器、工具链等。
Golang底层原理学习笔记（三）
lcynone的博客
01-14 188
Golang底层原理学习笔记
Golang 中的 map 为什么是并发不安全的？
lp15929801907的博客
04-19 1970
Golang 中的 map为什么是并发不安全的？怎么实现一个并发安全的 map？
golang中map的并发问题（golang中的sync.map）
xiaodongdonga的博客
11-28 1720
golang中map的并发问题（golang中的sync.map）
golang之map并发访问
techdashen的博客
10-12 1335
即定义一个新的结构体,为该结构体实现两个方法,在方法里使用sync包的Mutex或RWMutex来做加锁保证并发安全.(和缓存的做法很类似：先从缓存中取，如果没有则从数据库中读，读回来存入缓存，下次就可以从缓存中取到了。可以用sync.Mutex (互斥锁)，或者sync.RWMutex(读写锁)来"重构"map,map 不是并发安全的数据结构，倘若存在并发读写行为，会抛出 fatal error.并发安全也称线程安全,如果在并发中出现了数据的丢失或错乱,就是并发不安全。Store为写,Load为读。
关于golang的map并发
afanx的博客
05-17 443
进行并发自测时进程突然终止，错误为“fatal error: concurrent map writes”，原来golang原生map类型是非并发安全的，要使用sync.Map才能并发写。 package main import ( "fmt" "sync" ) type Test struct { MemA string MemB string MemC int } func main() { var TMap sync.Map TM
golang中的map以及并发问题
猛犸象
12-21 3708
特点 无序的键值对集合，使用key来获取，无法通过index来获取，返回顺序未知，因此每次打印的顺序可能不一样。 可迭代 for range。 使用hash表实现的，是引用类型。 len()获取长度。 key可以是所有可比较的类型：boolean， numeric， string， pointer， channel， interface， array， struct。 非并发安全的。 声明与初始化 var m1 map[string]int // 只是声明，依然是 nil m2 := make(map[
Go 1.9 sync.Map揭秘
weixin_34203426的博客
07-21 369
本文为转载，原文链接 在Go 1.6之前， 内置的map类型是部分goroutine安全的，并发的读没有问题，并发的写可能有问题。自go 1.6之后， 并发地读写map会报错，这在一些知名的开源库中都存在这个问题，所以go 1.9之前的解决方案是额外绑定一个锁，封装成一个新的struct或者单独使用锁都可以。 本文带你深入到sync.Ma...
Golang_GoKubernetes的IngressNGINX控制器.zip
最新发布
05-26
在Kubernetes生态系统中，Ingress是管理外部访问服务的主要方式，而Ingress NGINX控制器则是最常用的Ingress实现之一。这个压缩包“Golang_GoKubernetes的IngressNGINX控制器”显然包含了与使用Go语言开发和理解...
使用Go语言实现的分布式缓存
09-23
`Gache`可能会使用Go的内置`map`结构来存储键值对，这种数据结构提供了快速的查找、插入和删除操作，非常适合用于缓存场景。 `cache.go`文件可能包含具体的缓存操作方法，如设置、获取、删除和更新缓存项。这些方法...
开源项目-golang-go.zip
10-10
这种策略常用于减轻高并发场景下的锁竞争问题，提升系统的并行处理能力。 在Go语言中，当多个协程同时访问一个大对象时，全局锁可能会成为性能瓶颈。引入“分片”（sharding）的概念可以将大对象拆分为多个小对象，...
golang并发访问map安全问题
qq_37638125的博客
04-18 983
Go语言规范并未保证在并发写情况下map的行为。因此，如果发生并发写，程序可能会出现未定义的行为，如panic（数据竞争检测器检测到问题时）、数据不一致、程序崩溃等。这些行为是不可预测的，且难以调试。
golang中的mmap使用
practice make prefect
02-17 5928
mmap的原理参考：https://blog.csdn.net/ITer_ZC/article/details/44308729 golang中mmap存在于exp包下面，对于使用brew安装的环境而言，exp包的源码并未自动下载。需要先手动get下来。 go get github.com/golang/exp 下面是一个简单的小例子： package main import ( "...
Go map使用细节及综合案例
baidu_41388533的博客
07-01 252
map 使用细节 map 是引用类型，遵守引用类型传递的机制，在一个函数接收 map，修改后，会直接修改原来的 map func modify(map1 map[int]int) { map1[10] = 900 } func main() { //map是引用类型，遵守引用类型传递的机制，在一个函数接收map， //修改后，会直接修改原来的map map1 := make(map[int]int) map1[1] = 90 map1[2] = 88 map1[10] = 1 map
golang 1.8 并发安全Map简单实现
wwhhff11
03-18 2129
type SafeMap struct { sync.RWMutex Map map[int64]string } func NewSafeMap(size int) *SafeMap { sm := new(SafeMap) sm.Map = make(map[int64]string, size) return sm } func (sm *Safe...
【Go进阶】怎么实现并发安全的map
m0_50562814的博客
12-06 1827
go语言提供的数据类型中，只有channel是并发安全的，基础map并不是并发安全的。以下三种方案实现了并发安全的map。
并发环境应用map的解决方案
weixin_33928137的博客
09-03 270
众所周知,golang的map是非协程安全的(go1.6版本以后,go1.6之前读安全),而并发读写map的需求应该是很普遍的。举例如下： package main import "fmt" func main() { a := make(map[int]bool, 0) for i:=0;i<100;i++{...
mmap函数_「Golang」mmap “像使用内存一样操作文件”
weixin_39760433的博客
12-05 1725
mmap并不是什么新技术，早在4.2BSD的系统说明中就已经出现了mmap相关函数，并且mmap属于POSIX标准。在一众开源软件中都使用到了mmap，如Etcd、InfluxDB、RocketMQ等。想要理解MMAP，就不得不说到 虚拟内存(Virtual Memory，VM)。虚拟内存 VM虚拟内存是现代操作系统重要的一部分，它具备3个重要的能力：把内存用做硬盘的高速缓存快速交换数据为每个进程...
golang中的map并发读写问题： Golang 协程并发使用 Map 的正确姿势
程序员光剑
09-20 9289
map 不是并发安全的 官方的faq里有说明，考虑到有性能损失，map没有设计成原子操作，在并发读写时会有问题。 Map access is unsafe only when updates are occurring. As long as all goroutines are only reading—looking up elements in the map, including iter...
golang 并发编程
11-15
Golang 是一种编程语言，其设计目标之一就是支持并发编程。在 Golang 中，我们可以使用 goroutine 来实现并发操作。goroutine 可以理解为一种轻量级的线程，它可以由 Go 语言的运行时环境进行调度，并发执行。 在 Golang 中，我们可以通过关键字 go 来创建一个 goroutine。例如，我们可以通过以下方式启动一个 goroutine： ```go go func() { // 执行并发操作 }() ``` 除了 goroutine，Golang 还提供了一些并发编程的原语，比如 channel。Channel 是用来在 goroutine 之间进行通信和同步的一种机制。我们可以使用 channel 来在不同的 goroutine 之间传递数据，以及控制它们的执行顺序。 另外，Golang 还提供了一些内置的同步机制，比如 sync 包中的互斥锁和条件变量，可以帮助我们在并发编程中避免竞态条件和数据访问冲突。 总的来说，Golang 的并发编程模型非常简洁和高效。通过goroutine、channel以及内置的同步机制，我们可以很容易地实现并发操作，提高程序的性能，同时避免一些常见的并发编程问题。因此，Golang 在并发编程方面具有很强的优势，是一个非常适合开发并发程序的编程语言。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值