软限制可由用户调整但不能超硬限制，硬限制仅root可改；nofile过低致“Too many open files”，建议生产设soft/hard为65536+；stack过小引发栈溢出，宜设8MB或2–4MB；-v/-d限制现多由cgroups接管，慎用。
软限制和硬限制是 Linux 中 ulimit 控制资源使用的核心机制，直接影响进程能否正常启动、稳定运行甚至并发能力。软限制可由用户自行调整（但不能超过硬限制），硬限制只能由 root 修改，二者共同构成一道资源“安全阀”——设得太低会引发“Too many open files”“Cannot allocate memory”等错误；设得过高又可能掩盖内存泄漏或导致系统资源耗尽。
文件描述符限制（nofile）最常影响服务稳定性
Web 服务器、数据库、消息队列等高并发进程依赖大量文件描述符（socket、日志、配置文件等均计入）。默认 soft nofile 通常为 1024，远低于生产需求：
- nginx 启动失败或拒绝新连接，常见于 error log 中出现
accept() failed (24: Too many open files) - Java 应用抛出
java.io.IOException: Too many open files，尤其在使用大量 NIO channel 或连接池时 - MySQL 报错
Can't create thread (Errno: 11)或连接数卡在几百，实际受 ulimit -n 限制而非 max_connections 配置
建议：生产环境将 soft nofile 设为 65536，hard nofile 设为 65536 或更高（如 1048576），并通过 /etc/security/limits.conf 或 systemd 的 LimitNOFILE= 持久化生效。
栈大小（stack）不当易引发段错误或静默崩溃
每个线程默认分配 8MB 栈空间（x86_64），soft stack 限制过小会导致深度递归、大局部数组或嵌套调用失败：
- C/C++ 程序触发
Segmentation fault (core dumped)，gdb 显示栈溢出（stack overflow） - Go 程序在 goroutine 创建初期 panic，报
runtime: goroutine stack exceeds 1000000000-byte limit（实际受 ulimit -s 间接影响） - Java 应用启用 -XX:+UseG1GC 后，若线程栈过大且总线程数多，可能更快触达 RLIMIT_AS 或 RLIMIT_DATA 上限
建议：多数服务保持默认 8MB（即 ulimit -s 8192）即可；若确认无深度递归，可降至 2–4MB 节省内存；严禁设为 unlimited（-s unlimited），否则内核无法预估栈边界，反而增加风险。
地址空间与内存相关限制需结合应用模型权衡
ulimit -v（virtual memory）、-d（data segment）、-m（RSS，已废弃）等参数在容器化前较关键，如今更多由 cgroups 接管，但仍可能干扰调试：
- 设置
ulimit -v过低会使 malloc/mmap 分配失败，即使物理内存充足（因为虚拟地址空间被截断） - Java 应用若用 -Xmx 设定堆上限，再叠加较低的
ulimit -v，可能因元空间、直接内存、线程栈等额外开销导致 JVM 启动失败 - Python 多进程（multiprocessing）在 fork 时若父进程已占用大量虚拟内存，子进程可能因
ulimit -v不足而 fork 失败
建议：除非明确需要沙箱隔离，否则不主动限制 -v/-d；容器环境中优先使用 memory.limit_in_bytes 控制，ulimit 仅作兜底。
软硬限制差异决定运维响应方式
软限制是运行时生效值，硬限制是它的天花板。普通用户能临时提升 soft，但无法突破 hard：
-
ulimit -n 65536仅对当前 shell 及其子进程有效；退出即失效 -
ulimit -Hn查看当前 hard nofile，若显示 4096，则ulimit -n 65536会报错“Operation not permitted” - systemd 服务中，
LimitNOFILE=65536同时设置 soft 和 hard，且优先级高于 /etc/security/limits.conf
注意：修改 limits.conf 后，需重新登录或重启服务进程才生效；su 切换用户不继承原 shell 的 ulimit，需确保 PAM 的 pam_limits.so 已启用。
