JFR và profiling — Flight Recorder, JMC, async-profiler

JFR (Java Flight Recorder):

• Built-in JVM, không cài thêm. Java 11+ open-source.
• Overhead cực thấp <1%. Production safe always-on.
• Event-based: ghi event GC, JIT, lock, IO, allocation, exception. Rich metadata mỗi event.
• Java frame only: không thấy native / JNI stack.
• JMC GUI phân tích — table-based, drill down sâu.

async-profiler:

• External tool, cần cài (binary release).
• Overhead 1-3% (sampling rate cao hơn JFR).
• Sampling-based: mỗi N ms snapshot stack tất cả thread.
• Native + Java stack: thấy JNI, native lib, kernel call (perf integration).
• Flame graph SVG/HTML — visualization rất intuitive.
• Multiple event source: CPU (cycles, instructions), allocation, lock, page-fault.

Khi nào dùng JFR:

• Always-on production monitoring: 1-hour rotation, dump on incident.
• Cần event chi tiết: GC cause, lock owner, exception thrown count.
• Pure Java stack đủ: app không dùng native nhiều.

Khi nào dùng async-profiler:

• Flame graph để identify hot path: visual hơn JMC.
• Native stack quan trọng: app dùng JNI, native crypto, native DB driver.
• Allocation profiling chi tiết: per-method allocation rate.
• Lock contention deep: per-lock visualization.

Production setup chuẩn: JFR always-on (continuous safety net) + async-profiler on-demand (deep dive when needed). Không phải either/or.

Profiler instrumentation (kiểu cũ): chèn bytecode đo đạc vào đầu và cuối mọi method — mỗi lời gọi method gánh thêm vài instruction + ghi dữ liệu. Method nhỏ gọi hàng triệu lần/giây → overhead phình 10-30%, và tệ hơn: instrumentation làm JIT inline khác đi → số đo không còn phản ánh app thật.

JFR thiết kế khác từ gốc:

• Event-based, nằm sẵn trong JVM: GC, JIT, lock... vốn đã xảy ra trong JVM — JFR chỉ ghi lại metadata tại chỗ, không chèn code vào app.
• Method profiling bằng sampling (chụp stack định kỳ) thay vì đo mọi call — cost cố định theo sampling rate, không theo số lần gọi method.
• Per-thread buffer lock-free: mỗi thread ghi event vào buffer riêng, không tranh lock; buffer đầy mới flush sang global ring buffer / disk.
• Binary format + threshold filter: event ngắn hơn ngưỡng (vd lock wait dưới 10ms) bị bỏ qua từ đầu, không tốn công ghi.

Trade-off chấp nhận: sampling có thể bỏ sót method hiếm gặp, và threshold filter ẩn event nhỏ. Đổi lại được con số trung thực trên production — nơi instrumentation profiler không dám bật.

Cơ chế: JFR ghi event liên tục vào ring buffer trên disk (khi disk=true). Khi dữ liệu vượt maxage (1 giờ) hoặc maxsize (200MB), chunk cũ nhất bị xoá — luôn giữ "1 giờ gần nhất". Giống camera hành trình ô tô: ghi đè liên tục, chỉ giữ đoạn mới.

Khi incident xảy ra (alert lúc 3h05):

jcmd <PID> JFR.dump filename=/tmp/incident.jfr

File dump chứa toàn bộ 1 giờ trước đó — bao gồm chính khoảnh khắc 3h00 khi hệ thống lag. Đây là điều không tool snapshot nào (jstack, jstat) làm được: chúng chỉ thấy hiện tại, không thấy quá khứ.

Vì sao là setup chuẩn:

• Overhead dưới 1% — chi phí thường trực không đáng kể so với giá trị khi incident.
• Incident hiếm khi reproduce được: bug production thường phụ thuộc traffic pattern, data cụ thể, timing. Recording sẵn = không cần reproduce.
• Bounded resource: maxsize chặn disk usage, không lo log phình.

Lưu ý vận hành: đặt filename vào volume còn chỗ trống; với multi-instance, gắn PID/hostname vào tên file dump; tự động hoá dump trong alert handler để khỏi thao tác tay lúc 3h sáng.

Flame graph: trục X = tỷ lệ sample (thời gian), trục Y = độ sâu stack. Mỗi khối là 1 frame; khối con nằm trên khối cha (callee trên caller).

Plateau rộng trên đỉnh (khối rộng, không có khối con phía trên): method tự nó đốt CPU — sample dừng ở đó nghĩa là CPU đang chạy chính body method này (loop tính toán, regex, copy array). Đây là ứng viên optimize số 1: thu hẹp plateau = giảm CPU trực tiếp.

Tower cao (chuỗi khối chồng cao nhưng hẹp): call chain sâu — A gọi B gọi C... 50 tầng. Bản thân không tốn CPU nhiều (hẹp), nhưng gợi ý về kiến trúc: abstraction chồng tầng, recursive call, framework overhead. Nếu tower vừa cao vừa rộng → mỗi tầng cộng dồn cost (vd serialization lồng nhau) — xem có short-circuit được không.

Pattern khác đáng nhớ:

• Nhiều plateau rộng rải rác: không có hot spot đơn lẻ — optimize 1 chỗ không cứu được, cần nhìn tổng thể (algorithm, data structure).
• Plateau ở GC thread / __memcpy native: vấn đề không phải code logic mà allocation pressure — chuyển sang allocation profile (-e alloc).

Sai lầm phổ biến: nhìn flame graph CPU khi app chậm vì I/O wait — thread chờ socket không ăn CPU nên gần như vô hình trong CPU profile. Dùng wall-clock mode (-e wall) hoặc JFR I/O events cho case đó.

Profiler sampling truyền thống (VisualVM, JMX-based) lấy stack qua API Thread.getStackTrace — API này yêu cầu thread phải dừng tại safepoint (bài 11) để stack ổn định. Hệ quả gọi là safepoint bias: sample chỉ rơi vào các vị trí có safepoint poll (method return, loop back-edge), không bao giờ rơi vào giữa đoạn code nóng — hot loop được JIT bỏ safepoint poll trở nên "vô hình", profile méo.

async-profiler tránh bằng 2 cơ chế:

• AsyncGetCallTrace: internal API của HotSpot cho phép lấy Java stack ngay trong signal handler, tại bất kỳ điểm nào thread đang chạy — không cần chờ safepoint. Sample trúng cả giữa hot loop.
• perf_events (Linux): kernel gửi signal định kỳ theo CPU cycles; signal handler ghép native stack (từ kernel) + Java stack (từ AsyncGetCallTrace) → thấy được JNI, lib native, thậm chí kernel frame.

JFR method sampling cũng dùng cơ chế safepoint-free tương tự cho Java frame, nhưng không ghép native stack đầy đủ như async-profiler — đây là lý do app nặng JNI/native (crypto, DB driver, compression) nên deep-dive bằng async-profiler.

Trade-off: AsyncGetCallTrace là internal API không có spec chính thức — hiếm khi nhưng có thể fail trên 1 số frame (báo [unknown_Java]). Chấp nhận được cho profiling.