Let’s break down your questions thoroughly, using the details you’ve shared about your setup and error logs.

1. 64位Linux MATLAB中，除普通RAM外触发"Out of Memory"的其他资源 #

Yes, there are several factors beyond physical RAM that can trigger this error, even on 64-bit systems:

• 连续虚拟地址空间耗尽: 64位系统理论上有极大的地址空间，但MATLAB数组要求内存块是连续的。如果程序反复创建、释放大量中小数组，内存会逐渐碎片化——总空闲内存足够，但找不到一块足够大的连续空间来容纳你要创建的数组（比如报错中的cat(2,...)操作）。
• 进程内存限制: Linux通过ulimit设置进程级资源限制。你可以在启动MATLAB的同一个shell里执行ulimit -v，检查是否给MATLAB设置了虚拟内存上限。如果这个上限小于代码需要的连续内存块大小，哪怕有空闲RAM/交换空间，也会触发OOM。
• MATLAB内部内存池耗尽: MATLAB会为小对象管理自己的内存池，如果这些池碎片化或耗尽（哪怕系统内存还有剩余），依赖它们的操作也会抛出OOM错误。
• 交换空间访问限制: 虽然你的VmSwap显示为0（还没用到交换空间），但如果系统swappiness设置极低，或者交换空间被其他进程占用，MATLAB可能无法在需要时使用它。不过这显然不是你这次的问题。

2. 该错误是否与内存碎片有关？ #

绝对是——这是你当前场景最可能的原因。

你的日志显示MATLAB仅占用了约3GB内存（远小于12GB物理RAM+32GB交换空间），却在横向拼接数组（horzcat）时崩溃。cat(2,...)操作需要分配一块连续的内存来存储合并后的数组。如果内存被拆分成大量零散的空闲块，哪怕总空闲内存足够，也找不到足够大的连续块——直接触发OOM错误。

另外，不同参数配置下错误发生在不同程序位置，也佐证了这一点：不同参数对应不同的数组大小，触发“找不到足够大连续块”的阈值位置也就不同。

3. 如何测量当前内存碎片的程度？ #

你可以从Linux系统层面和MATLAB内部两个维度来测量：

Linux系统工具 #

• /proc/[pid]/smaps: 这个文件详细记录了MATLAB进程的内存映射。你可以查找空闲内存区域，检查是否有足够大的连续空闲块。执行以下命令：

  grep -A 3 -B 3 "free" /proc/14123/smaps
  

  它会展示空闲内存段及其大小。如果看到大量小空闲块，却没有大的连续块，说明碎片化严重。
• pmap -x [pid]: 这个命令会列出进程的所有内存段，包括段大小、驻留集大小（RSS）和脏页。如果看到大量零散的小分配段，就说明存在内存碎片。

MATLAB内部工具 #

• memory命令: 在MATLAB中执行这个命令（在错误发生前，或者在代码关键节点添加），可以看到：
  • Maximum possible array size: 这是MATLAB当前能分配的最大连续内存块大小。如果这个数值远小于总可用内存，就说明碎片化问题严重。
  • Memory used by MATLAB vs Physical Memory (RAM): 对比这两个值，确认总内存不足不是问题所在。
• pack命令: 这更偏向修复而非测量，但执行pack会强制MATLAB整理内存——把所有已分配数据移到连续块，释放碎片化空间。如果这个操作能延迟或避免OOM错误，就说明碎片化确实是根源。

额外的优化建议 #

• 预分配数组: 不要动态扩展数组（比如array = [array, new_data]），而是用array = zeros(n,m)这类命令预先分配完整大小的数组，避免创建大量导致碎片化的中间数组。
• 显式清理无用变量: 用clear varname删除不再需要的变量（尤其是大数组），给MATLAB更多可用内存。
• 避免用嵌套元胞数组存储大数据: 元胞数组的每个元素都是独立内存块，更容易导致碎片化，尽量改用结构体数组或连续矩阵。

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