关于多进程的问题中全局变量地址问题

[a476286557]

import multiprocessing
import os

g_task=["task"]

def task1():
g_task.append("task1")
print("--task1--进程 id=%d---g_task=%s----g_task 的 id=%d" % (os.getpid(), g_task, id(g_task)))

def task2():
g_task.append("task2")
print("--task2--进程 id=%d---g_task=%s----g_task 的 id=%d" % (os.getpid(), g_task, id(g_task)))


def main_task():
g_task.append("main_task")
print("--main_task--进程 id=%d---g_task=%s----g_task 的 id=%d" % (os.getpid(), g_task, id(g_task)))


if __name__ == '__main__':
p1 = multiprocessing.Process(target=task1)
p1.start()
p1.join()

p2 = multiprocessing.Process(target=task2)
p2.start()
p2.join()

main_task()





为什么在 linux 中 id(g_task)这个地址相同 而在 windows 中 id(g_task)地址却不同呢？

[mashiro233]

不同是正常的，相同是“碰巧”的。理解多进程和多线程的区别就应该懂了。

[BOYPT]

因为 linux 下的 multiprocessing 用的是 fork，fork 后的进程跟父进程完全一致，所以 id 号一样； windows 下的实现有所区别。

[wwqgtxx]

linux 下用 fork，所以并不改变原来的虚拟地址，而 win 下用的是重启一个新的 python.exe ，所以所有的变量都重新初始化了

[bantao]

如上，原因是 2 种系统对多进程的实现有区别。
另外，linux 上列表 g_task 的表现（全局变量地址一样）很容易让人感觉到进程间居然共享内存空间，打印结果表明并不是，实际只是复制了一份地址过去？联想到深拷贝（拷贝后列表 id 不同）、浅拷贝（拷贝后列表中子对象还是同一个，测试发现多进程中也不是）。好奇多进程这里的全局变量 list 是怎么实现的？
最后，官方不建议这么玩，进程间通信、共享数据的方法有很多介绍。

[mashiro233]

@bantao

首先，运行在用户空间的程序所拿到的内存地址，都不是真实的物理内存地址。我们它所在的地址空间叫做 user virtual address space，这些地址是通过内存管理单元（ MMU ）来对应真实的物理地址。所以当你的程序被系统加载执行后，所获得的指针地址全都是针对你自身的虚拟地址。A 和 B 两个程序的 0x1111 地址，可能指向同一个物理内存地址，也可能指向不同的物理内存地址。同理，A 的 0x1111 和 B 的 0x2222 也可能指向同一个物理内存地址（共享内存）。

所以，这里的 g_task 在 A 和 B 两个不同的 process 观测到指向同一地址，并不能说明什么。可以运行楼主的例子，在 process Ａ中对ｇ_task 进行的修改，并不能在 process B 中观测到。之所以他们内存地址相同，只是因为 Linux 使用 fork 实现让他们"碰巧"相同了而已。

[bantao]

@mashiro233 学习了！
补了下 fork 的内容，看看理解的对不对。fork 之后的ｇ_task 在子进程中“某一阶段”是共享的同一真实物理内存，virtual address 是一样的，对应的物理地址也是一样的，但是子进程会有自己独立的新内存空间。由于 Copy-on-Write 机制，只有在子进程发生对 g_task 的修改操作时，才会在子进程独立内存空间为 g_task 重新分配新空间，此时继承自父进程的 virtual address 仍然都不变，但物理地址都变了。

[mashiro233]

@bantao
是的，可以这么理解。