在Linux环境中，每一个进程都会消耗CPU、内存、文件描述符等系统资源。如果不加约束，某个异常程序可能占满内存导致系统触发OOM Killer，或者耗尽文件句柄让其他服务无法建立连接。理解并运用系统提供的资源限制手段，是保障多任务稳定运行的基础。
一、使用ulimit进行用户级限制
ulimit是shell内置命令，用来设置和查看当前shell会话及其启动的子进程能够使用的资源上限。它分为软限制和硬限制：软限制是进程当前实际生效的阈值，硬限制是软限制可调的上限，普通用户只能调低硬限制，root可以升高。
例如，限制单个进程最多打开1024个文件描述符，可以使用如下命令：
# 查看当前所有资源限制 ulimit -a # 设置软限制为1024，硬限制为2048 ulimit -Sn 1024 ulimit -Hn 2048 # 限制用户最多创建进程数为512 ulimit -u 512
这些设置在当前会话有效，退出登录后失效。若需持久化，可写入/etc/security/limits.conf，例如配置appuser的nofile限制：
# /etc/security/limits.conf 内容示例 appuser soft nofile 4096 appuser hard nofile 8192 appuser soft nproc 1024 appuser hard nproc 2048
ulimit的优点是简单直观、无需额外服务，适合快速临时限制或用户级管控。缺点是作用范围仅到登录会话和子进程，难以对已经运行的独立守护进程做精细化分组控制，并且在容器里往往受宿主机设置制约。
二、利用cgroup实现分组持久化限制
cgroup（control group）是Linux内核提供的资源隔离框架，可以把多个进程归入同一个组，对该组统一施加CPU、内存、IO等限制。它支持层级结构，规则在系统重启后通过配置文件或systemd持久保留。
以cgroup v1限制内存为例，先创建组并写入上限，再把进程号加入组：
# 创建内存控制组 mkdir -p /sys/fs/cgroup/memory/myapp # 限制该组最多使用100MB内存 echo 104857600 > /sys/fs/cgroup/memory/myapp/memory.limit_in_bytes # 将当前shell进程加入组（其子进程也会受限） echo $$ > /sys/fs/cgroup/memory/myapp/tasks
如果使用systemd管理的系统，可直接写单元文件，无需手动操作虚拟文件系统：
[Service] ExecStart=/usr/local/bin/myapp MemoryMax=100M CPUQuota=50% TasksMax=512
cgroup的优势在于粒度细、可跨会话、适合长期运行的服务以及容器底层。劣势是概念稍复杂，v1和v2接口不同，排查时需要熟悉对应文件系统布局。对于大多数现代发行版，推荐直接用systemd资源指令，降低运维成本。
三、通过systemd服务单元约束守护进程
当服务由systemd托管时，最方便的作法是在.service文件里声明资源参数。这样进程一启动就处于限制中，且随开机自动生效，不必依赖用户登录。
常见可用指令包括：MemoryMax限制最大内存，CPUQuota限制CPU时间百分比，LimitNOFILE限制文件描述符数。示例如下：
[Unit] Description=My Background Worker [Service] Type=simple ExecStart=/opt/worker/run.sh MemoryMax=200M CPUQuota=80% LimitNOFILE=65535 Restart=on-failure [Install] WantedBy=multi-user.target
这种方式的优点是和现代Linux启动体系天然集成，配置集中、易审计。缺点是不能像ulimit那样在交互终端里随时敲命令试验，修改后需执行systemctl daemon-reload并重起服务。
四、应对超限的实践策略
面对进程资源限制，第一步是明确限制目标：是防内存泄漏拖垮整机，还是防日志进程占满磁盘IO。不同目标对应不同工具组合。交互式排查可用ulimit，生产守护进程用systemd，多租户批量任务用cgroup。
建议配合监控脚本，当进程接近限制时主动告警或重启。下面一段shell可检测某pid内存是否超80MB：
PID=$1
MAX=83886080
USED=$(awk '/VmRSS/{print $2*1024}' /proc/$PID/status)
if [ "$USED" -gt "$MAX" ]; then
echo "进程 $PID 内存超限，当前 $USED 字节"
kill -TERM $PID
fi
综合运用上述方法，能够在无容器环境下也建立起清晰的资源边界。关键是根据运行场景选型，并把这些限制写进配置管理，避免临时敲命令后被人遗忘，才能在故障发生前把风险关进笼子。