课件及源代码地址

老师，我按照第一个示例：读锁的 lockAccess 和 无锁的 lockFreeAccess 方法分析 cpu.prof 文件的时候，top命令返回的结果，为什么有时候使用率会没有 lockAccess ，而是 lockFreeAccess 方法占用CPU比较高。代码是和文档一致的 (pprof) top Showing nodes accounting for 11.25s, 98.94% of 11.37s total Dropped 13 nodes (cum <= 0.06s) Showing top 10 nodes out of 29 flat flat% sum% cum cum% 2.40s 21.11% 21.11% 2.40s 21.11% sync.(*RWMutex).RLock 2.29s 20.14% 41.25% 2.99s 26.30% runtime.mapaccess2_faststr 2.21s 19.44% 60.69% 2.21s 19.44% sync.(*RWMutex).RUnlock 1.90s 16.71% 77.40% 1.90s 16.71% runtime.findnull 0.87s 7.65% 85.05% 0.87s 7.65% runtime.pthread_cond_wait 0.55s 4.84% 89.89% 3.19s 28.06% go_learning/ch48/lock_test.lockFreeAccess.func1 0.47s 4.13% 94.02% 0.47s 4.13% runtime.add 0.34s 2.99% 97.01% 0.34s 2.99% runtime.pthread_cond_signal 0.12s 1.06% 98.07% 0.12s 1.06% runtime.newstack 0.10s 0.88% 98.94% 0.15s 1.32% runtime.(*bmap).keys

按老师的代码实例测试，变化 读写的比例 我得到的结果总是 sync.Map 花的时间最少， 问题可能出在哪里呢？

很多程序的性能问题，都和锁有关，数据库或者编程语言的。 Go 语言中有读写锁，互斥的写锁比较容易理解，而互斥的读锁容易造成“误解”。 LockFree 和 LockAccess 在我的笔记本上性能差距大概是 1:30 Concurrent Map 利用 parition 的原理，把一个大的 Map 变成很多小的 Map，这样就可以避免因为一个大的 Map 整个被锁定（锁冲突）的情况 读多写少的时候，使用 sync.map 读写都很频繁的时候使用 Concurrent Map 但是从我本地测试的情况来看，直到读写比 50:1 的时候，sync.Map 在性能上才超过了 Concurrent Map。 按照留言中的线索，读写比例在 10:1 的时候，sync.map 和 concurrent_map 的性能差距大概是 1:2；如果将读写比例设定为 1:1 的时候，性能比上升为 1:5，concurrent_map 的优势更为明显。

我的理解从锁功能上来说: map with lock类似表锁，每次加锁都锁整个map sync map类似行锁，只锁要写的那块map内存 concurrent map类似区间锁， 但是跟mysql中不一样，mysql里行锁好于区间锁好于表锁

老师，为什么我的go test -bench打印不出来课程里面的那些参数啊

concurrent_map 看了下源码，应该只是增加了并行度，跟Java老的cm实现不一样的是，第一层槽数组的每个元素用读写锁处理并发，挺有意思的

我的理解从锁功能上来说: map with lock类似表锁，每次加锁都锁整个map sync map类似行锁，只锁要写的那块map内存 concurrent map类似区间锁， 但是跟mysql中不一样，mysql里行锁好于区间锁好于表锁，这里不一样