Python os.system()调用脚本的资源分配与GIL机制问题

先明确问题对应的两个示例脚本基础结构：

Script A（CSV逐行处理脚本）:

import sys
with open(sys.argv[1], 'r') as f:
    # 逐行执行独立处理逻辑

Script B（调用脚本）:

import os
os.system('python Script_A.py somefile.csv')

os.system() 调用场景下的资源共享规则 #

os.system()的实现非常直接：它调用C标准库的system函数，让当前运行Script B的Python进程挂起，启动系统shell执行传入的命令，等shell拉起的Script A进程完全退出后，Script B才会恢复执行。

• 两个脚本对应两个完全独立的操作系统进程：各自拥有独立的虚拟内存地址空间、独立的Python解释器实例、独立的调用栈与堆内存、独立的GIL、独立的文件描述符表。除了默认继承的stdin/stdout/stderr三个标准流，Script B中定义的变量、加载的模块、打开的文件句柄，Script A完全无法访问，反之亦然。
• CPU、内存等计算资源的分配完全由操作系统调度器决定，两个进程不存在Python层面的主动资源共享。所谓的公共资源占用只有操作系统全局层面的：比如磁盘IO带宽、系统页缓存、CPU三级缓存这类所有进程都可访问的资源，并非两个脚本特意做的共享。
• os.system()阻塞期间，Script B进程基本处于休眠等待状态，几乎不占用CPU资源，算力主要分配给执行处理逻辑的Script A进程。

subprocess 调用场景的资源分配变化 #

核心的资源隔离与分配机制没有任何变化，差异只存在于调用层的控制能力，不触及进程本质：

• subprocess默认不经过shell中转（除非显式指定shell=True），直接由Script B进程fork出子进程执行Script A，少了一层shell进程的额外开销，但两个进程依然是完全独立的Python解释器实例，内存隔离、GIL独立的特性和os.system()场景完全一致。
• 和os.system()的区别仅在于可控性：你可以选择让Script B不等待子进程结束继续执行、可以读写子进程的标准输入输出、可以向子进程发送信号、自定义子进程的环境变量/工作目录/资源限额，但这些都是操作系统提供的通用进程管控能力，不会改变两个独立Python实例的隔离本质。两个进程之间依然不能直接访问对方的内存数据，跨进程传值必须走管道、文件、共享内存等操作系统提供的IPC机制。

引入multiprocessing多进程的影响 #

不管是在os.system还是subprocess场景下使用multiprocessing，核心逻辑不会变：Python的multiprocessing本质是封装了操作系统的进程创建API，无论使用fork还是spawn启动模式，拉起的都是实打实的独立操作系统进程，和手动敲命令启动Python脚本的进程模型没有区别，每个进程都有独立的内存空间、独立的GIL。

• 如果在Script B中用multiprocessing启动多个处理CSV行的进程：这些子进程和手动启动的Script A实例完全等价，操作系统会将它们调度到不同CPU核心上并行执行，刚好适配CSV行之间无依赖的处理场景。需要注意启动模式的差异：fork模式下子进程会通过写时复制（COW）机制拿到父进程（Script B）在fork瞬间的内存快照，只要子进程不修改这部分内存，就不会产生额外的物理内存占用；spawn模式下子进程会从头启动全新的Python解释器，重新导入所有依赖，完全不继承父进程的运行时状态，和手动敲命令启动Script A的行为完全一致。
• 如果在Script A内部用multiprocessing做行级并行处理：这些多进程全是Script A进程的子进程，Script B完全感知不到它们的存在，只会观测到Script A进程占用了更多CPU和内存资源，底层的资源隔离规则没有任何变化。

独立Python实例间的GIL作用逻辑 #

GIL的作用边界非常清晰：它是单个Python解释器进程内部的全局互斥锁，从来不会跨进程生效。

• 每个独立的Python进程——无论通过os.system启动、subprocess拉起、还是multiprocessing创建——都持有自己独立的GIL。每个GIL只约束所属进程内的Python字节码执行：同一时间单个进程内只允许一个线程执行Python字节码，这个限制仅在进程内部生效。
• 多个独立Python进程运行在不同CPU核心上时，各自的GIL完全互不干扰，操作系统可以调度它们真正并行执行，不会出现一个进程的GIL阻塞另一个进程的情况。
• 只有在同一个Python进程内部开多线程跑CPU密集型逻辑时，GIL才会导致无法利用多核算力；只要使用多进程模型，无论进程通过哪种方式启动，GIL都不会成为跨核并行的阻碍。

内容的提问来源于stack exchange，提问作者waslow