multiprocessing.Array内存分配机制疑问：为何可分配超过物理RAM容量的数组？

核心底层逻辑说明 #

• 内存超售与延迟分配机制
  Linux系统默认开启内存超售（Overcommit）策略，你调用接口申请内存时，内核只会给你分配虚拟地址空间，不会直接预留物理RAM。只有当你真正读写某一段内存地址时，内核才会通过缺页中断给对应地址分配物理内存页。只要你没有实际写入超过物理内存容量的数据，就算申请的虚拟内存远大于物理RAM，也可以创建成功、不会触发swap，这就是你能创建大于32GB数组的核心原因。
• 共享内存的统计逻辑
  multiprocessing.Array默认基于/dev/shm下的tmpfs文件实现，tmpfs是完全跑在内存中的文件系统，它占用的空间系统会统一统计到buff/cache（也就是htop里的黄色缓存区域）。htop里的绿色已用内存是进程的常驻内存（RSS），统计的是当前进程实际访问过、已经映射到进程地址空间的物理页大小。
  你创建小容量数组时绿色内存同步上涨，是因为小内存块申请后内核会做预分配，加上你后续访问了数组元素，对应的物理页被计入进程RSS；创建20GB这类大容量数组时，内核不会做预分配，你只访问了数组最后一个元素，只有这1个4KB/16KB的内存页被映射计入RSS，剩下的区域只占虚拟地址空间，所以绿色内存几乎无变化，整体申请的共享内存容量统计在黄色缓存区域。
• 访问速度无差异的原因
  tmpfs的所有数据本身就存储在物理内存中，htop里的黄色缓存只是统计分类，和读写磁盘用的磁盘缓存不是一回事。只要是已经分配了物理页的内存，不管统计在RSS还是缓存分类下，访问速度都是物理内存的读写速度，完全没有性能差异。

实际场景使用建议 #

你在8GB内存设备上用作摄像头缓冲区时，只要6个共享内存数组的实际写入总数据量不超过设备的可用物理内存（扣除系统、其他进程占用后一般剩余6-7GB），就算部分内存统计在缓存区域也不会有任何性能问题。只有当实际写入的数据量超过可用物理内存时，才会触发OOM杀进程或者swap写入，才会影响运行稳定性和性能。

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