如何在不使用Boost的情况下创建共享内存中的unordered_map？

1. 共享内存+自定义哈希表结构 #

标准库unordered_map依赖堆内存（非连续分布），指针无法跨进程生效，所以可以自己实现一个基于连续共享内存块的哈希表：

• 调用系统API创建共享内存（Linux用shm_open+mmap，Windows用CreateFileMapping+MapViewOfFile），确保两个进程能访问同一块内存区域。
• 在共享内存内定义连续结构：比如预分配的键值对节点数组、哈希桶偏移量表（用偏移量代替指针，避免跨进程地址失效），所有数据都放在这块内存里。
• 自己实现哈希碰撞处理（比如链地址法中，链表节点的"指针"用相对于共享内存起始地址的偏移量表示）。
• 必须加进程间同步机制：用共享内存中的互斥锁（Linuxpthread_mutex_t需初始化时设置共享属性，Windows用Mutex）或读写锁，保证写进程修改时读进程不会读取到不一致的数据。

伪代码示例：

// 共享内存中的哈希表结构
struct SharedHashNode {
    char key[64];
    char value[256];
    uint32_t next_offset; // 用偏移量代替指针，指向共享内存中的下一个节点
};

struct SharedHashMap {
    uint32_t bucket_count;
    uint32_t used_nodes;
    uint32_t bucket_offsets[1024]; // 哈希桶的偏移量数组
    SharedHashNode nodes[4096]; // 预分配的节点存储区
};

// 写入进程逻辑
int shm_fd = shm_open("/shared_hash", O_CREAT | O_RDWR, 0666);
ftruncate(shm_fd, sizeof(SharedHashMap));
SharedHashMap* map = (SharedHashMap*)mmap(NULL, sizeof(SharedHashMap), PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0);
// 初始化结构、加锁、插入键值对...

// 读取进程逻辑
int shm_fd = shm_open("/shared_hash", O_RDONLY, 0666);
SharedHashMap* map = (SharedHashMap*)mmap(NULL, sizeof(SharedHashMap), PROT_READ, MAP_SHARED, shm_fd, 0);
// 加读锁、遍历哈希桶查找数据...

2. 内存映射文件模拟共享内存 #

如果觉得原生共享内存API繁琐，可以用内存映射文件：

• 创建一个磁盘文件，将其映射到两个进程的地址空间，本质和共享内存逻辑一致，但数据会持久化到磁盘，进程重启后数据不会丢失。
• 同样在映射区域内放置自定义的连续哈希结构，同步机制和上述方案相同。

3. 消息队列/管道做间接同步 #

如果不想手动实现共享哈希表，可以让写进程把unordered_map的变更序列化（比如转成二进制格式、JSON或Protobuf），通过命名管道或消息队列发送给读进程，读进程在本地维护一份unordered_map副本。

• 优点是实现简单，无需处理共享内存的复杂结构；缺点是数据有延迟，读进程拿到的是副本而非实时原数据，数据量大时序列化开销较高。

4. 轻量级IPC库替代Boost #

如果只是不想引入庞大的Boost，可以选择轻量级跨平台IPC库：

• libuv：支持共享内存、消息队列等多种IPC方式，集成成本低。
• nng：轻量级消息传递库，可高效实现进程间数据交换，省去手动实现的麻烦。

内容的提问来源于stack exchange，提问作者nick