UncP’s Blog

Adaptive Radix Tree

2019-05-02T00:00:00+00:00

这篇文章介绍 Adaptive Radix Tree 并且提供其并发算法 Multi-ART。

论文链接：The Adaptive Radix Tree: ARTful Indexing for Main-Memory Databases

Adaptive Radix Tree

Adaptive Radix Tree(ART) 中文名字是可变基数树，相较于传统的 radix tree，其最大的区别在于每个节点可以容纳的 key 是动态变化的，这样既可以节省空间，又可以提高缓存局部性。

art 内部节点分为4种类型，分别是 node4, node16, node48, node256。

Node4

Node4 有4个槽，存储4个 unsigned char 和4个指针，这些指针可以指向叶子节点(即 key 指针)，也可以指向下一层内部节点。当 Node4 存放第5个 key byte 时需要将其扩大为 Node16。

Node16

Node16 和 Node4 在结构上是一致的，但是 Node16 可以存放16个 unsigned char 和16个指针。当存放第17个 key byte 时需要将其扩大为 Node48。

Node48

Node48 结构上和 Node4, Node16 有所不同，它有256个索引槽和48个指针，这256个索引槽对应 unsigned char 的 0-255，然后每个索引槽的值对应指针的位置，分别为 1-48，如果某个字节不存在的话，那么它的索引槽的值就是0。当存放第49个 key byte 时需要将其扩大为 Node256。

Node256

Node256 直接存放256个指针，每个指针对应 unsigned char 的 0-255 区间。

除了以上的可变节点，ART 还引入了两种技术来进一步减少内存占用（尤其是在 long key 情况下），分别是 Path Compression 和 Lazy Expansion。

Path Compression & Lazy Expansion

Lazy Expansion 用于区别两个叶子节点时才进行创建内部节点，比如上图中的 FOO，为了节省空间，两个内部节点不会被创建，只会存在一个叶子节点，当另一个 key 比如 FPO 被插入时，才会创建一个内部节点以区别 O 和 P。

Path Compression 用于移除只有单个子节点的节点，比如上图中带有 A 的节点会被合并入父节点。

节点合并带来了前缀，前缀需要在下降时进行比较，所以产生了两种方法，一种是悲观方法，即每个节点专门开辟一个变长区间存放前缀，每次下降时需要进行比较；另一种是乐观方法，只存储前缀的长度，下降时跳过这个长度，然后到达叶子节点时再回头利用叶子节点进行前缀的比较。在 ART 的实现中结合了这两种方法，每个节点存放最多8个字节的前缀，下降会根据前缀长度进行动态切换。

查找算法

查找流程很简单：

如果当期节点为空代表不存在；
如果当前节点是叶子节点并且 key 相等那么即代表找到；
如果当前节点是内部节点需要首先比较前缀，前缀不同则表明 key 不存在，相同则可以继续进行下降。

插入算法

插入流程大致分为以下几步：

如果下降到的节点是空节点，那么用叶子节点替换掉这个叶子节点；
如果下降到的节点是叶子节点，那么需要进行比较，如果 key 存在退出；否则使用新的内部节点替换到当前叶子节点，同时需要根据两个 key 获取前缀
如果下降到的是内部节点，需要首先比较前缀，如果前缀不符合的话，生成新节点，令公共前缀为其前缀，公共前缀后一字节作为区分两个 key 的字节，然后将叶子节点和截断公共前缀后的老节点插入到这个新节点中
如果下降到的是内部结点并且前缀相等，如果存在下一层节点的话，继续进行下降；否则直接将叶子节点插入，并根据需要进行节点大小的调整

删除算法

参考插入算法。

Multi-ART

Multi-ART 是 ART 的并发算法，是我实习时开始琢磨的，到现在断断续续地有三个月了。Multi-ART 参考了 Mass Tree 的并发策略即 lock-free read + fine-grained-locking write，然后根据 ART 的特点做出了调整。

设计

在实现完 Mass Tree 之后决定自己设计一个并发算法，于是选择了 ART。ART 是很久之前就知道的一种索引，当时将某个 C 实现的 ART 翻译成了 C++ 实现，然后非常惊讶于其性能，所以选择了 ART 来设计并发算法。

整个设计中最核心的问题就是“如何正确下降到下一层节点”。

在并发 B-Tree（包括 Mass Tree）中，下降最大的障碍在于分裂，下降前根据 key 判断应该下降到 A 节点，但实际上由于节点的横向分裂实际需要下降到另一个节点 B，但是在 Multi-ART 中，情况又有很大的不同，ART 节点不存在横向分裂的行为，取而代之的是：

节点竖向分裂或合并，由节点前缀变更引起
节点原地扩展或收缩，由插入和删除引起

对于 B Tree 或者 Mass Tree 来说，为了保证下降到正确的节点，有两种机制，第一种是每个节点自带一个 next 域和一个 sentinel key，用于进行节点之间的右移，比如 B Link Tree；第二种是重试，即从某个子树进行重新下降，比如 Mass Tree。

对于 Multi-ART 来说，我们首先考虑节点的原地扩展或收缩，即上图中 ART Node Expand 这种情况。为了保证正确地下降，对每个节点引入 old 这个域（只需占用某个 bit），每次节点发生扩展或收缩时需要将当前节点标记为 old。如果在下降到这个节点时发现这个节点已经处于 old 状态，即代表它已经被一个新的节点取代了，那么为了获取正确的节点，这里可以有两种辅助机制：

每个节点引入 new 指针，如果当前节点被替换了，通过 new 来获取新节点
根据父节点来获取新节点，因为父节点中旧的节点会被原地替换为新节点

以上两种机制都能正常工作，考虑到 ART 原有算法，我采用了 old 域 + 通过父节点获取新节点这种方式。

最后我们考虑节点的竖向分裂或合并，即上图中 ART Node Split 这种情况。这里需要两个机制来保证正确性。

一是对每个节点引入 offset 域，即如果下降到这个节点，该从哪个偏移开始比较。比如某个节点前缀是 ABC，节点的 offset 是4，如果在另一个线程下降过程中发生了竖向分裂，那么可能前缀变成了 BC，offset 变成了 5，那么另一个线程就不能用 offset 4 进行比较，当它发现 offset 5 时，即知道发生了前缀变化，需要进行重试。

二是对每个节点引入 expand version 域，比较节点前缀前后都需要获取这个域来保证节点的前缀在比较时没有发生改变。

三是对每个节点引入 parent 域，因为两个线程可能一前一后更改了前缀，所以第二个线程替换父节点中的节点时应该获取上图中的绿色节点，而不是下降时的红色节点。

为了支持这个算法，对每个 ART 节点引入了 version(8字节) 和 parent(8字节) 域。

off: 节点的 offset
count: 节点的 key 数量
prefix_len: 前缀长度
type: node4 | node16 | node48 | node256
old: 节点是否是旧的
lock: 用于写线程加锁
expand: 是否正在发生前缀变化
vexpand: 前缀的 version
insert 和 vinsert 目前没有使用

以上就是 Multi-ART 的设计核心问题，其实花的精力远远不止以上这点篇幅，还有很多其它的设计细节和实现细节，懒得展开了，可以参考这个专栏之前的相关并发算法的文章。

性能

预计在55个线程左右 Multi-ART 8字节每秒随机写入可以破亿。

我的 GitHub 上有这四个算法的实现，这个知乎专栏也有这个四个算法的介绍。

Multi-ART 的性能相较于 B Tree based 的并发算法，几乎是碾压。（当然这里需要指出的是为了实现的简单，并不保证 Multi-ART 的 Node4, Node16 和 Node48 中 key 是有序的）。

Multi-ART 的高性能有很多因素，比如算法时间复杂度低，cache 友好的节点设计，良好的并发策略设计等等。

总结

这篇文章介绍了 ART 以及 Multi-ART 的设计与实现。

GitHub 地址：UncP/aili。

4 Modifications For Raft Consensus

2019-01-26T00:00:00+00:00

全局唯一的数据库 ID

作用

防止其他集群的成员加入到当前集群中

Pre-Vote

作用

防止“term inflation”（即一个存在网络问题的机器发起选举，但是没有收到回应，导致 term 一直增长，直到很长一段时间之后才成功当选 leader）。

行为

引入 pre-vote 算法，在成员转变为 candidate 之前会先发起一次 pre-vote rpc，当这个 rpc 收到多数成员的同意之后才会发起真正的选举。

Pre-Vote RPC

arguments:
nextTerm: caller's term + 1
candidateId: caller
lastLogIndex
lastLogTerm

results:
term: currentTerm, for caller to update itself
voteGranted: true means caller would receive vote if it was a candidate

receiver:
1. reply false if last AppendEntries call was received less than election timeout ago(leader stickness)
2. reply false if nextTerm < currentTerm
3. if caller's log is at least as up-to-date as receiver's log, return true

另外，对于 pre-vote 来说，不存在同一任期一个成员只能投一次票这样的限制，因为到达真正的投票阶段时，只会有一个 leader。

Leader stickness

作用

防止 leader 的频繁切换。对于 raft 来说这是正确的行为，但是对于应用来说，如果需要频繁的切换访问 leader 会带来很大的问题。

行为

收到投票时，在一个 election timeout 之内当前成员曾收到过 AppendEntry RPC，那么它会拒绝这次投票。

这种行为的引入使得只有当超过半数的成员在 election timeout 之外没有收到 AppendEntry 后，选举才可能成功。其实这样的行为和 redis cluster 中的 master 切换是比较相似的。

Mass Tree

2018-12-13T00:00:00+00:00

这篇文章介绍 Trie 树和 B+ 树结合而成的并发算法——Mass Tree。

Mass Tree 是 2012 年提出的，引用了很多 OLFIT Tree 以及 B^link Tree 的概念。（这个专栏的第一篇文章介绍了 B^link Tree。）

论文链接：Cache Craftiness for Fast Multicore Key-Value Storage

Mass Tree 结构

从结构上来说，Mass Tree 是由一层或多层 B+ 树组成的 Trie 树。

上图中，圆形代表内部节点（interior node，也就是 B+ 树的 branch node），矩形代表边缘节点（border node，也就是 B+ 树的 leaf node），五角星代表 value。border node 的 value 域可能存放的是数据，也可能存放的是下一层子树的根节点。

每个虚线框代表一棵 B+ 树，对于每一层（Layer）的 B+ 树，采用8字节进行索引。长度小于 (8h + 8) 字节的 key 会被存放在 layer <=h。比如，两个 key 存放在 layer 1，那么它们的前8字节是相同的。

注意上面 <= h，极端情况下才会放在 h 层，否则会尽可能地把 key 放在较低的层，比如 Mass Tree 中所有 key 都是8字节，那么它们都位于 layer 0，突然来了一个1k字节长度的 key，显然没有必要把这个 key 放在第一百多层，如果这个 key 的前8字节没有和其他 key 冲突的话，那么它也会被放在 layer 0，如果发生了冲突，那么我们只需要生成新的子树（subtree），把这个 key 放在 layer 1 就可以，即层数是懒惰生成的，只有当出现节点8字节索引相同时才会生成新的 layer。

同一层的所有叶节点会被双向连接（next 和 prev）在一起，但是内部结点是不连接的，这和 B^link Tree 不一样，后者对所有节点维护单向连接（next），所以 Mass Tree 在进行根节点到叶子节点的下降过程时，逻辑和 B^link Tree 是不一样的。

B^link Tree 的每一个 border node 都带有一个 higher key，用于判断是否需要进行节点右移，但是 Mass Tree 没有 higher key，所以判断是否右移需要获取下一个节点。

对于叶节点来说，higher key 并不是必须的。请问这是为什么？

Mass Tree 给出了完整的内部节点和叶节点结构，这里只介绍叶节点的原子状态跃迁，为了防止读线程读到中间状态，叶节点被设计成最多存放 15 个 key，引入了一个8字节64位的 permutation(uint64_t)，这个 permutation 被划分成16份，每份4位，其中1份代表当前节点的 key 数量，另外15份用于存放每个 key 在节点中实际位置的索引，key 的插入是顺序插入，之后只需要修改 permutation 来更新节点内 key 的索引信息，然后施加一个 release 语义，当读线程对这个节点的 permutation 施加 acquire 语义时，可以获取到完整的节点信息。

Mass Tree 算法

并发策略

Mass Tree 的并发策略和 OLFIT Tree 是相似的：

fine-grained locking，即节点锁，解决 write-write 竞争，同一时刻只有一个线程可以对当前节点进行写操作
optimistic concurrency control，即节点 version (uint32_t)，解决 read-write 竞争，读开始前和读结束后都需要获取当前节点的最新 version，来判断在读过程中当前节点是否发生了写操作（插入或分裂），同时对节点的写操作都需要先修改 version，在插入 key 之前需要设置 inserting 标记，插入完成之后将 insert 的 vinsert + 1；在分裂之前需要设置 splitting 标记，分裂完成之后将 split 的 vsplit + 1。

和 permutation 一样，version 也被划分成了多个域，除了带有 insert 和 split 信息之外，还包含一个 lock bit，用于加锁；一个 root bit，用于指示否是根节点；一个 border bit，用于指示是否是 border node；一位 deleted 位，用于指示这个节点是否被标记为删除。

下降流程

对于每次插入，获取，删除操作，都需要从 root（可能是整棵树的根节点，也可能是某棵子树的根节点）下降到对应的叶节点（border node）。

首先，在开始读取节点之前，必须获得节点的 stable version（图中橙色方块），即 version 中的 inserting 和 splitting 位都为0。

其次，在下降之前，需要获取最新的 root，因为在开始下降前，根节点可能分裂了，导致其发生了改变（图中蓝色方块）。

最后，如果当前节点已经是叶节点，那么可以返回，否则需要进行下降，读取内部结点根据 key[x, x+8)(8字节) 获得下降节点之后，分为3种情况处理：

case 1 那行伪代码可以这样用 C 语言表示：

uint32_t before = node_get_stable_version(n);
// read node here
uint32_t after = node_get_version(n); // no need to be stable, just latest version
if ((before ^ after == LOCK_BIT) || (before ^ after == 0))
    // neither insert nor split happened

节点在我们读取期间没有发生任何变化，我们可以安全地进行下降；

节点发生了变化，而且是分裂，那么我们需要从根节点重新进行下降（内部节点没有相互连接起来，所以不能像 B^link Tree 那样获取右节点）；
节点发生了变化，但只是插入，只需要重新对当前节点进行下降

注意第二个黄色方块，这一行非常关键，如果你细看下的话，它似乎可以挪到 case 1 的 if 语句里面，但实际上不能这样做。因为如果当前节点的孩子节点发生了分裂，但是还没来得及将新节点插入到当前节点，对调这两行代码，可能会导致下降到错误的节点。

插入流程

作者只给出了读取伪代码，这里给出插入伪代码。

当我们通过 findborder 下降到叶节点后，需要对其加锁（图中蓝色方块），但是此时并不能直接将 key 进行插入，当两个写线程同时下降到同一个叶节点时，只有一个线程可以进行写入，所以加锁后需要查看在加锁前是否有其他线程对这个节点进行了写入，如果有的话需要查看是否需要右移，这里的逻辑和 B^link Tree 是一样的。

当我们成功加锁并且定位到正确的叶节点之后，可以进行写入，结果有4种：

插入 key 成功或 key 已经存在；
需要下降到下一层，同时需要增加索引的偏移；
存在索引冲突，比如 “12345678AA” 和 “12345678BB”，此时需要创建一棵子树，存放 “AA” 和 “BB”，同时需要把原来存放 “AA” 的地方替换成这棵子树的根节点
节点已满，需要分裂之后再次插入（见下一小节）

橙色方块在下面删除流程中介绍

分裂流程

分裂流程和 B^link Tree 是一样的逻辑，需要同时锁住当前节点以及父节点，分为三种情况：

当前节点没有父节点，即当前节点是某个子树的根节点或者整棵树的根节点，在这种情况下我们需要生成新节点作为根节点。有个特殊的地方需要处理，对于子树来说，它的节点存放在上层的叶节点中，但是上图中并没有提到当子树分裂时，如何将上层叶节点中旧的根节点替换掉，这里有两种处理方法：
- 懒惰处理，不设置根节点的父节点，但是会在写路径中添加判断，当从叶节点下降到某个子树的根节点时，会判断其是否是真正的根节点，如果不是的话，会追溯到新的父节点，然后在叶节点替换掉旧根节点（这种懒惰处理的思想很巧妙）；
- 设置子树的根节点的父节点为上一层的叶节点，只需要在 case1 和 case2 中添加一种 case，处理子树根节点的替换（这两种方法没有优劣之分）
父节点没有满，则只需要将 fence key 和新节点插入到父节点
父节点已满，需要分裂父节点然后进行插入，之后需要将分裂的新节点提升到更上层

Mass Tree 每个节点都有一个指向父节点的指针，B^link Tree 的节点可以不需要父节点，请问这是为什么？

读取流程

整体而言和插入流程是一样的，这里不再展开，有个点需要注意：

unstable 状态（图中绿色方块），插入流程的 case 3，当出现8字节索引相同时，需要生成子树来替换掉这个 value，但是这个操作不会修改 inserting 或者 splitting 标记，所以需要先标记这个 slot 为 unstable，然后把 value 替换为子树根节点的指针（以及一些其他操作），来防止读到不稳定状态（说实话，这个状态的引入似乎增加了复杂性，其实可以在替换之前标记 inserting，这样也会触发重试）；

橙色方块，在下面删除流程中介绍

删除流程

这里只讨论逻辑删除，物理删除需要额外的技术，比如 hazard pointer，epoch-based reclamation 等等。

逻辑删除和B+树的类似，但是我们并不对 key 少的节点进行合并，当节点 key 减少到0时，需要标记这个节点为 deleted，然后将其从父节点删除，同时如果是叶节点的话，还需要维护叶节点的双向连接（这是为什么叶节点需要双向连接的一大原因，维护起来简单）。如果某棵子树为空的话也可以删除整棵子树。当其他线程发现节点处于 deleted 状态时，需要进行重试，因为这个节点逻辑上是不存在的。

除此以外还有一种特殊情况需要考虑：

左边的线程根据 k1 定位到了位置 i，在读取 v1 之前这个节点发生了删除位于位置 i 的 k1，同时在位置 j 处插入 k2，如果 i 等于 j，可能导致左边的线程读取到 v2，为了解决这个问题，需要在索引 i 被删除后重新利用时增加节点的 vinsert 域。

以上就是 Mass Tree 算法的整体介绍。

Mass Tree 优化

其实节点的结构，比如每个节点存放15个 key 本身就是作者测试过后的最优解。作者还在论文里也提到了不少优化，比如节点预取，索引（uint64_t）用整形数比较，定制的节点内存分配器，以及 key 的后缀的管理，等等。这里不做展开。

Mass Tree 总结

Trie 和 B+ 两种索引树的结合，使得在下降过程中的重试不需要从整棵树的根节点开始，同时加快拥有相同前缀的 key 的处理速度
具体的内部结点与外部节点的结构
fine-grained locking 写以及 lock-free 读
比较具体的节点删除机制
较小的节点减少了线程的竞争

需要指出的是这个算法不支持性能线性扩展，不过这并不是问题。

这个算法实现起来很有挑战性，个人认为主要有两个方面，第一个是对于树结构的把握，Mass Tree 是 Trie 和 B+ 树的结合。第二个是对于并发下可见性的理解，”先改哪个域后改哪个域“，”谁先可见谁后可见“，”谁何时可见“，“在哪加以及加不加 memory barrier”等等这样的问题需要花很多时间考虑，而且出现 bug 非常难调试。

Mass Tree 性能比我预想中要好很多，对于均匀分布的10字节 key 随机插入，数据量1000万，在我的机器上4个线程可以到500万以上的 tps；对于分布集中的测试数据，可以到1000万以上。其实对于内存索引来说，cache miss 对性能造成的影响有时候是远远大于线程竞争的，所以尽管数据分布非常集中（线程竞争更多），仍然可以获得更高的性能。

这是我的 Mass Tree 实现：UncP/aili，没有实现删除操作。

这是另一个实现：https://github.com/rmind/masstree，代码确实漂亮。他采用了激进生成子树的策略，缺点就是 cache locality 在有些情况下不好。

这是论文作者的实现：https://github.com/kohler/masstree-beta。

PS:

最后推荐一个算法，Palm Tree，这个算法很好地诠释了什么是大道至简。你可以在这个专栏之前的文章中找到其介绍。

The Art Of Multiprocessor Programming

2018-11-19T00:00:00+00:00

Chapter 2

Good `Lock` Algorithm

Mutual exclusion: critical section 不会发生重叠，即 $CS_{A}^{k}→CS_{B}^{j}$ or $CS_{B}^{j}→CS_{A}^{k}$
Freedom From Deadlock: 如果某个线程尝试加锁，那么某个线程会成功加锁。如果一个线程尝试加锁，但是始终不成功，那么一定是其他线程在完成无尽的 critical section
Freedom From Starvation: 所有尝试加锁的线程最终都会成功（Lockout Freedom）

2-Thread Solutions

`LockOne` Class

class LockOne implements Lock {
  private boolean[] flag = new boolean[2]; // thread-local index, 0 or 1

  public void lock() {
    int i = ThreadID.get();
    int j = 1 - i;
    flag[i] = true;        // write true
    while (flag[j]) {}     // read
  }

  public void unlock() {
    int i = ThreadID.get();
    flag[i] = false;
  }
}

满足1，

假设不满足1，那么 $lock_{A} → lock_{B}$ 成立，可以得出 $write_{A}(flag[A] = true) → read_{A}(flag[B] == false) → write_{B}(flag[B] = true) → read_{B}(flag[A] == false)$，即 $write_{A}(flag[A] = true) → read_{B}(flag[A] == false)$ ，矛盾，write true 操作后所有 read 操作都应该为 true，所以一定有 $unlock_{A}$ 操作发生在 $lock_{A}$ 和 $lock_{B}$ 之间。

但是不满足2，

两个线程在 read 操作之前都进行了 write true 操作，所以 read 结果一直为真。

`LockTwo` Class

class LockTwo implements Lock {
  private int victim;

  public void lock() {
    int i = ThreadID.get();
    victim = i;            // let the other go first
    while (victim == i) {} // wait
  }

  public void unlock() {}
}

满足1，

$CS_{A}: write_{A}(victim = A) → read_{A}(victim == B)$

$CS_{B}: write_{B}(victim = B) → read_{B}(victim == A)$

假设不满足1，那么 $lock_{A} → lock_{B}$ 成立，可以得出 $write_{A}(victim = A) → write_{B}(victim = B) → read_{A}(victim == B)$，但是 $victim == B$ 与 $CS_{B}$ 矛盾。

但是不满足2，

如果线程 B 在线程 A 之后执行，那么 B 将死锁。

LockOne 与 LockTwo 互为补充。

The Peterson Lock

class Peterson implements Lock {
  private boolean[] flag = new boolean[2]; // thread-local index, 0 or 1
  private int victim;
    
  public void lock() {
    int i = ThreadID.get();
    int j = 1 - i;
    flag[i] = true; // I’m interested
    victim = i;     // you go first
    while (flag[j] && victim == i) {} // wait
  }

  public void unlock() {
    int i = ThreadID.get();
    flag[i] = false; // I’m not interested
  }
}

满足1，

假设不满足1，那么 $lock_{A} → lock_{B}$ 成立，可以得出 $write_{A}(victim = A) → write_{B}(victim = B)$，即 $write_{B}(victim = B) → read_{B}(flag[A] == false)$，所以 $write_{A} (flag[A] = true) → write_{A} (victim = A) → write_{B}(victim = B) → read_{B}(flag[A] == false)$，即 $write_{A} (flag[A] = true) → read_{B}(flag[A] == false)$，矛盾。

满足3，

如果不满足3，那么对于任意线程（假设是 A）来说一定是在 while 循环中，即 $flag[B] == true$ 或 $victim == A$，那么对于 B 来说当它进入 lock() 时，会将 victim 设为 B，并且不会改变，所以 A 一定会被唤醒，矛盾。

满足3的同时一定满足2。

The Filter Lock

class Filter implements Lock {
  int[] level;
  int[] victim;
  
  public Filter(int n) {
    level = new int[n];
    victim = new int[n]; // use 1..n-1
    for (int i = 0; i < n; i++) {
      level[i] = 0;
    }
  }

  public void lock() {
    int me = ThreadID.get();
    for (int i = 1; i < n; i++) { // attempt level i
    level[me] = i;
    victim[i] = me;
    // spin while conflicts exist
    while ((∃k != me) (level[k] >= i && victim[i] == me)) {}
  }
      
  public void unlock() {
    int me = ThreadID.get();
    level[me] = 0;
  }
}

The Bakery Lock

二阶段保证公平性（fairness）
1. Doorway: 执行间隔是有限的
2. Waiting: 执行间隔可能是无限的

Frist Come Frist Served: 先结束 Doorway 阶段的线程先加锁

class Bakery implements Lock {
  boolean[] flag;
  Label[] label;

  public Bakery (int n) {
    flag = new boolean[n];
    label = new Label[n];
    for (int i = 0; i < n; i++) {
      flag[i] = false;
      label[i] = 0;
    }

  public void lock() {
    int i = ThreadID.get();
    flag[i] = true;
    label[i] = max(label[0], ..., label[n-1]) + 1;
    while ((∃k != i)(flag[k] && (label[k],k) << (label[i],i))) {}
  }

  public void unlock() {
    flag[ThreadID.get()] = false;
  }
}

Chapter 3

$Amdahl’s\ Law:\ S=\frac{1}{1-p+\frac{p}{n}}$

$p$: 一个任务可以被并发执行的比例

$n$: 线程数量

### quiescent(relaxed) consistency

Sequential Consistency

定义：

The result of any execution is the same as if the operations of all the processors were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program.

要求：

Each processor issues memory requests in the order specified by it’s program，first-appear, first-serve
Memory requests from all processors issued to an individual memory module are serviced from a single FIFO queue. Issuing a memory request consists of entering the request on this queue, first-come, first-serve

注意：

不保证 real time ordering，以下序列是合法的：
```
Enq(x) A
Ok()   A
Enq(y) B
Deq()  A
Ok()   B
Ok(y)  A
```
没有局部性（locality）
```
p Enq(x) A
p Ok()   A
q Enq(y) B   (1)
q Ok()   B
q Enq(x) A
q Ok()   A
p Enq(y) B   (2)
p Ok()   B
p Deq()  A
p Ok(y)  A   (3)
q Deq()  B
q Ok(x)  B   (4)
```
对于 p 和 q 来说满足顺序一致性，但是作为一个整体不满足，因为对于线程 A 来说，如果 (3) 成立，那么意味着 B 先执行了 (2)，同时意味着 B 先执行了 (1)，在这种情况下 (4) 无法成立。
非阻塞

Linearizability

定义：

$<{H}: e{0} <{H} e{1}\;if\;res(e_{0})\;precedes\;inv(e_{1})\;in\;H.$

complete(H’) 等价于某个合法化的顺序华历史 S
$<{H}\;\subseteq\;<{S}$

特点：

局部性，历史 H 中每个对象 x 是线性化的，才能保证 H 是线性化的。
非阻塞

Serializable

定义：

每个事务都没有交叉地顺序执行

Strict Serializable

定义：

每个事务在顺序化历史中的顺序和发生顺序相匹配，通常由二阶段锁保证，而不是 MVCC，也不是网络分区中提供 availability 的方法。

线性化可被视为对单个对象进行单个操作的特殊 strict serializability。

特点：

没有局部性，如 sequential consistency 中的 2（将 A 和 B 视为事务）
阻塞

Jemalloc

2018-11-16T00:00:00+00:00

JeMalloc

JeMalloc 是一款内存分配器，与其它内存分配器相比，它最大的优势在于多线程情况下的高性能以及内存碎片的减少。

这篇文章介绍 JeMalloc-5.1.0 版本（release 日期：2018年5月9日）的实现细节。

对于对老版本比较熟悉的人来说，有几点需要说明：

chunk 这一概念被替换成了 extent
dirty page 的 decay（或者说 gc）变成了两阶段，dirty -> muzzy -> retained
huge class 这一概念不再存在
红黑树不再使用，取而代之的是 pairing heap

基础知识

以下内容介绍 JeMalloc 中比较重要的概念以及数据结构。

size_class

每个 size_class 代表 jemalloc 分配的内存大小，共有 NSIZES（232）个小类（如果用户申请的大小位于两个小类之间，会取较大的，比如申请14字节，位于8和16字节之间，按16字节分配），分为2大类：

small_class（小内存） : 对于64位机器来说，通常区间是 [8, 14kb]，常见的有 8, 16, 32, 48, 64, …, 2kb, 4kb, 8kb，注意为了减少内存碎片并不都是2的次幂，比如如果没有48字节，那当申请33字节时，分配64字节显然会造成约50%的内存碎片
large_class（大内存）: 对于64位机器来说，通常区间是 [16kb, 7EiB]，从 4 * page_size 开始，常见的比如 16kb, 32kb, …, 1mb, 2mb, 4mb，最大是 $2^{62}+3^{60}$
size_index : size 位于 size_class 中的索引号，区间为 [0，231]，比如8字节则为0，14字节（按16计算）为1，4kb字节为28，当 size 是 small_class 时，size_index 也称作 binind

base

用于分配 jemalloc 元数据内存的结构，通常一个 base 大小为 2mb，所有 base 组成一个链表。

base.extents[NSIZES] : 存放每个 size_class 的 extent 元数据

bin

管理正在使用中的 slab（即用于小内存分配的 extent）的集合，每个 bin 对应一个 size_class

bin.slabcur : 当前使用中的 slab
bin.slabs_nonfull : 有空闲内存块的 slab

extent

管理 jemalloc 内存块（即用于用户分配的内存）的结构，每一个内存块大小可以是 N * page_size(4kb)（N >= 1）。每个 extent 有一个序列号（serial number）。

一个 extent 可以用来分配一次 large_class 的内存申请，但可以用来分配多次 small_class 的内存申请。

extent.e_bits : 8字节长，记录多种信息
extent.e_addr : 管理的内存块的起始地址
extent.e_slab_data : 位图，当此 extent 用于分配 small_class 内存时，用来记录这个 extent 的分配情况，此时每个 extent 的内的小内存称为 region

slab

当 extent 用于分配 small_class 内存时，称其为 slab。一个 extent 可以被用来处理多个同一 size_class 的内存申请。

extents

管理 extent 的集合。

extents.heaps[NPSIZES+1] : 各种 page(4kb) 倍数大小的 extent
extents.lru : 存放所有 extent 的双向链表
extents.delay_coalesce : 是否延迟 extent 的合并

arena

用于分配&回收 extent 的结构，每个用户线程会被绑定到一个 arena 上，默认每个逻辑 CPU 会有 4 个 arena 来减少锁的竞争，各个 arena 所管理的内存相互独立。

arena.extents_dirty : 刚被释放后空闲 extent 位于的地方
arena.extents_muzzy : extents_dirty 进行 lazy purge 后位于的地方，dirty -> muzzy
arena.extents_retained : extents_muzzy 进行 decommit 或 force purge 后 extent 位于的地方，muzzy -> retained
arena.large : 存放 large extent 的 extents
arena.extent_avail : heap，存放可用的 extent 元数据
arena.bins[NBINS] : 所以用于分配小内存的 bin
arena.base : 用于分配元数据的 base

内存状态	备注
clean	分配给用户或 `tcache`
dirty	用户调用 free 或 `tcache` 进行了 gc
muzzy	`extents_dirty` 对 `extent` 进行 lazy purge
retained	`extents_muzzy` 对 `extent` 进行了 decommit 或 force purge

purge 及 decommit 在内存 gc 模块介绍

rtree

全局唯一的存放每个 extent 信息的 Radix Tree，以 extent->e_addr 即 uintptr_t 为 key，以我的机器为例，uintptr_t 为64位（8字节）， rtree 的高度为3，由于 extent->e_addr 是 page(1 << 12) 对齐的，也就是说需要 64 - 12 = 52 位即可确定在树中的位置，每一层分别通过第0-16位，17-33位，34-51位来进行访问。

cache_bin

每个线程独有的用于分配小内存的缓存

low_water : 上一次 gc 后剩余的缓存数量
cache_bin.ncached : 当前 cache_bin 存放的缓存数量
cache_bin.avail : 可直接用于分配的内存，从左往右依次分配（注意这里的寻址方式）

tcache

每个线程独有的缓存（Thread Cache），大多数内存申请都可以在 tcache 中直接得到，从而避免加锁

tcache.bins_small[NBINS] : 小内存的 cache_bin

tsd

Thread Specific Data，每个线程独有，用于存放与这个线程相关的结构

tsd.rtree_ctx : 当前线程的 rtree context，用于快速访问 extent 信息
tsd.arena : 当前线程绑定的 arena
tsd.tcache : 当前线程的 tcache

内存分配（malloc）

小内存(small_class)分配

首先从 tsd->tcache->bins_small[binind] 中获取对应 size_class 的内存，有的话将内存直接返回给用户，如果 bins_small[binind] 中没有的话，需要通过 slab(extent) 对 tsd->tcache->bins_small[binind] 进行填充，一次填充多个以备后续分配，填充方式如下（当前步骤无法成功则进行下一步）：

通过 bin->slabcur 分配
从 bin->slabs_nonfull 中获取可使用的 extent
从 arena->extents_dirty 中回收 extent，回收方式为 best-fit，即满足大小要求的最小 extent，在 arena->extents_dirty->bitmap 中找到满足大小要求并且第一个非空 heap 的索引 i，然后从 extents->heaps[i] 中获取第一个 extent。由于 extent 可能较大，为了防止产生内存碎片，需要对 extent 进行分裂（伙伴算法），然后将分裂后不使用的 extent 放回 extents_dirty 中
从 arena->extents_muzzy 中回收 extent，回收方式为 first-fit，即满足大小要求且序列号最小地址最低（最旧）的 extent，遍历每个满足大小要求并且非空的 arena->extents_dirty->bitmap，获取其对应 extents->heaps 中第一个 extent，然后进行比较，找到最旧的 extent，之后仍然需要分裂
从 arena->extents_retained 中回收 extent，回收方式与 extents_muzzy 相同
尝试通过 mmap 向内核获取所需的 extent 内存，并且在 rtree 中注册新 extent 的信息
再次尝试从 bin->slabs_nonfull 中获取可使用的 extent

简单来说，这个流程是这样的，cache_bin -> slab -> slabs_nonfull -> extents_dirty -> extents_muzzy -> extents_retained -> kernal。

大内存(large_class)分配

大内存不存放在 tsd->tcache 中，因为这样可能会浪费内存，所以每次申请都需要重新分配一个 extent，申请的流程和小内存申请 extent 流程中的3, 4, 5, 6是一样的。

内存释放（free）

小内存释放

在 rtree 中找到需要被释放内存所属的 extent 信息，将要被释放的内存还给 tsd->tcache->bins_small[binind]，如果 tsd->tcache->bins_small[binind] 已满，需要对其进行 flush，流程如下：

将这块内存返还给所属 extent，如果这个 extent 中空闲的内存块变成了最大（即没有一份内存被分配），跳到2；如果这个 extent 中的空闲块变成了1并且这个 extent 不是 arena->bins[binind]->slabcur，跳到3
将这个 extent 释放，即插入 arena->extents_dirty 中
将 arena->bins[binind]->slabcur 切换为这个 extent，前提是这个 extent “更旧”（序列号更小地址更低），并且将替换后的 extent 移入 arena->bins[binind]->slabs_nonfull

大内存释放

因为大内存不存放在 tsd->tcache 中，所以大内存释放只进行小内存释放的步骤2，即将 extent 插入 arena->extents_dirty 中。

内存再分配（realloc）

小内存再分配

尝试进行 no move 分配，如果两次申请位于同一 size class 的话就可以不做任何事情，直接返回。比如第一次申请了12字节，但实际上 jemalloc 会实际分配16字节，然后第二次申请将12扩大到15字节或者缩小到9字节，那这时候16字节就已经满足需求了，所以不做任何事情，如果无法满足，跳到2
重新分配，申请新内存大小（参考内存分配），然后将旧内存内容拷贝到新地址，之后释放旧内存（参考内存释放），最后返回新内存

大内存再分配

尝试进行 no move 分配，如果两次申请位于同一 size class 的话就可以不做任何事情，直接返回。
尝试进行 no move resize 分配，如果第二次申请的大小大于第一次，则尝试对当前地址所属 extent 的下一地址查看是否可以分配，比如当前 extent 地址是 0x1000，大小是 0x1000，那么我们查看地址 0x2000 开始的 extent 是否存在（通过 rtree）并且是否满足要求，如果满足要求那两个 extent 可以进行合并，成为一个新的 extent 而不需要重新分配；如果第二次申请的大小小于第一次，那么尝试对当前 extent 进行 split，移除不需要的后半部分，以减少内存碎片；如果无法进行 no move resize 分配，跳到3
重新分配，申请新内存大小（参考内存分配），然后将旧内存内容拷贝到新地址，之后释放旧内存（参考内存释放），最后返回新内存

内存 GC

分为2种， tcache 和 extent GC。其实更准确来说是 decay，为了方便还是用 gc 吧。

tcache GC

针对 small_class，防止某个线程预先分配了内存但是却没有实际分配给用户，会定期将缓存 flush 到 extent。

GC 策略

每次对于 tcache 进行 malloc 或者 free 操作都会执行一次计数，默认情况下达到228次就会触发 gc，每次 gc 一个 cache_bin。

如何 GC

cache_bin.low_water > 0 : gc 掉 low_water 的 3/4，同时，将 cache_bin 能缓存的最大数量缩小一倍
cache_bin.low_water < 0 : 将 cache_bin 能缓存的最大数量增大一倍

总的来说保证当前 cache_bin 分配越频繁，则会缓存更多的内存，否则则会减少。

extent GC

调用 free 时，内存并没有归还给内核。 jemalloc 内部会不定期地将没有用于分配的 extent 逐步 GC，流程和内存申请是反向的， free -> extents_dirty -> extents_muzzy -> extents_retained -> kernal。

GC 策略

默认10s为 extents_dirty 和 extents_muzzy 的一个 gc 周期，每次对于 arena 进行 malloc 或者 free 操作都会执行一次计数，达到1000次会检测有没有达到 gc 的 deadline，如果是的话进行 gc。

注意并不是每隔10s一次性 gc，实际上 jemalloc 会将10s划分成200份，即每隔0.05s进行一次 gc，这样一来如果 t 时刻有 N 个 page 需要 gc，那么 jemalloc 尽力保证在 t+10 时刻这 N 个 page 会被 gc 完成。

严格来说，对于两次 gc 时刻 $t_{1}$ 和 $t_{2}$，在 $t_{2}-t_{1}$ 时间段内产生的所有 page（dirty page 或 muzzy page）会在 ($t_{2}$, $ t_{2}+10$] 被 gc 完成。

对于 N 个需要 gc 的 page 来说，并不是简单地每0.05s处理 N/200 个 page，jemalloc 引入了 Smoothstep（主要用于计算机图形学）来获得更加平滑的 gc 机制，这是 jemalloc 非常有意思的一个点。

jemalloc 内部维护了一个长度为200的数组，用来计算在10s的 gc 周期内每个时间点应该对多少 page 进行 gc。这样保证两次 gc 的时间段内产生的需要 gc 的 page 都会以图中绿色线条（默认使用 smootherstep）的变化曲线在10s的周期内从 N 减为 0（从右往左）。

如何 GC

先进行 extents_dirty 的 gc，后进行 extents_muzzy 。

将 extents_dirty 中的 extent 移入 extents_muzzy：
1. 在 extents_dirty 中的 LRU 链表中，获得要进行 gc 的 extent，尝试对 extent 进行前后合并（前提是两个 extent 位于同一 arena 并且位于同一 extents 中），获得新的 extent，然后将其移除
2. 对当前 extent 管理的地址进行 lazy purge，即通过 madvise 使用 MADV_FREE 参数告诉内核当前 extent 管理的内存可能不会再被访问
3. 在 extents_muzzy 中尝试对当前 extent 进行前后合并，获得新的 extent，最后将其插入 extents_muzzy
将 extents_muzzy 中的 extent 移入 extents_retained :
1. 在 extents_muzzy 中的 LRU 链表中，获得要进行 gc 的 extent，尝试对 extent 进行前后合并，获得新的 extent，然后将其移除
2. 对当前 extent 管理的地址进行 decommit，即调用 mmap 带上 PROT_NONE 告诉内核当前 extent 管理的地址可能不会再被访问，如果 decommit 失败，会进行 force purge，即通过 madvise 使用 MADV_DONTNEED 参数告诉内核当前 extent 管理的内存可能不会再被访问
3. 在 extents_retained 中尝试对当前 extent 进行前后合并，获得新的 extent，最后将其插入 extents_retained
jemalloc 默认不会将内存归还给内核，只有进程结束时，所有内存才会 munmap，从而归还给内核。不过可以手动进行 arena 的销毁，从而将 extents_retained 中的内存进行 munmap

内存碎片

JeMalloc 保证内部碎片在20%左右。对于绝大多数 size_class 来说，都属于 $2^{x}$ 的 group $y$，比如 160，192，224，256都属于 $2^{8-1}$ 的 group 7。对于一个 group 来说，会有4个 size_class，每个 size 的大小计算是这样的，$(1 « y) + (i « (y-2))$，其中 i 为在这个 group 中的索引（1，2，3，4），比如 160 为 $(1 « 7) + (1 « 5)$，即 $5 * 2^{7-2}$。

对于两组 group 来说：

Group	Size
y	$5 * 2^{y-2}$, $6 * 2^{y-2}$, $7 * 2^{y-2}$, $8 * 2^{y-2}$
y+1	$5 * 2^{y-1}$, $6 * 2^{y-1}$, $7 * 2^{y-1}$, $8 * 2^{y-1}$

取相差最大的第一组的最后一个和第二组的第一个，内存碎片约为 $\frac{5 * 2^{y-1} - 8 * 2^{y-2} + 1}{5 * 2^{y-1}}$ 约等于 20%。

JeMalloc 实现上的优缺点

优点

采用多个 arena 来避免线程同步
细粒度的锁，比如每一个 bin 以及每一个 extents 都有自己的锁
Memory Order 的使用，比如 rtree 的读写访问有不同的原子语义（relaxed, acquire, release）
结构体以及内存分配时保证对齐，以获得更好的 cache locality
cache_bin 分配内存时会通过栈变量来判断是否成功以避免 cache miss
dirty extent 的 delay coalesce 来获得更好的 cache locality；extent 的 lazy purge 来保证更平滑的 gc 机制
紧凑的结构体内存布局来减少占用空间，比如 extent.e_bits
rtree 引入 rtree_ctx 的两级 cache 机制，提升 extent 信息获取速度的同时减少 cache miss
tcache gc 时对缓存容量的动态调整

缺点

arena 之间的内存不可见
- 某个线程在这个 arena 使用了很多内存，之后这个 arena 并没有其他线程使用，导致这个 arena 的内存无法被 gc，占用过多
- 两个位于不同 arena 的线程频繁进行内存申请，导致两个 arena 的内存出现大量交叉，但是连续的内存由于在不同 arena 而无法进行合并
目前只想到了一个

总结

文章开头说 JeMalloc 的优点在于多线程下的性能以及内存碎片的减少，对于保证多线程性能，有不同 arena、降低锁的粒度、使用原子语义等等；对于内存碎片的减少，有经过设计的多种 size_class、伙伴算法、gc 等等。

阅读 JeMalloc 源码的意义不光在于能够精确描述每次 malloc 和 free 会发生什么，还在于学习内存分配器如何管理内存。malloc 和 free 是静态的释放和分配，而 tcache 和 extent 的 gc 则是动态的管理，熟悉后者同样非常重要。

除此以外还能够帮助自己在编程时根据相应的内存使用特征去选择合适的内存分配方法，甚至使用自己实现的特定内存分配器。

最后个人觉得 jemalloc 最有意思的地方就在于 extent 的曲线 gc 了。

参考

TCMalloc分析 - 如何减少内存碎片

TCMalloc

UncP’s Blog

Adaptive Radix Tree

Adaptive Radix Tree

Node4

Node16

Node48

Node256

Path Compression & Lazy Expansion

查找算法

插入算法

删除算法

Multi-ART

设计

性能

总结

4 Modifications For Raft Consensus

全局唯一的数据库 ID

作用

Pre-Vote

作用

行为

Leader stickness

作用

行为

Mass Tree

Mass Tree 结构

Mass Tree 算法

并发策略

下降流程

插入流程

分裂流程

读取流程

删除流程

Mass Tree 优化

Mass Tree 总结

PS:

The Art Of Multiprocessor Programming

Chapter 2

Good Lock Algorithm

2-Thread Solutions

LockOne Class

LockTwo Class

The Peterson Lock

The Filter Lock

The Bakery Lock

Chapter 3

Sequential Consistency

Linearizability

Serializable

Strict Serializable

Jemalloc

JeMalloc

基础知识

size_class

base

bin

extent

slab

extents

arena

rtree

cache_bin

tcache

tsd

内存分配（malloc）

小内存(small_class)分配

大内存(large_class)分配

内存释放（free）

小内存释放

大内存释放

内存再分配（realloc）

小内存再分配

大内存再分配

内存 GC

tcache GC

extent GC

内存碎片

JeMalloc 实现上的优缺点

优点

缺点

Good `Lock` Algorithm

`LockOne` Class

`LockTwo` Class