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

最新推荐文章于 2024-10-22 17:05:57 发布
最新推荐文章于 2024-10-22 17:05:57 发布
阅读量3.7k 收藏 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的技术笔记】
日后的文章发布会主要在公众号上发布
希望各位关注一下
谢谢大家啦
在这里插入图片描述

【全】Go语言指针与Map使用指南
走向CTO的路上...
10-15 432
指针是一个保存变量内存地址的变量。在 Go 中，指针使用和符号操作。通过指针修改函数外部的变量值。使用指针管理复杂的数据结构，如链表或树。map 是一种无序键值对集合，类似 Python 的字典，可以存储和快速查找值。检测是否存在键并遍历 map。使用 map 管理复杂数据结构，例如数据缓存。标准方式遍历 map 得到键值对。按顺序遍历 map，需要先将键进行排序。使用切片的稳定排序对 map 进行更复杂的处理。创建切片，其中每个元素都是一个 map。创建 map，其值为切片，以便管理多值条目。
【全】 Go Goroutine 与并发编程使用指南
走向CTO的路上...
10-21 550
i < 5;i++ {wg.Add(1)go work(i)wg.Wait()Go语言中的goroutine及其相关的并发编程工具提供了强大而灵活的方式来处理并发任务。通过理解各种工具（如通道、互斥锁、原子操作等）的使用场景和原理，开发者可以编写出高效、易于维护的并发程序。随着技术的不断进步，未来我们可以期待更多优化工具和最佳实践出现，以进一步提升Go语言在并发编程中的表现。
关于golang的map并发
afanx的博客
05-17 455
进行并发自测时进程突然终止，错误为“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
m0_70578296的博客
10-09 672
通过一道考题，来实现一个简单的并发安全的Map，以加深对并发编程和channel的理解。要求实现一个map：（1）面向高并发（2）只存在插入和删除操作，时间复杂度为O(1)（3）查询时，若Key存在，直接返回Val；若Key不存在，阻塞直到KV对被放入后，获取Val返回；如果等待指定时长仍未放入，返回超时错误；
golang中map的并发问题（golang中的sync.map）
xiaodongdonga的博客
11-28 1746
golang中map的并发问题（golang中的sync.map）
golang之map并发访问
techdashen的博客
10-12 1411
即定义一个新的结构体,为该结构体实现两个方法,在方法里使用sync包的Mutex或RWMutex来做加锁保证并发安全.(和缓存的做法很类似：先从缓存中取，如果没有则从数据库中读，读回来存入缓存，下次就可以从缓存中取到了。可以用sync.Mutex (互斥锁)，或者sync.RWMutex(读写锁)来"重构"map,map 不是并发安全的数据结构，倘若存在并发读写行为，会抛出 fatal error.并发安全也称线程安全,如果在并发中出现了数据的丢失或错乱,就是并发不安全。Store为写,Load为读。
golang中的map以及并发问题
猛犸象
12-21 3736
特点 无序的键值对集合，使用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 380
本文为转载，原文链接 在Go 1.6之前， 内置的map类型是部分goroutine安全的，并发的读没有问题，并发的写可能有问题。自go 1.6之后， 并发地读写map会报错，这在一些知名的开源库中都存在这个问题，所以go 1.9之前的解决方案是额外绑定一个锁，封装成一个新的struct或者单独使用锁都可以。 本文带你深入到sync.Ma...
golang并发访问map安全问题
qq_37638125的博客
04-18 1024
Go语言规范并未保证在并发写情况下map的行为。因此，如果发生并发写，程序可能会出现未定义的行为，如panic（数据竞争检测器检测到问题时）、数据不一致、程序崩溃等。这些行为是不可预测的，且难以调试。
【全】Go 网络编程：Socket 和 WebSocket 使用指南
最新发布
走向CTO的路上...
10-22 962
Socket：适合低层次、需要完整控制的网络应用，比如文件传输、定制协议通讯。WebSocket：适合高层次、需要实时交互的应用，如即时通信、实时游戏。Go语言的网络编程能力非常强大，尤其是其内建的并发模型简化了并发网络程序开发。随着5G和IoT的发展，对高效、低延迟网络通信的需求将会增加，Go语言将在这些领域有更多应用。
Golang进阶：性能优化与并发编程实战
6. **函数**：强调了高效函数设计，包括在允许的情况下使用初始化声明，以提升代码简洁性和性能。 7. **文件操作**：涉及文件的读写、I/O操作和并发处理，通过合理利用并发通道改善性能。 8. **并发协程和通道**：...
【全】Go语言函数使用指南
走向CTO的路上...
10-16 804
基本函数定义和局部变量作用域。使用包范围内的变量。理解函数内、包内及全局变量的区别。函数的简单参数传递与单一返回值。多返回值及命名返回参数。通过指针修改传入参数。在变量中存储并调用匿名函数。使用匿名函数进行延迟执行。闭包特性捕获环境变量。简单递归函数示例。嵌套闭包函数。递归与闭包结合使用。简单的 defer 使用以确保资源释放。多个 defer 的执行顺序。defer 配合匿名函数实现更复杂的逻辑。init 函数用于初始化设置。多个 init 函数的执行顺序。init 函数间依赖管理。
golang中的mmap使用
practice make prefect
02-17 5952
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 259
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 中的 map 为什么是并发不安全的？
lp15929801907的博客
04-19 2081
Golang 中的 map为什么是并发不安全的？怎么实现一个并发安全的 map？
golang 1.8 并发安全Map简单实现
wwhhff11
03-18 2140
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 1899
go语言提供的数据类型中，只有channel是并发安全的，基础map并不是并发安全的。以下三种方案实现了并发安全的map。
并发环境应用map的解决方案
weixin_33928137的博客
09-03 279
众所周知,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 1744
mmap并不是什么新技术，早在4.2BSD的系统说明中就已经出现了mmap相关函数，并且mmap属于POSIX标准。在一众开源软件中都使用到了mmap，如Etcd、InfluxDB、RocketMQ等。想要理解MMAP，就不得不说到 虚拟内存(Virtual Memory，VM)。虚拟内存 VM虚拟内存是现代操作系统重要的一部分，它具备3个重要的能力：把内存用做硬盘的高速缓存快速交换数据为每个进程...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值