原文: Inside the Go CPU profiler,作者 Sümer Cip。我猜测 Felix Geisendörfer 肯定会进行评论，果不其然。
Go 是那种自带 profiler (分析器)的语言之一。它的运行时包含强大的自成一派的各种 profiler。其它语言，比如 Ruby、Python 和 Node.js, 它们也包含 profiler或者一些用来编写profiler的API，但是与Go的开箱即用的 profiler相比，它们提供的profiler功能有限。如果你想多了解Go提供的这些可观察工具的情况，我强烈推荐你阅读 Felix Geisendörfer的 The Busy Developer’s Guide to Go Profiling, Tracing and Observability。
作为一个好奇的工程师，我喜欢挖掘事物在底层上的工作方式，我一直想去学习Go CPU profiler底层·是怎么工作的。这篇文章就是此次探索的结果。每当我阅读Go运行时代码时，我总是学到到一些新东西，这次也不例外。
Go一向以它的简单易学而著称，我也遇到过同学说只需半天就能掌握Go语言了，两三年的Go开发经验就称专家了。
想比较Rust等编程语言，Go语言的确容易上手，查看Go语言的规范你也会看到，它的语言规范相比较其它编程语言非常的简短，的确可以一个小时就可以读完。但是如果你深入了解这门语言(其它语言也是类似情况)，就会发现很多细节的地方，需要花谢心思和时间仔细琢磨琢磨。这不，我先来几道Go并发的源代码考考你，看看你能回答上来不？
在 Go 1.19 的开发中, string.SliceHeader和string.StringHeader经历了一个生死存亡的争斗，这两个类型一度被标记为弃用(deprecated),但是这两个类型经常用在 slice of byte 和 string 高效互转的场景中，如果被标记为弃用，但是目前还没有可替代的方法，所以这两个类型又把弃用标记去掉了，如无意外，它们也会在 Go 1.20 再次被标记为弃用。
orcaman/concurrent-map是一个非常高效的线程安全的map库，正如它的文档中所说的那样，标准库sync.Map更适合append-only的场景，或者说少写大量的读的场景，如果针对多读多写的场景，concurrent-map可能会更有优势。它是通过分片的方式，将锁的粒度减少，从而提高性能。
今年初的时候，这个库做了改造，开始支持泛型，但是不幸的是，它只支持Value值泛型，它的key只能是string类型，这就限制了它的应用场景。
距离上一次2021年Go生态圈rpc框架benchmark的测试整整一年了。一年来，各个RPC框架也获得长足的进展，rpcx也在众多网友的支持下做了一些有益的优化和精简，所以是时候再做一次国内几个常用框架的性能比较了。
