使用mmap()实现跨进程共享内存的两处技术疑问咨询

嘿，这两个问题都是用mmap实现进程间共享内存时非常典型的场景，我来帮你拆解清楚：

其实有几种更靠谱的方式，比管道直接传地址要稳妥：

• 命令行参数传递：把共享内存的虚拟地址转换成字符串（比如转成无符号长整型再转字符串），作为execve的argv参数传给子进程。子进程拿到后再转成指针类型就行。不过要注意，不同进程的虚拟地址空间是独立的，直接传虚拟地址的做法并不具备可移植性，某些场景下可能失效。
• 环境变量传递：和命令行参数逻辑类似，把地址转成字符串后存入环境变量，子进程通过getenv获取再转换。这种方式适合不想占用命令行参数的场景，但要注意环境变量的长度限制。
• 基于文件的映射（最推荐）：如果你的共享内存是基于磁盘文件或者匿名文件（比如用memfd_create创建的），那根本不需要传递地址！子进程只需要用同一个文件描述符或者文件路径再次调用mmap，就能映射到同一块物理内存区域。这是规范的做法，完全避开了虚拟地址不兼容的问题。

你遇到的情况大概率是这几个问题之一：

• 映射参数不匹配：父进程和子进程的mmap参数必须完全对齐！比如父进程用了MAP_SHARED（共享修改），子进程却用了MAP_PRIVATE（私有拷贝），那子进程根本看不到父进程的数据；再比如父进程设置了PROT_WRITE，子进程却只开了PROT_READ，写操作会直接触发段错误。
• 匿名映射的局限性：如果父进程用的是MAP_ANONYMOUS | MAP_SHARED这种匿名映射，它只能通过fork继承的方式在父子进程间共享。一旦你用execve替换了子进程的地址空间，原来的映射会被销毁，子进程拿到的地址自然是无效的。这种情况必须换成基于文件的映射，或者用memfd_create创建匿名文件描述符传递给子进程后再映射。
• 虚拟地址无效：如果是直接传递父进程的虚拟地址，子进程的地址空间和父进程完全独立，这个地址在子进程里可能指向随机内存甚至无效区域，根本不是共享内存的位置。这也是为什么不推荐直接传虚拟地址的原因。
• 同步问题：父进程是不是在execve启动子进程之前，还没把数据写完？如果子进程先于父进程完成数据写入就去读取，拿到的就是未初始化的垃圾数据。这时候可以用信号量、互斥锁或者简单的管道信号来做同步，确保父进程写完数据后子进程再读。

给你举个基于文件映射的简单示例，避免踩坑：
父进程代码片段：

// 创建并打开共享文件
int fd = open("shared_int_arr.bin", O_RDWR | O_CREAT | O_TRUNC, 0666);
// 分配10个int的空间
ftruncate(fd, sizeof(int) * 10);
// 映射到内存
int *shmem = mmap(NULL, sizeof(int)*10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
// 写入数据
shmem[0] = 42;
shmem[1] = 100;
// 关闭文件描述符，映射依然有效
close(fd);

// 启动子进程，把文件名作为参数传递
char *argv[] = {"./child_process", "shared_int_arr.bin", NULL};
execve("./child_process", argv, environ);

子进程代码片段：

// 打开父进程创建的共享文件
int fd = open(argv[1], O_RDWR);
// 同样参数映射内存
int *shmem = mmap(NULL, sizeof(int)*10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
// 读取数据，应该能拿到42和100
printf("shmem[0] = %d, shmem[1] = %d\n", shmem[0], shmem[1]);
// 释放映射
munmap(shmem, sizeof(int)*10);
close(fd);

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