购物商城网站建设流程中国军事新闻最新消息

• 问题：这份代码在 3.11.3 中它居然输出 0 ，一度以为自己写错了，抱着不信邪的态度，又搞了个 Python 3.9.7 的环境试了下，果然还是符合自己预期，输出不为 0，想问下 3.11 版本中是做了什么修改吗？

import threadingnum = 0def add():global numfor i in range(10_000_000):num += 1def sub():global numfor i in range(10_000_000):num -= 1if __name__ == "__main__":add_t = threading.Thread(target=add)sub_t = threading.Thread(target=sub)add_t.start()sub_t.start()add_t.join()sub_t.join()print("num result : %s" % num)

• 答案：

  1. 首先在 Python 字节码执行的时候 ，GIL 并不是随时能在任意位置中断切换线程。只有在主动检测中断的地方才可能发生线程切换。这个是大前提

  2. 3.10 之前的版本中，INPLACE_ADD 这个 opcode 之后 GIL 会去主动监测中断，所以导致现成不安全。3.10 的代码中有一个提交，https://github.com/python/cpython/commit/4958f5d69dd2bf86866c43491caf72f774ddec97
     根据 T. Wouters 的 Twitter 描述 https://twitter.com/Yhg1s/status/1460935209059328000
     这次提交修改了 INPLACE_ADD 之后主动监测中断的操作。使得 INPLACE_ADD 之后无论如何都不会发生线程切换，因此虽然是两个 opcode ，但是确实是线程安全。

  3. 因为字节码中+=的操作是两步 opcode 操作，且 INPLACE_ADD 之后 GIL 会主动监测中断，导致虽然加了，但是没有重新赋值，就切换到了别的线程上**。比如 A 线程 当前 num=100 。+=1 之后 101 但是买没来得及重新赋值给 num ，GIL 切换了线程，再 B 线程中 num 还是 100 ，-=之后就是 99 ，但是这个线程却赋值给了 num ，此时 num 就是 99 然后又且回了 A 线程**。结果线程将中断时候的 101 赋值给了 num 导致此时 num 变成了 101 就出现问题了

  4. 3.10 以后就不会出现这个问题了，因为 INPLACE_ADD 操作之后 GIL 不再会主动检测中断，意味着正常情况下执行完+=之后线程不会被切换，而是正确执行了赋值给 num 的操作