Phần 4 cho thấy tải cao giết hash table. Nhưng tôi đo tiếp: ngay ở CÙNG tải 0,70, đổi hàm băm tốt sang xấu làm probe trung bình nhảy từ 2,17 lên 358,9 — tra cứu chậm 23 lần. Băm hằng số thì thoái hóa hoàn toàn về O(n). Tải thấp là điều kiện cần, không đủ.
Tưởng mỗi push_back copy cả mảng nên vector chậm, hoặc grow-by-1 tiết kiệm RAM nên tốt? Tôi đo thử: nhân đôi amortize xuống 2,57ns/push (O(1)) xây 20 triệu phần tử, còn grow-by-1 là O(N²) — chỉ 50 nghìn phần tử đã 1,25 tỷ copy, 3213ns/push, nếu 20 triệu thì mất 7 giờ.
Tưởng kiểm null rồi khóa rồi kiểm lại là đủ, và DCL chỉ là mẹo tránh khóa? Tôi đo: fast-path đọc atomic không khóa nhanh 314 lần always-lock — nhưng DCL đúng bắt buộc có rào bộ nhớ (acquire/release), thiếu nó luồng khác thấy con trỏ đã publish mà object chưa khởi tạo xong. Một bug ẩn kỹ tới mức Java mất nhiều năm mới thừa nhận.
Ai cũng nói hash table là O(1). Tôi đo thử: O(1) chỉ đúng khi hệ số tải thấp — tải 0,25 tốn 1,17 probe (3,2ns), nhưng đẩy tải lên 0,99 thì probe trung bình nổ lên 43 và tra cứu chậm 10 lần. O(1) là trung bình có điều kiện, không phải bảo đảm vô điều kiện.
Tưởng giới hạn CPU của cgroup giống nice, chỉ cắn khi máy bận? Tôi đo: --cpus=0.5 vẫn chậm 2,2 lần và --cpus=0.25 chậm 6,5 lần dù 9/10 lõi ngồi không. Nó là hạn ngạch tuyệt đối, không phải ưu tiên — và ở hạn ngạch nhỏ còn tệ hơn tỉ lệ.
Tưởng CPU luôn chạy theo thứ tự mình viết, còn reorder bộ nhớ chỉ là lý thuyết trong sách? Tôi đo litmus store-buffer trên ARM: reorder xảy ra thật (11 ca trong 60 triệu vòng), rào dmb ish dập được về 0. Nhưng nó hiếm tới ~1 trên 5,5 triệu vòng — nên code sai vẫn qua sạch mọi test rồi nổ ở production.