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 中基本无效，不要依赖它
正确配置方式：临时与永久
临时限制（适合调试或单次运行）：
- 在运行可疑程序前执行：
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）定位泄漏点，而非仅靠堵漏
