综合实现复杂度，节点检索性能等等的考虑吧。
1.一页一个节点。页的地址即可表示节点，那么可以直接根据页号找到对应节点数据。如果一页多节点还得额外存信息来索引节点所在位置，并且存取和更新都会有额外的复杂度，提高开发难度，对性能不友好。
2.一个节点可能跨页。当 key 或 value 数据过大时，需要跨页。至于跨页的分配管理得看实现。我以前写的是和节点页采用同一套页管理，加个特殊标识。而像 etcd 的底层 bbolt 是采用相邻连续页组合成一个页，这样开发复杂度降低，感觉空间浪费会多些。

再看 request ，猜测是不是有业务在做 http 请求时，每次都新建 http.Client 后请求。这样导致 sync.Pool 每次都重新创建

看到 p.pinSlow 。猜测是 sync.Pool 这的问题。可能是 sync.Pool 使用有误，大量新建 sync.Pool 和销毁。sync.Pool 有个全局维护的数组 allPools ，有个全局的锁保证它的并发读写。

写框架，函数库，基础设施时写比较好。业务的话，业务复杂起来后，维护成本很高。比如测试用例的执行顺序变化和并发执行时，会导致新增单测在单跑时正确，全部一起跑时就可能有时正确有时错误，维护非常耗时间。

刚入了 thinkbook 14+预期之后和上个笔记本一样做双系统。这个双系统有什么问题吗？ 14+有一个 ssd 扩展，双系统应该容易的啊。

你同事的意思是不是读一行处理一行？

很少用，要用也是带其它条件字段将数据缩减到足够小的范围。正则走不了索引。而通常做查询时，先考虑走什么索引。

golang 之前确实有篇单机 100 万连接实践。本质上是讲 golang 在 100 万连接下怎么优化的。比较采用常规的一个链连接 2 个 go 程方案与通过 syscall
直接使用 epoll 方案之间的内存占用和延迟差别等。和 100 万并发不是同个概念。文章里实现单机 100 万连接的一些设置以及测试方式还是可以借鉴的。其它语言也能做到

分片。把两张表拉下来，根据公司 id 分片，存到磁盘上。然后一个一个分片加载到内存中计算。磁盘持久化的 b+树上千万级，性能下降很厉害。

看区域。大多区域已经被我爱我家，链家等中介公司垄断。极少数区域房东还坚持自己租。千万警惕二房东。我爱我家之类正规的，相当于花钱省麻烦。大多情况下不用和房东打交道。故障之类平台上报修，小东西会直接免费用。和房东打交道费力些。二房东往往收钱不办事，你还得和房东打简单。也有那种通过中介租的当二房东，听过没接触过。

共同探讨，有理有据完全可以接受

@hengyunabc 关于你说的仓库被攻击引入 hash 的问题。java 也存在，任何从仓库下载的都存在篡改问题。而且 go 也能做到从企业内部的仓库下载。

估计是一下子没找到问的方向，问这个看看你熟悉什么，然后再深入问

@byte10 runtime.LockOSThread()

入口代码在 src/runtime/proc.go 。有个 func main()

golang 的 runtime 源码在 src 可以直接找到。真正的 main 函数其实是在 runtime 里。然后你可以看到启动的步骤，包括不限于启动 g0 协程和启动 gc 工作。
每个 go 进程是自己独立的，和虚拟机区分开来。没有独立的 runtime 进程。
简单的讲，你可以理解成 c 语言加入了协程和 gc 的框架。由于有 gc，所以不能直接使用系统分配内存的函数，都是通过这个框架提供的函数来分配。

以前了解过。1.8 出来后想抽空尝试，刚好碰到项目里需要个小东西，挺合适最终效果也不错。现在我部门已经全是 golang 了

刚好手头就遇到一个场景。大致是中间层汇聚各种内容一起返回。但是只知道 key,以及值是一个 json 。某项 key 内容不存在时，你让中间层实例化也很为难啊，都不知道内容。