resource.setrlimit 对 python 进程本身“看似无效”是因为 rlimit_as 限制虚拟地址空间，而 cpython 的 pymalloc 预分配并复用内存池，已映射的地址空间不触发新 mmap/brk，故限制只约束后续系统调用；且该限制进程级生效、需在子进程中显式设置，linux 上真正可用的是 rlimit_as 或 rlimit_memlock，rlimit_data 和已废弃的 rlimit_rss 不可靠。
resource.setrlimit 为什么对 Python 进程本身无效？
直接调用 resource.setrlimit(resource.RLIMIT_AS, (limit, limit)) 后发现内存没被限制住，是因为 RLIMIT_AS 作用于进程的虚拟地址空间（包括 mmap、malloc 预留等），而 CPython 的内存分配器（如 pymalloc）会提前向系统申请大块内存池，并反复复用——这些内存始终在地址空间内，即使 Python 对象已销毁，RLIMIT_AS 也“看不见”实际使用量。更关键的是：该限制只对后续的 brk/mmap 系统调用生效，无法回溯约束已分配的内存。
真正可控的是 RLIMIT_DATA（数据段大小，不含堆栈和 mmap）或 RLIMIT_RSS（但 Linux 内核自 2.6.36 起已废弃该限制，设了也无效）。所以实际能稳定起效的只有 RLIMIT_AS 或 RLIMIT_MEMLOCK（配合 mlock），但后者仅限锁定内存页，不解决总用量问题。
- 优先用
RLIMIT_AS，设为略高于预期峰值（比如 512MB → 设 600MB），避免 malloc 失败导致MemoryError比预期内存超限更早发生 - 必须在子进程里设置，主进程设置后 fork 出的子进程会继承限制；若在主线程中设置，无法限制后续 spawn 的新解释器进程
- macOS 上
RLIMIT_AS行为与 Linux 不一致（部分版本映射为RLIMIT_RSS），务必在目标系统上实测
限制 CPU 时间：RLIMIT_CPU 是硬中断，不是超时控制
RLIMIT_CPU 触发时，内核会向进程发送 SIGXCPU 信号，默认行为是终止进程。它统计的是“用户态 + 内核态”的累计 CPU 时间（非 wall-clock 时间），因此 IO 等待、sleep、锁竞争阻塞都不会计入。这意味着：一个死循环占满 CPU 会在设定秒数后立刻被杀；而一个频繁 sleep 的爬虫可能跑几天也不触发。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 设
resource.setrlimit(resource.RLIMIT_CPU, (30, 30))表示最多用 30 秒 CPU 时间，超时后进程退出，不会抛 Python 异常 - 可注册
signal.signal(signal.SIGXCPU, handler)捕获信号做清理，但 handler 中不能调用大多数 Python C API（如print、list.append），推荐只写入文件或调用os._exit() - 注意：Jupyter / IDE 内嵌 Python 解释器通常无法可靠捕获
SIGXCPU，应在独立 shell 中运行脚本验证
如何让 resource 限制在多线程/多进程场景下生效？
resource 模块的限制作用于整个进程（process-wide），不是线程或协程粒度。如果你用 threading.Thread 启动多个线程，它们共享同一套资源限制；而用 multiprocessing.Process 启动子进程时，子进程默认不继承父进程的 rlimit——必须显式在子进程中调用 setrlimit。
- 对于
multiprocessing：在target函数开头立即调用resource.setrlimit，不要依赖父进程设置 - 对于
concurrent.futures.ProcessPoolExecutor：需通过initializer参数传入初始化函数，在其中设置限制 - asyncio 无影响：协程不创建新进程，所有限制仍适用于当前进程，但 CPU 时间统计包含 event loop 调度开销，可能比纯计算任务略高
替代方案：cgroups v2 或 ulimit 更适合生产环境
Python 的 resource 模块本质是对 setrlimit(2) 的封装，缺乏细粒度控制（比如无法区分内存 RSS 和 cache）、不支持子树继承、且无法限制子进程自动派生的子进程（如 subprocess.Popen 启动的 shell）。在容器或服务化部署中，应优先使用外部机制：
- Linux 上用 cgroups v2：通过
memory.max和cpu.max文件精确控 RSS 和 CPU 带宽，且自动递归约束所有子孙进程 - 启动前用
ulimit -v 524288 -t 30（单位 KB 和秒）再执行 Python 脚本，比代码内设置更可靠，尤其适合 cron 或 systemd 场景 - 若必须用 Python 控制，建议封装成独立 wrapper 进程：先 setrlimit，再
os.execv替换为真正的目标脚本，确保 100% 继承限制
真正难处理的是内存泄漏型脚本——RLIMIT_AS 只能防止 OOM kill，无法定位哪段代码在涨内存。这时候得配合 tracemalloc 或 psutil.Process().memory_info().rss 主动采样，而不是依赖内核限制。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
