ulimit -v 不能防止内存泄漏，但能限制进程虚拟内存总量，避免单个失控进程耗尽系统地址空间；它通过拦截 brk/mmap/mremap 系统调用并在超限时返回 enomem 来终止进程，仅作用于当前 shell 及其子进程，单位为 kb，且不回收已泄漏内存。

ulimit -v 不能防止内存泄漏，但能限制进程虚拟内存总量，避免单个失控进程耗尽系统地址空间。关键在于理解它拦的是“申请行为”，不是“泄漏本身”。

ulimit -v 实际起作用的原理

设置 ulimit -v 后，内核会对该进程后续所有 brk()、mmap() 和 mremap() 系统调用做检查。一旦累计申请的虚拟地址空间（AS，Address Space）超过设定值，调用直接返回 ENOMEM，进程通常会崩溃或报错退出。

• 它限制的是 虚拟内存总量（含代码段、数据段、堆、栈、映射文件等），不是 RSS 或物理内存
• 单位是 KB，例如 ulimit -v 1048576 表示限制为 1GB 虚拟地址空间
• 只对当前 shell 及其启动的子进程生效，不作用于已运行进程
• -m（RSS 限制）在现代 Linux 中基本无效，不要依赖它

正确配置方式：临时与永久

临时限制（适合调试或单次运行）：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 在运行可疑程序前执行：ulimit -v 524288 && ./leaky_app（限制 512MB）
• 查看当前值：ulimit -v；显示 unlimited 表示无限制

永久限制（按用户或服务）：

• 编辑 /etc/security/limits.conf，添加（以用户 john 为例）：
  

  john soft as 536870912<br>john hard as 536870912

  
  其中 as 即 address space，单位为字节；soft 可被用户临时下调，hard 是不可突破的上限
• 需用户重新登录或重启 PAM 会话才生效（SSH 登录、图形界面登录均触发 PAM）
• systemd 服务建议直接用 MemoryMax=，比 ulimit 更可靠

为什么它只能“缓解”，不能“防止”内存泄漏

内存泄漏的本质是程序持续 malloc/mmap 但不 free/munmap，导致地址空间和物理内存双双增长。ulimit -v 的作用是：

• 在泄漏进程尝试分配第 N+1 次内存时卡住，提前终止它，避免拖垮整机
• 给运维争取响应时间，比如配合监控告警发现异常进程
• 无法修复代码缺陷，也无法回收已泄漏的内存块
• 若泄漏发生在共享库或子进程中，且主进程未受限制，仍可能绕过

搭配使用的实用建议

• 监控配合：ps aux --sort=-vsz | head -10 快速查看虚拟内存占用 Top 进程
• 日志兜底：在 limits.conf 中加 john hard core 0 防止大 core 文件占满磁盘
• 优先用 cgroup：对关键服务（如 Java 应用、Node.js 服务），用 systemd 的 MemoryMax= 或手动挂载 cgroup v2 更精准
• 真正治本：用 Valgrind、eBPF 工具（如 memleak）定位泄漏点，而非仅靠堵漏