Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
Tưởng cond_wait thức dậy là điều kiện đã đúng, dùng if là đủ, và đánh thức gần như tức thì? Tôi đo: đánh thức tốn ~8,5µs (đúng một chuyển ngữ cảnh), busy-poll nhanh 245 lần nhưng đốt trọn một lõi, và spurious/lost wakeup bắt buộc phải while + mutex — bỏ một trong hai là mời một bug đua tranh không tài nào tái hiện.
Tưởng cứ đọc nhiều thì rwlock luôn nhanh hơn mutex? Tôi đo: với vùng tới hạn đọc cực ngắn, rwlock chậm hơn mutex 5,9 lần vì bộ đếm đọc là một ghi chung bị cache nảy; chỉ khi mỗi lần đọc đủ dài rwlock mới thắng 6,3 lần nhờ đọc thật sự song song. Điểm lật nằm ở độ dài đọc, không phải ở đọc-nhiều-hay-ít.
Một vòng 2 tỉ phép tính mà kết quả không ai dùng đo ra đúng 0,00 ns — gcc -O2 xóa cả vòng, hàm chỉ còn ret. Thêm một volatile sink là số nhảy lên 1,37 ns thật. Khử mã chết còn xóa dead store và mã sau return, và đây chính là lý do mọi benchmark cần 'quan sát' kết quả.
Để bí mật ở đâu cho đúng? Tôi đo bốn cách bằng một câu hỏi kiểm chứng được — ai đọc được nó — chứ không xếp thang cảm tính: hardcode (cả repo + lịch sử), biến môi trường (con thừa kế, /proc/environ, docker inspect), .env (an toàn đúng bằng quyền file), và file 400 trên tmpfs (hẹp nhất). Kèm một lần tôi đo sai /proc suýt kết luận biến môi trường kín.
Bốn cách dùng sai JWT, dựng lại và tấn công thật: alg:none tự phong admin, secret 'secret' bị bẻ trong một vòng lặp bảy phần tử, và HS/RS confusion thủng đúng khi bạn tự viết verify (PyJWT thì chặn). Sợi chỉ chung: ba trong bốn lỗi là tin vào thứ do chính kẻ tấn công kiểm soát.
Span db.query nói một con số, pg_stat_statements nói một con số khác cho đúng truy vấn đó, và chúng lệch nhau gần chục lần. Không cái nào sai — chúng đo hai thứ khác nhau, và cái hiệu của chúng mới là con số quyết định việc tối ưu SQL của bạn có ích hay hoàn toàn vô nghĩa.