实际上这个回答的重点，并不是你看过什么源码，而是看你怎么看源码的。
因为工作原因，我看过 OPENSSL 自动机的源码，分析过里面的功能，但是只看功能是第一步的，我原先总结的看代码目标是：

+ 自动机中功能性的划分，能迅速找到功能划分的位置。
+ 针对某些异常情况的处理，能迅速找到在不同步骤出异常或问题时的处理流程。
+ 系统竞争和瓶颈所在地，能迅速找到可能导致并发 /新建问题出现的地方。
+ 多线程或多进程同步的地方，能迅速分析清楚具体是哪种同步模型。
+ 能够将模块中可拆分 /变化的部分迅速找到，并零件化

具体可以看看这篇文章，这个是我总结这几年工作加看代码的经验和教训：
https://hxndg.github.io/2020/12/15/%E5%BC%82%E6%AD%A5%E7%A8%8B%E5%BA%8F%E7%BC%96%E5%86%99%E6%97%B6%E7%9A%84%E4%B8%80%E4%BA%9B%E5%B0%8F%E6%95%99%E8%AE%AD/

嗯，我做负载均衡想转互联网也基本都失败了，这么一想是不是感觉内心好多了？

坦白讲，我也不知道欢迎套接字是啥。。。。

我主要好奇的是 《计算机网络自底向上》是个啥书？
我只知道《计算机网络自顶向下》特别好。

@Wirbelwind 嗯，我也怀疑是这个，但是没把代码下下来看并不确定

@matrixji
不，你这个说法没有解释清楚为什么 local_name + "**"为什么会 core，
每个线程都是在自己的栈上操作，local_name+"**"的结构应该是在本地栈上分配的，即使 assign 的是直接这个地址也不应该 core 才对。

local_name + "**"和 key 必然是放在栈上申请的临时变量，按照道理来说不应该有问题，所以我做了个尝试：

我把你 B1.func1 核 B2.func1 里面的`a->name = local_name`去掉以后，试了下就一直没出现 core 的现象了。

估计又是编译器做的一些“好事”导致的问题，感觉还是跟利用了 a->name 有关系，和生命周期什么的有关。

我司之所以不用 C++，用 C 一部分原因也是因为避免编译器的操作。。。。

建议还是上 libc 源码看看吧，这个明显跟编译器行为有关了。

不过没明白干嘛要干这种事情呢？一般这种多线程操作都是极度小心的。

讲道理直接 vim 打开看看，然后进行切块不行吗？

快不快这个得看数据检索的方式吧？

内存里的数据还得看有没有被换出等多方面信息。

我个人觉得。。。。很多的线程同步的东西实际上底层都给你做了。。。。

类似什么 MCS，CLH，钟表锁之类的别说你不知道，面试官可能也不知道，但是知道了又能怎么样呢？ TAS 和 TTAS 的性能为什么不同，底层 MESI 造成的后果这些都不会有人了解，除非你去做内核。

也就我们拿 C，有时候需要自己设计多线程操作的才会实现自旋锁之类的多线程，
有的时候我们抄 linux 内核的东西也得理解一些锁的操作等等。


所以你就多刷刷算法，和基础调优之类就够了

大厂内卷现在和高考差不多，都是不看工程能力，一套题目一把梭。

重新看了一下写的书评，内核态的自旋锁实际上用的原理也是 MCS，CMH 那些，但是用的是 C 。
说“没能深入到内核层讲解诸如高效自旋锁等内容的实现”并不是说这些内容没有，而是说不能满足内核工程师的一探究竟。

PS 下半部分看的我有点头大。。。。

首先，你这个应该不会只出现一种 core 的结果
27 行应该也可能出现 core，但 core 的原因应该是多个线程 free 同一个地方导致的。

另外 28 行出现 core 的原因看流程像是拷贝的时候生成的临时变量都是在 local_name 上，然后不同线程操作导致拷贝的长度无效导致的。

当然以上结论需要事实+观察寄存器传参确定，我忘了 X86_64 位下寄存器的值代表的含义了，不做任何正确性保证。

lz 你的问题实际上已经在下面这帮子人的回复里体现了
有冷嘲热讽的，有直接卡死到底的，有举例子的，有编段子的

如果你是一个论坛的站长，你怎么维持一个论坛的活力和质量？
另一个问题，技术群的干货又怎么定义？

@rocky114
如果单纯从缓存热点的角度来考虑，你使用 ttl 是可以做的，但是具体 ttl 的值哪种更合适这个只能测出来，因为不同的流量，ttl 的值可能需要动态变化。

一段时间没被访问的缓存走数据库是没问题的，但是要防备热点更新，这种比方说很多人每天早上醒过来的时候会看新闻这种。

你提的实际上就是 lru 算法的各种实现，搜搜看？

我没实现过分布式，不过设计过单机的线程缓存操作之类的。。。。。提个自己的想法
创建一个缓存的队列，命名为缓冲垫，表示没命中，目前正在从数据库拿数据。

如果工作者线程发现缓存没命中，这个数据也没在缓冲垫里，直接去数据库那数据就完了，然后一次性更新数量多一些的数据，如果有局部性可言。

如果工作者线程发现缓存没命中，这个数据在缓冲垫里，那就直接返回，先去做别的事务，等待已经去数据库取数据的工作者线程把数据取回来，再继续执行。

总之就是减少忙等，除非忙等的时间特别短。

我一个平时主用 C 的，表示现在看 C++11 还是提供了不少高层特性的
我们对着 ARM 的宽松内存模型已经修了不少自己家系统的 BUG 了，全是那种稀奇古怪的 BUG
C++17 相比 C++11 提供了哪些更高层，更方便的理念 /实践呢？