CS架构
Android 平台第一个想到的就是 ContentProvider：一个单独进程管理数据，数据同步不易出错，简单好用易上手。然而它的问题也很明显，就是一个字慢：启动慢，访问也慢。这个可以说是 Android 下基于 Binder 的 CS 架构组件的通用痛点。至于其他的 CS 架构，例如经典的 socket、PIPE、message queue，因为要至少 2 次的内存拷贝，就更加慢了。
共享内存架构
使用 mmap 实现，只需要将文件 mmap 到每个访问进程的内存空间，加上合适的进程锁，再处理好数据的同步，就能够实现多进程并发访问。
进程锁
Android 是个阉割版的 Linux，IPC 组件的支持比较残缺。例如，说到进程锁第一个想到的就是 pthread 库的 pthread_mutex，创建于共享内存的 pthread_mutex 是可以用作进程锁的，然而 Android 版的 pthread_mutex 并不保证robust，亦即对 pthread_mutex 加了锁的进程被 kill，系统不会进行清理工作，这个锁会一直存在下去，那么其他等锁的进程就会永远饿死。其他的 IPC 组件，例如信号量、条件变量，也有同样问题，Android 为了能够尽快关闭进程，真是无所不用其极。
能够保证 robust 的，只有已打开的文件描述符，以及基于文件描述符的文件锁和 Binder 组件的死亡通知
实现细节
将文件 mmap 到内存块中，将新增的 key-value 统统 append 到内存中；到达边界后，进行重整回写以腾出空间，空间还是不够的话，就 double 内存空间；对于内存文件中可能存在的重复键值，MMKV 只选用最后写入的作为有效键值。那么其他进程为了保持数据一致，就需要处理这三种情况：写指针增长、内存重整、内存增长。但首先还得解决一个问题：怎么让其他进程感知这三种情况？
状态同步
写指针的同步
我们可以在每个进程内部缓存自己的写指针，然后在写入键值的同时，还要把最新的写指针位置也写到 mmap 内存中；这样每个进程只需要对比一下缓存的指针与 mmap 内存的写指针，如果不一样，就说明其他进程进行了写操作。事实上 MMKV 原本就在文件头部保存了有效内存的大小，这个数值刚好就是写指针的内存偏移量，我们可以重用这个数值来校对写指针。
内存重整的感知
考虑使用一个单调递增的序列号，每次发生内存重整，就将序列号递增。将这个序列号也放到 mmap 内存中，每个进程内部也缓存一份，只需要对比序列号是否一致，就能够知道其他进程是否触发了内存重整。
内存增长的感知
事实上 MMKV 在内存增长之前，会先尝试通过内存重整来腾出空间，重整后还不够空间才申请新的内存。所以内存增长可以跟内存重整一样处理。至于新的内存大小，可以通过查询文件大小来获得，无需在 mmap 内存另外存放。
写指针的增长
当一个进程发现 mmap 写指针增长，就意味着其他进程写入了新键值。这些新的键值都 append 在原有写指针后面，可能跟前面的 key 重复，也可能是全新的 key，而原写指针前面的键值都是有效的。那么我们就要把这些新键值都读出来，插入或替换原有键值，并将写指针同步到最新位置。
内存重整
当一个进程发现内存被重整了，就意味着原写指针前面的键值全部失效，那么最简单的做法是全部抛弃掉，从头开始重新加载一遍。
实现递归锁
意思是如果一个进程/线程已经拥有了锁，那么后续的加锁操作不会导致卡死，并且解锁也不会导致外层的锁被解掉。对于文件锁来说，前者是满足的，后者则不然。因为文件锁是状态锁，没有计数器，无论加了多少次锁，一个解锁操作就全解掉。只要用到子函数，就非常需要递归锁。
加写锁时，如果当前已经持有读锁，那么先尝试加写锁，try_lock 失败说明其他进程持有了读锁，我们需要先将自己的读锁释放掉，再进行加写锁操作，以避免死锁的发生。
解写锁时，假如之前曾经持有读锁，那么我们不能直接释放掉写锁，这样会导致读锁也解了。我们应该加一个读锁，将锁降级。
网友评论