GIL & vì sao CPython nhanh dần

Đây là khái niệm gây hiểu lầm nhất ở Python. GIL (Global Interpreter Lock) khiến CPython chỉ cho MỘT luồng chạy bytecode tại một thời điểm - dù máy có nhiều lõi. Hệ quả khác hẳn nhau giữa CPU-bound và I/O-bound; chỉnh widget để thấy:

Và đây là benchmark THẬT tạo ra những con số đó - hai luồng so với chạy tuần tự:

import time, threading

def cpu(n):                       # CPU-bound: tinh toan thuan
    s = 0
    for i in range(n): s += i * i
    return s

def io():                         # I/O-bound: cho doi
    time.sleep(0.3)

def do_2_threads(fn, *a):
    ts = [threading.Thread(target=fn, args=a) for _ in range(2)]
    t = time.perf_counter()
    [x.start() for x in ts]; [x.join() for x in ts]
    return time.perf_counter() - t

# (đo trên một máy; con số tuyệt đối tuỳ máy, nhưng TỈ LỆ thì ổn định)
print("CPU 2 luong:", round(do_2_threads(cpu, 8_000_000), 3), "s  -> ~1.0x (KHONG nhanh hon)")
print("I/O 2 luong:", round(do_2_threads(io), 3), "s  -> ~2x nhanh hon tuan tu")

CPU 2 luong: 0.64 s  -> ~1.0x (KHONG nhanh hon)
I/O 2 luong: 0.31 s  -> ~2x nhanh hon tuan tu

• ▸GIL = khoá toàn cục: mỗi lúc chỉ 1 luồng chạy bytecode Python.
• ▸CPU-bound: 2 luồng ≈ 1 luồng (đo ≈1,03×) - tranh nhau GIL, không có lời.
• ▸I/O-bound: 2 luồng ≈ nhanh gấp đôi (đo ≈1,96×) - vì GIL được nhả khi chờ.

Nếu một luồng giữ GIL mãi thì luồng khác "chết đói" (starvation). CPython tránh điều đó bằng switch interval: cứ khoảng 5ms, luồng đang giữ GIL phải nhường lượt. Quan trọng hơn: khi chờ I/O thì nhả GIL ngay.

import sys
print(sys.getswitchinterval())     # 0.005  (5 mili-giay)
# sys.setswitchinterval(0.001)     # chuyen luong thuong xuyen hon (hiem khi can)

0.005

• ▸GIL nhả ở 3 lúc: hết ~5ms (switch interval), khi CHỜ I/O, và trong nhiều hàm C nặng.
• ▸Vì vậy I/O-bound (mạng/đĩa) và "việc C" (NumPy, nén, băm) vẫn hưởng lợi từ đa luồng.
• ▸switch interval chỉ đổi TẦN SUẤT nhường lượt - KHÔNG cho CPU-bound chạy song song.

GIL tồn tại chủ yếu vì cách CPython quản lý bộ nhớ: đếm tham chiếu. Mỗi object giữ một con số "đang có bao nhiêu nơi trỏ tới"; về 0 thì được giải phóng.

import sys
a = []
print(sys.getrefcount(a))   # gom ca tham chieu TAM khi truyen vao getrefcount
b = a                       # them mot tham chieu
print(sys.getrefcount(a))   # tang them 1

2
3

• ▸Mỗi object có bộ đếm tham chiếu: tăng khi có nơi trỏ tới, giảm khi thôi; về 0 → giải phóng.
• ▸Hai luồng cùng tăng/giảm bộ đếm KHÔNG khoá → sai → giải phóng nhầm (use-after-free, sập) hoặc rò rỉ.
• ▸GIL khoá toàn bộ → tăng/giảm refcount luôn an toàn, RẺ, và đơn luồng nhanh. Đánh đổi: không song song bytecode.

Từ Python 3.11 (PEP 659), máy ảo tự chuyên biệt hoá lệnh "nóng" lúc chạy. Hãy SOI tận mắt: cùng một hàm, sau khi chạy nhiều lần, bytecode đổi:

import dis

def add(a, b):
    return a + b

for _ in range(200):           # "ham nong" -> may ao chuyen biet hoa
    add(1, 2)

dis.dis(add, adaptive=True)    # xem bytecode da chuyen biet

  LOAD_FAST_BORROW_LOAD_FAST_BORROW (a, b)
  BINARY_OP_ADD_INT                  <-- chuyen biet: cong INT, bo kiem tra kieu
  RETURN_VALUE

• ▸Máy ảo quan sát lệnh chạy nhiều lần rồi thay bằng phiên bản CHUYÊN BIỆT.
• ▸BINARY_OP (tổng quát) → BINARY_OP_ADD_INT khi thấy luôn cộng int → bỏ kiểm tra kiểu → nhanh hơn.
• ▸Tự động, không cần sửa code - lý do lớn khiến CPython 3.11+ nhanh hơn hẳn 3.10.

• ▸Từ 3.13 (PEP 744): JIT THỬ NGHIỆM kiểu "copy-and-patch" - ghép sẵn mảnh mã máy cho bytecode nóng.
• ▸Tới 3.14 VẪN thử nghiệm; bản binary Windows/macOS đã kèm để bật thử (build có hỗ trợ JIT).
• ▸Khác adaptive interpreter (luôn bật): JIT dịch hẳn ra mã máy - tiềm năng lớn nhưng còn non.