为何Python解释器非线程安全？为何GIL锁定核心阻碍线程并行？

Hey there! Let's unpack your two questions about Python's thread safety and the GIL—they're super tied to how CPython (the standard Python interpreter) was built under the hood.

The short answer boils down to CPython's core design choices, especially around memory management. Let's break it down:

• Reference counting: CPython uses reference counting to track object lifecycles. Every time you assign an object to a variable, its reference count goes up; when you discard it, the count goes down. The problem? These increment/decrement operations aren't atomic—meaning a thread could get interrupted halfway through the operation. If two threads mess with the same object's reference count at the same time, you end up with a wrong count. That can lead to objects being freed too early (crashes) or never freed (memory leaks).
• Unprotected internal state: Beyond reference counts, the interpreter has tons of global data structures (like the module registry, thread state tracking) that aren't guarded by per-object locks. If multiple threads tried to modify these structures simultaneously without synchronization, you'd get corrupted data and unpredictable behavior.

Instead of building thread safety into every nook and cranny of the interpreter, the CPython team went with a simpler compromise: the Global Interpreter Lock (GIL).

Here's the context: The GIL is a single lock that ensures only one thread executes Python bytecode at a time—even on multi-core systems. But why was this chosen over true parallelism?

• Historical simplicity: Back when CPython was first developed, multi-core CPUs weren't common. Adding the GIL was a quick way to make the interpreter thread-safe without having to implement fine-grained locks for every single object. Fine-grained locks would have added massive overhead (think constant locking/unlocking) and made the codebase way more complex.
• Single-thread performance: For the majority of Python use cases (like scripting, web apps where I/O waits are common), single-thread performance matters a lot. The GIL avoids the overhead of multiple locks, so single-threaded code runs faster than it would with a more complex locking system.
• Legacy compatibility: Over decades, countless Python libraries and applications have been built assuming the GIL exists. Removing it would break a huge amount of existing code—especially C extensions that rely on the GIL to safely interact with Python objects.

Wait, but what about multi-core systems? Pure Python threads can't run in parallel, but they can still do concurrency (switch between threads when one is waiting on I/O, like a network call or file read). And for CPU-heavy tasks, you can use multiprocessing (each process has its own Python interpreter and GIL) or libraries like NumPy that release the GIL when executing C-level code.

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