Global Interpreter Lock — GIL trong CPython

Năm 2019, một đội ngũ backend tại một công ty fintech Việt Nam triển khai hệ thống xử lý giao dịch bằng Python. Họ dùng threading để tăng tốc, kỳ vọng 4 cores sẽ cho throughput gấp 4. Kết quả: hiệu năng không đổi, thậm chí chậm hơn 10% do context switching. Nguyên nhân nằm ở ba chữ cái mà mọi Python engineer phải hiểu — GIL.

GIL (Global Interpreter Lock) là cơ chế đặc thù của CPython khiến tại bất kỳ thời điểm nào, chỉ một thread được thực thi Python bytecode — dù máy có 16 cores. Đây không phải bug, mà là quyết định thiết kế có chủ đích từ năm 1991, bảo vệ reference counting khỏi race condition. Hiểu đúng GIL giúp bạn chọn đúng công cụ: threading cho I/O-bound, multiprocessing cho CPU-bound, và biết khi nào GIL thực sự là bottleneck.

Python 3.13 đánh dấu bước ngoặt lịch sử với free-threaded build (PEP 703) — lần đầu tiên GIL có thể bị vô hiệu hóa. Bài này phân tích GIL từ cơ chế hoạt động đến chiến lược vượt qua giới hạn của nó trong production.

Bức tranh tư duy

Hãy tưởng tượng một quán phở đông khách ở Sài Gòn. Quán có 4 bàn bếp (4 CPU cores) nhưng chỉ có một chiếc muôi duy nhất (GIL). Dù có 4 đầu bếp (4 threads), mỗi lần chỉ một đầu bếp được cầm muôi để nấu. Đầu bếp nào muốn nấu phải chờ đầu bếp đang giữ muôi trả lại.

Khi đầu bếp cần chờ nước sôi (I/O wait), anh ta đặt muôi xuống — đầu bếp khác lập tức cầm lên và nấu tiếp. Đây là lý do threading vẫn hiệu quả cho I/O-bound: GIL được release trong lúc chờ I/O.

Nhưng nếu cả 4 đầu bếp đều cần xào liên tục không nghỉ (CPU-bound), chiếc muôi duy nhất trở thành nút thắt cổ chai. Giải pháp? Mở thêm quán (multiprocessing — mỗi process có muôi riêng), hoặc chờ quán nâng cấp thành 4 muôi (free-threaded Python 3.13+).

Khi nào analogy không còn chính xác: GIL thực tế phức tạp hơn — nó release theo thời gian (mỗi 5ms trong Python 3.2+) chứ không chỉ khi I/O. Và C extensions có thể chủ động release GIL để cho phép true parallelism trong native code.

Cốt lõi kỹ thuật

GIL là gì?

GIL là một mutex (mutual exclusion lock) cấp interpreter trong CPython. Nó đảm bảo tại mọi thời điểm, chỉ có một thread giữ quyền thực thi Python bytecode. Các thread khác phải chờ cho đến khi thread hiện tại release GIL.

python

import sys
import threading

# Kiểm tra GIL có đang hoạt động không (Python 3.13+)
if hasattr(sys, "_is_gil_enabled"):
    print(f"GIL enabled: {sys._is_gil_enabled()}")
else:
    print("GIL luôn active trong CPython < 3.13")

# Xem switch interval — khoảng thời gian trước khi GIL được chuyển
print(f"GIL switch interval: {sys.getswitchinterval()}s")  # Mặc định 0.005s

# Có thể điều chỉnh switch interval
sys.setswitchinterval(0.01)  # 10ms — cẩn thận trong production

Tại sao CPython cần GIL?

Reference counting: CPython quản lý bộ nhớ bằng đếm tham chiếu. Mỗi object có ob_refcnt — khi refcount về 0, object bị giải phóng. Không có GIL, hai threads đồng thời tăng/giảm refcount sẽ gây race condition, dẫn đến memory leak hoặc use-after-free.

python

import sys

a = []
print(sys.getrefcount(a))  # 2 (biến a + tham số hàm getrefcount)

b = a  # refcount tăng lên 3
del b  # refcount giảm về 2

# Không có GIL, hai threads cùng thay đổi refcount:
# Thread 1: đọc refcount = 2, tính 2+1 = 3
# Thread 2: đọc refcount = 2, tính 2-1 = 1
# Thread 1: ghi refcount = 3
# Thread 2: ghi refcount = 1 → SAI! Object bị giải phóng sớm

C extension compatibility: Hàng nghìn C extensions (NumPy, Pandas, lxml) được viết với giả định single-threaded access. GIL cho phép tích hợp C code mà không cần lo thread-safety.

Simplicity: Thiết kế interpreter đơn giản hơn đáng kể, giảm bug và tăng throughput cho single-threaded workload — vốn chiếm đa số use case.

GIL và Threading: CPU-bound vs I/O-bound

python

import time
import threading

def cpu_bound_work():
    """Tác vụ CPU-bound: GIL giữ chặt."""
    total = 0
    for i in range(30_000_000):
        total += i
    return total

# Sequential
start = time.perf_counter()
cpu_bound_work()
cpu_bound_work()
sequential_time = time.perf_counter() - start

# Threaded
start = time.perf_counter()
t1 = threading.Thread(target=cpu_bound_work)
t2 = threading.Thread(target=cpu_bound_work)
t1.start(); t2.start()
t1.join(); t2.join()
threaded_time = time.perf_counter() - start

print(f"Sequential : {sequential_time:.2f}s")
print(f"Threaded   : {threaded_time:.2f}s")
# Kết quả điển hình:
# Sequential : 3.40s
# Threaded   : 3.65s  ← Chậm hơn do context switching!

python

import time
import threading
from urllib.request import urlopen

URLS = [
    "https://www.python.org",
    "https://docs.python.org",
    "https://pypi.org",
    "https://peps.python.org",
    "https://wiki.python.org",
]

def fetch_url(url: str) -> int:
    """Tác vụ I/O-bound: GIL release khi chờ network."""
    with urlopen(url, timeout=10) as response:
        return len(response.read())

# Sequential
start = time.perf_counter()
for url in URLS:
    fetch_url(url)
sequential_time = time.perf_counter() - start

# Threaded
start = time.perf_counter()
threads = [threading.Thread(target=fetch_url, args=(url,)) for url in URLS]
for t in threads: t.start()
for t in threads: t.join()
threaded_time = time.perf_counter() - start

print(f"Sequential : {sequential_time:.2f}s")
print(f"Threaded   : {threaded_time:.2f}s")
# Kết quả điển hình:
# Sequential : 2.80s
# Threaded   : 0.65s  ← 4x nhanh hơn!

C Extensions Release GIL

C extensions có thể chủ động release GIL bằng macro Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS. Đây là lý do NumPy, hashlib, zlib đạt true parallelism ngay cả với threading.

python

import hashlib
import threading
import time

def hash_work():
    """hashlib release GIL trong quá trình tính hash."""
    for _ in range(200):
        hashlib.sha256(b"x" * 1_000_000).hexdigest()

# hashlib release GIL → threading thực sự parallel
start = time.perf_counter()
threads = [threading.Thread(target=hash_work) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()
threaded_time = time.perf_counter() - start

start = time.perf_counter()
for _ in range(4):
    hash_work()
sequential_time = time.perf_counter() - start

print(f"Sequential : {sequential_time:.2f}s")
print(f"Threaded   : {threaded_time:.2f}s")
# Threaded nhanh hơn ~3-4x trên 4 cores vì hashlib release GIL

Free-threaded Python 3.13+ (PEP 703)

Python 3.13 giới thiệu experimental build không có GIL — bước ngoặt trong lịch sử CPython.

python

import sys

# Kiểm tra free-threaded build
if hasattr(sys, "_is_gil_enabled"):
    if not sys._is_gil_enabled():
        print("Free-threaded Python — GIL đã bị vô hiệu hóa!")
    else:
        print("GIL vẫn active (tắt bằng PYTHON_GIL=0)")
else:
    print(f"Python {sys.version} — GIL luôn active")

python

import threading
import time

def cpu_work():
    total = 0
    for i in range(30_000_000):
        total += i
    return total

# Với free-threaded Python 3.13t:
start = time.perf_counter()
t1 = threading.Thread(target=cpu_work)
t2 = threading.Thread(target=cpu_work)
t1.start(); t2.start()
t1.join(); t2.join()
print(f"Threaded: {time.perf_counter() - start:.2f}s")
# Free-threaded build: ~1.8s (gần 2x speedup thật sự!)
# Regular CPython:     ~3.6s (không speedup)

Lưu ý quan trọng về free-threaded build:

Single-threaded code chậm hơn 5-10% do fine-grained locking thay thế GIL
Nhiều C extensions chưa tương thích (NumPy, Pandas đang cập nhật)
Trạng thái: experimental trong 3.13, stabilizing trong 3.14+

Thực chiến

Tình huống: API Gateway xử lý hỗn hợp CPU và I/O

Bối cảnh: Hệ thống API gateway nhận request, validate JWT token (CPU-bound), sau đó forward tới microservices (I/O-bound). Traffic: 500 req/s, latency target p99 < 200ms.

Mục tiêu: Tối ưu throughput bằng cách chọn đúng concurrency model cho từng giai đoạn.

python

import time
import hmac
import hashlib
import asyncio
from concurrent.futures import ProcessPoolExecutor

def validate_jwt_signature(token: str, secret: str) -> bool:
    """CPU-bound — GIL giữ chặt với pure Python."""
    header, payload, signature = token.split(".")
    expected = hmac.new(
        secret.encode(), f"{header}.{payload}".encode(), hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(signature, expected)

async def forward_to_service(service_url: str, payload: dict) -> dict:
    """I/O-bound — GIL release khi chờ network."""
    await asyncio.sleep(0.05)  # Giả lập network latency
    return {"status": "ok", "service": service_url}

async def handle_request(
    token: str,
    service_url: str,
    payload: dict,
    process_pool: ProcessPoolExecutor,
) -> dict:
    loop = asyncio.get_running_loop()

    # CPU-bound → process pool (bypass GIL hoàn toàn)
    is_valid = await loop.run_in_executor(
        process_pool, validate_jwt_signature, token, "secret-key"
    )
    if not is_valid:
        return {"error": "Invalid token"}

    # I/O-bound → asyncio (GIL không ảnh hưởng)
    return await forward_to_service(service_url, payload)

async def main():
    process_pool = ProcessPoolExecutor(max_workers=4)
    mock_token = "header.payload.signature"

    start = time.perf_counter()
    tasks = [
        handle_request(mock_token, f"http://svc-{i}", {}, process_pool)
        for i in range(100)
    ]
    results = await asyncio.gather(*tasks)
    elapsed = time.perf_counter() - start

    print(f"100 requests trong {elapsed:.2f}s")
    print(f"Throughput: {100 / elapsed:.0f} req/s")
    process_pool.shutdown(wait=False)

if __name__ == "__main__":
    asyncio.run(main())

Phân tích:

JWT validation (CPU-bound) → ProcessPoolExecutor bypass GIL
Network forwarding (I/O-bound) → asyncio vì GIL release khi chờ I/O
run_in_executor bridge giữa sync CPU code và async I/O code
Trade-off: IPC overhead từ ProcessPool, nhưng đáng đổi khi validation nặng

Sai lầm điển hình

❌ Sai lầm 1: Dùng threading cho CPU-bound

Vấn đề: Kỳ vọng threading tăng tốc tính toán thuần Python.

python

# SAI: Threading cho CPU-bound — không nhanh hơn
import threading

def tinh_toan(n):
    return sum(i * i for i in range(n))

threads = [threading.Thread(target=tinh_toan, args=(10_000_000,)) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()
# Thời gian ≈ chạy tuần tự + overhead context switching

Tại sao sai: GIL chỉ cho phép một thread chạy Python bytecode tại một thời điểm. 4 threads tranh giành GIL liên tục, tạo overhead context switching mà không có speedup.

python

# ĐÚNG: ProcessPoolExecutor cho CPU-bound
from concurrent.futures import ProcessPoolExecutor

def tinh_toan(n):
    return sum(i * i for i in range(n))

if __name__ == "__main__":
    with ProcessPoolExecutor(max_workers=4) as pool:
        results = list(pool.map(tinh_toan, [10_000_000] * 4))

❌ Sai lầm 2: Tin rằng GIL bảo vệ khỏi mọi race condition

Vấn đề: Nghĩ rằng GIL tự động đảm bảo thread-safety cho mọi operation.

python

# SAI: counter += 1 KHÔNG phải atomic operation
import threading

counter = 0

def increment():
    global counter
    for _ in range(1_000_000):
        counter += 1  # LOAD → ADD → STORE — GIL có thể switch giữa các bước

threads = [threading.Thread(target=increment) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()
print(f"Kỳ vọng: 4,000,000 — Thực tế: {counter}")  # Thường < 4,000,000

Tại sao sai: counter += 1 biên dịch thành nhiều bytecode instructions. GIL có thể release giữa chúng. Trong production, lỗi này gây balance âm, inventory sai, data corruption.

python

# ĐÚNG: Lock cho shared mutable state
import threading

counter = 0
lock = threading.Lock()

def safe_increment():
    global counter
    for _ in range(1_000_000):
        with lock:
            counter += 1

threads = [threading.Thread(target=safe_increment) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()
print(f"Kết quả: {counter}")  # Luôn = 4,000,000

❌ Sai lầm 3: Thread leak — tạo thread không giới hạn

Vấn đề: Mỗi request tạo thread mới, không giới hạn.

python

# SAI: Thread leak — không giới hạn, không join
import threading

def handle_request(data):
    t = threading.Thread(target=process, args=(data,))
    t.start()  # Không join, không giới hạn → hàng nghìn threads

Tại sao sai: Mỗi thread tiêu ~8MB stack. 1000 threads = 8GB RAM. OS giới hạn ~4000 threads trên Linux mặc định.

python

# ĐÚNG: ThreadPoolExecutor với số worker cố định
from concurrent.futures import ThreadPoolExecutor

executor = ThreadPoolExecutor(max_workers=20)

def handle_request(data):
    future = executor.submit(process, data)
    return future.result(timeout=30)

❌ Sai lầm 4: Deadlock do lock ordering

Vấn đề: Hai threads acquire locks theo thứ tự ngược nhau.

python

# SAI: Deadlock
import threading
lock_a, lock_b = threading.Lock(), threading.Lock()

def thread_1():
    with lock_a:
        with lock_b:
            print("Thread 1")

def thread_2():
    with lock_b:       # Ngược thứ tự
        with lock_a:   # → DEADLOCK
            print("Thread 2")

python

# ĐÚNG: Lock ordering nhất quán
def thread_1():
    with lock_a:
        with lock_b:
            print("Thread 1")

def thread_2():
    with lock_a:  # Cùng thứ tự: a trước, b sau
        with lock_b:
            print("Thread 2")

Under the Hood

Cơ chế GIL trong CPython

GIL sử dụng condition variable và mutex cấp OS. Kể từ Python 3.2 ("New GIL" — Antoine Pitrou):

Thread đang giữ GIL chạy Python bytecode
Sau mỗi 5ms (sys.getswitchinterval()), kiểm tra thread khác đang chờ
Nếu có → release GIL, gửi signal
Thread chờ nhận signal → acquire GIL → bắt đầu chạy
Thread vừa release phải chờ lượt tiếp

Khía cạnh	Old GIL (< 3.2)	New GIL (≥ 3.2)
Switch trigger	Mỗi 100 bytecode ops	Mỗi 5ms (time-based)
Fairness	Kém — priority starvation	Tốt hơn — timeout-based
I/O release	Có	Có
Multi-thread overhead	Cao	Thấp hơn

Khi nào C Extensions Release GIL

python

# Các thư viện release GIL khi tính toán:
# - NumPy: hầu hết array operations (BLAS, LAPACK)
# - hashlib: hash computation (OpenSSL backend)
# - zlib/bz2: compression/decompression
# - re: regex matching trên string lớn
# - socket: tất cả network I/O
# - file I/O: đọc/ghi file system calls

import numpy as np
import threading
import time

def numpy_work():
    """NumPy release GIL → true parallelism."""
    a = np.random.rand(2000, 2000)
    return np.linalg.svd(a)

start = time.perf_counter()
threads = [threading.Thread(target=numpy_work) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()
print(f"Threaded NumPy SVD: {time.perf_counter() - start:.2f}s")
# Gần linear speedup nhờ BLAS release GIL

So sánh approach vượt GIL

Approach	Overhead khởi tạo	Shared Memory	True Parallel	Phù hợp
Threading + I/O	Thấp	Có (trực tiếp)	Không (GIL)	I/O-bound
Threading + C ext	Thấp	Có (trực tiếp)	Có	NumPy, hashlib
multiprocessing	Cao (fork/spawn)	Qua IPC/SharedMemory	Có	CPU-bound thuần Python
ProcessPoolExecutor	Trung bình	Qua pickle	Có	CPU-bound đơn giản
Free-threaded 3.13+	Thấp	Có (trực tiếp)	Có	Tương lai (experimental)
Sub-interpreters 3.12+	Trung bình	Hạn chế	Có (per-interp GIL)	Isolated workloads

Trade-offs

GIL nên giữ khi: Codebase chủ yếu single-threaded, dùng nhiều C extensions chưa thread-safe, ưu tiên simplicity. Single-threaded performance với GIL tốt hơn 5-10% so với free-threaded build.

GIL cản trở khi: Cần CPU parallelism thuần Python, hệ thống yêu cầu low-latency multi-threaded processing, muốn tận dụng toàn bộ cores mà không chịu IPC overhead.

Checklist ghi nhớ

✅ Checklist triển khai

Hiểu GIL

[ ] Xác định workload là CPU-bound hay I/O-bound trước khi chọn concurrency model
[ ] Kiểm tra C extensions có release GIL không (NumPy, hashlib — có; pure Python — không)
[ ] Đo benchmark thực tế thay vì giả định threading sẽ nhanh hơn

Thread Safety

[ ] Dùng threading.Lock cho mọi shared mutable state
[ ] Acquire locks theo thứ tự cố định để tránh deadlock
[ ] Dùng ThreadPoolExecutor thay vì tạo thread thủ công
[ ] Set timeout cho lock acquisition trong production

Chọn đúng công cụ

[ ] I/O-bound (ít tasks) → threading hoặc ThreadPoolExecutor
[ ] I/O-bound (nhiều tasks) → asyncio
[ ] CPU-bound → multiprocessing hoặc ProcessPoolExecutor
[ ] CPU + I/O hỗn hợp → asyncio + run_in_executor với ProcessPool

Python 3.13+

[ ] Kiểm tra sys._is_gil_enabled() trước khi dựa vào free-threaded behavior
[ ] Xác minh C extensions tương thích với free-threaded build
[ ] Benchmark single-threaded performance — free-threaded chậm hơn 5-10%

Bài tập luyện tập

Bài 1: Phân loại workload — Intermediate

Đề bài: Cho các hàm sau, xác định nên dùng threading, multiprocessing, hay asyncio. Viết benchmark so sánh thời gian chạy sequential vs threaded vs multiprocessing.

python

import time
import hashlib

def task_a():
    """Tính tổng bình phương 10 triệu số."""
    return sum(i * i for i in range(10_000_000))

def task_b():
    """Hash 1000 chuỗi lớn."""
    for _ in range(1000):
        hashlib.sha256(b"data" * 10000).hexdigest()

def task_c():
    """Đọc file từ disk (giả lập bằng sleep)."""
    time.sleep(0.5)

🧠 Quiz

Câu hỏi: Hàm task_b() dùng hashlib.sha256. Khi chạy 4 threads đồng thời, điều gì xảy ra?

[ ] A. Không speedup vì GIL block tất cả
[x] B. Gần 4x speedup vì hashlib release GIL khi tính hash
[ ] C. Crash vì hashlib không thread-safe
[ ] D. 2x speedup vì GIL release một nửa thời gian Giải thích: hashlib implement bằng C và chủ động release GIL (Py_BEGIN_ALLOW_THREADS) khi tính hash. 4 threads chạy song song thật sự trên 4 cores, đạt gần linear speedup. Đáp án A sai vì hashlib là C extension có release GIL. C sai vì hashlib hoàn toàn thread-safe. D sai vì GIL release toàn bộ thời gian tính hash, không chỉ một nửa.

💡 Gợi ý

task_a là pure Python computation → GIL giữ chặt
task_b dùng C extension release GIL → threading hiệu quả
task_c là I/O-bound → threading hoặc asyncio

✅ Lời giải

python

import time
import hashlib
from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor

def task_a():
    return sum(i * i for i in range(10_000_000))

def task_b():
    for _ in range(1000):
        hashlib.sha256(b"data" * 10000).hexdigest()

def task_c():
    time.sleep(0.5)

def benchmark(func, label, workers=4):
    start = time.perf_counter()
    for _ in range(workers):
        func()
    seq = time.perf_counter() - start

    start = time.perf_counter()
    with ThreadPoolExecutor(max_workers=workers) as pool:
        list(pool.map(lambda _: func(), range(workers)))
    thr = time.perf_counter() - start

    print(f"{label}: Sequential={seq:.2f}s, Threaded={thr:.2f}s, "
          f"Speedup={seq/thr:.1f}x")

if __name__ == "__main__":
    benchmark(task_a, "CPU-pure")    # Speedup ≈ 1.0x
    benchmark(task_b, "CPU-C-ext")   # Speedup ≈ 3-4x
    benchmark(task_c, "I/O-bound")   # Speedup ≈ 4x

Phân tích: task_a → dùng multiprocessing; task_b → threading đủ tốt; task_c → threading hoặc asyncio.

Bài 2: Thread-safe Counter — Intermediate

Đề bài: Implement class ThreadSafeCounter với increment(), decrement(), get(). Test với 10 threads, mỗi thread gọi increment() 100,000 lần. Kết quả cuối phải luôn đúng.

💡 Gợi ý

Dùng threading.Lock bảo vệ mọi operation trên counter
Test bằng cách so sánh kết quả với giá trị kỳ vọng

✅ Lời giải

python

import threading

class ThreadSafeCounter:
    def __init__(self, initial: int = 0):
        self._value = initial
        self._lock = threading.Lock()

    def increment(self) -> int:
        with self._lock:
            self._value += 1
            return self._value

    def decrement(self) -> int:
        with self._lock:
            self._value -= 1
            return self._value

    def get(self) -> int:
        with self._lock:
            return self._value

counter = ThreadSafeCounter()
threads = []
for _ in range(10):
    t = threading.Thread(
        target=lambda: [counter.increment() for _ in range(100_000)]
    )
    threads.append(t)
    t.start()

for t in threads:
    t.join()

assert counter.get() == 1_000_000, f"Sai: {counter.get()}"
print(f"Kết quả: {counter.get()}")  # Luôn = 1,000,000

Phân tích: Lock đảm bảo atomicity. Trade-off: throughput giảm do lock contention, nhưng correctness luôn ưu tiên hơn speed.

Liên kết học tiếp

Từ khóa glossary: GIL, Global Interpreter Lock, mutex, reference counting, free-threaded, PEP 703, context switching

Tìm kiếm liên quan: python gil là gì, tại sao python chậm, threading python không nhanh hơn, python multicore

Global Interpreter Lock — GIL trong CPython ​

Bức tranh tư duy ​

Cốt lõi kỹ thuật ​

GIL là gì? ​

Tại sao CPython cần GIL? ​

GIL và Threading: CPU-bound vs I/O-bound ​

C Extensions Release GIL ​

Free-threaded Python 3.13+ (PEP 703) ​

Thực chiến ​

Tình huống: API Gateway xử lý hỗn hợp CPU và I/O ​

Sai lầm điển hình ​

❌ Sai lầm 1: Dùng threading cho CPU-bound ​

❌ Sai lầm 2: Tin rằng GIL bảo vệ khỏi mọi race condition ​

❌ Sai lầm 3: Thread leak — tạo thread không giới hạn ​

❌ Sai lầm 4: Deadlock do lock ordering ​

Under the Hood ​

Cơ chế GIL trong CPython ​

Khi nào C Extensions Release GIL ​

So sánh approach vượt GIL ​

Trade-offs ​

Checklist ghi nhớ ​

Bài tập luyện tập ​

Bài 1: Phân loại workload — Intermediate ​

Bài 2: Thread-safe Counter — Intermediate ​

Liên kết học tiếp ​

Global Interpreter Lock — GIL trong CPython

Bức tranh tư duy

Cốt lõi kỹ thuật

GIL là gì?

Tại sao CPython cần GIL?

GIL và Threading: CPU-bound vs I/O-bound

C Extensions Release GIL

Free-threaded Python 3.13+ (PEP 703)

Thực chiến

Tình huống: API Gateway xử lý hỗn hợp CPU và I/O

Sai lầm điển hình

❌ Sai lầm 1: Dùng threading cho CPU-bound

❌ Sai lầm 2: Tin rằng GIL bảo vệ khỏi mọi race condition

❌ Sai lầm 3: Thread leak — tạo thread không giới hạn

❌ Sai lầm 4: Deadlock do lock ordering

Under the Hood

Cơ chế GIL trong CPython

Khi nào C Extensions Release GIL

So sánh approach vượt GIL

Trade-offs

Checklist ghi nhớ

Bài tập luyện tập

Bài 1: Phân loại workload — Intermediate

Bài 2: Thread-safe Counter — Intermediate

Liên kết học tiếp