LMDB（Lightning Memory-Mapped Database）以其极高的读性能和紧凑的存储结构，在嵌入式系统、特征存储和模型参数缓存中被广泛使用。但在实际部署中，工程师经常碰到“database lock conflict”或“resource temporarily unavailable”的报错，尤其是在多个进程同时访问同一环境目录时。与此同时，若初始化时map size估计不足，后续写入会直接失败。理解LMDB的锁模型与内存映射机制，是排除这类故障的前提。
LMDB锁机制与多进程读取原理
LMDB在操作系统层面依赖一个文件锁（在Linux下通常是flock，Windows下为LockFileEx）来保护写事务的独占性。读事务并不持有写锁，因此多个进程可以各自开启只读事务并并发读取，这正是LMDB被称为“多读单写”数据库的原因。环境目录中的lock.mdb文件就是锁载体，而data.mdb则是内存映射的主数据文件。当某个进程以写模式打开环境且未正确关闭，或另一个进程以互斥方式重复打开时，就会引发锁冲突。
很多人在多进程场景下直接复用同一份env句柄而没有区分角色，或者错误地在只读进程里调用了env.open(path)的默认写模式，这会尝试获取写锁。正确的做法是：读取方显式声明readonly=True（Python）或MDB_RDONLY（C++），并且设置lock=True以允许读锁共存。LMDB的锁是建议性锁，配合内存映射，读取进程只需映射同一文件即可，无需复制数据。
下面是一段Python中多进程安全读取的示例，子进程以只读方式打开已有环境，主进程负责写入，二者不会互相阻塞：
import lmdb
import multiprocessing
def reader_proc(path):
# 子进程以只读模式打开，不获取写锁
env = lmdb.open(path, readonly=True, lock=True, readahead=False, meminit=False)
with env.begin() as txn:
val = txn.get(b'key1')
print('reader got:', val)
env.close()
if __name__ == '__main__':
path = './test_lmdb'
writer = lmdb.open(path, map_size=1 << 30)
with writer.begin(write=True) as txn:
txn.put(b'key1', b'hello')
p = multiprocessing.Process(target=reader_proc, args=(path,))
p.start()
p.join()
writer.close()
Map Size的作用与动态调整策略
map size决定了LMDB通过mmap映射到进程地址空间的最大文件尺寸。它在环境创建时设定，并直接限制data.mdb的增长上限。如果写入的数据总量超过map size，LMDB会抛出MAP_FULL错误，而不是自动扩容。由于mmap区域在打开时固定，运行期不能随意缩小，但可以通过关闭后以更大的map size重新打开来实现扩容。
预估map size时，需要考虑键值对膨胀、空闲页复用率以及B+树内部节点开销。一般建议设置为预期数据量的1.5到2倍。在C++中，可以通过mdb_env_set_mapsize在open之前设置；Python则在lmdb.open传入map_size参数。注意，map size过大会占用虚拟地址空间，在32位进程里容易耗尽地址段，因此64位程序更为安全。
下面的C++代码展示了如何以2GB的map size打开环境，并在捕获到扩容需求时关闭并以更大尺寸重建：
#include <lmdb.h>
#include <iostream>
int main() {
MDB_env* env;
mdb_env_create(&env);
// 设置映射大小为2GB
mdb_env_set_mapsize(env, 2ULL << 30);
int rc = mdb_env_open(env, "./test_lmdb", 0, 0664);
if (rc == MDB_MAP_FULL) {
mdb_env_close(env);
mdb_env_create(&env);
mdb_env_set_mapsize(env, 4ULL << 30);
rc = mdb_env_open(env, "./test_lmdb", 0, 0664);
}
if (rc != 0) {
std::cerr << "open failed: " << mdb_strerror(rc) << std::endl;
}
mdb_env_close(env);
return 0;
}
常见冲突场景与避坑实践
第一种典型冲突是同一环境被多次以写模式打开。LMDB允许一个进程内多个句柄，但跨进程写锁互斥。若容器化部署时多个Pod挂载同一网络盘并都尝试写，就会频繁锁死。此时应明确单一写者，其余全部只读，或使用外部协调服务选主。
第二种误区是误删lock.mdb。有些运维为“释放锁”手动删除该文件，结果导致写事务状态不一致甚至数据损坏。lock.mdb只记录锁，删除它不会解锁，反而让后续打开者重新建锁但旧写者仍映射旧文件。正确释放锁的方式是正常关闭所有env句柄。
最后，使用subdir=False时要确保路径指向具体文件而非目录，否则在多进程下路径解析差异也会表现为锁异常。建议在初始化阶段统一路径规范，并通过健康检查确认env.stat()返回的map size与页使用量，防患于未然。