Java 25: Giải Thích Các Cải Tiến Về JVM và Hiệu Năng

Java 25 là một bản LTS, nên khi bàn chuyện nâng cấp thì mọi người thường nhìn vào language features trước. Nhưng với nhiều hệ thống production, câu chuyện quan trọng hơn lại nằm ở bên dưới.

JDK 25 mang đến một loạt cải tiến ở JVM và runtime với mục tiêu:

• giảm chi phí bộ nhớ,
• cải thiện warmup,
• làm cho profiling hữu ích hơn,
• củng cố các lựa chọn GC thiên về độ trễ thấp,
• và giúp các workflow tối ưu startup dễ dùng hơn.

Trong bài tổng quan, chúng ta đã nhìn toàn bộ bản phát hành ở mức cao. Trong bài về thay đổi ngôn ngữ, chúng ta tập trung vào phần source code. Bài này sẽ đi xuống một tầng nữa và tập trung vào những gì thay đổi trong HotSpot JVM, JIT, GC và bộ công cụ JFR.

Những thay đổi quan trọng nhất về JVM và hiệu năng trong Java 25 là:

• JEP 519: Compact Object Headers
• JEP 514: Ahead-of-Time Command-Line Ergonomics
• JEP 515: Ahead-of-Time Method Profiling
• JEP 521: Generational Shenandoah
• JEP 509: JFR CPU-Time Profiling (Experimental)
• JEP 518: JFR Cooperative Sampling
• JEP 520: JFR Method Timing & Tracing

Phân Loại Nhanh

Nhìn từ góc độ vận hành thực tế, bạn có thể nhóm chúng như sau:

Chủ yếu liên quan đến hiệu quả runtime

• Compact Object Headers
• Generational Shenandoah

Chủ yếu liên quan đến startup và warmup

• Ahead-of-Time Command-Line Ergonomics
• Ahead-of-Time Method Profiling

Chủ yếu liên quan đến observability và diagnostics

• JFR CPU-Time Profiling
• JFR Cooperative Sampling
• JFR Method Timing & Tracing

Đây là mental model đơn giản nhất để quyết định nên đánh giá phần nào trước.

1. Compact Object Headers

JEP 519 đưa compact object headers từ experimental feature thành product feature trong Java 25.

Nó Có Nghĩa Là Gì

Mỗi object trong Java đều mang theo một phần metadata ở header. Phần header đó là cần thiết, nhưng nó cũng tiêu tốn bộ nhớ. Với những ứng dụng có rất nhiều object, chỉ cần giảm được một chút chi phí trên mỗi object cũng có thể tạo ra khác biệt đáng kể ở mức toàn hệ thống.

Compact object headers hướng tới việc giảm phần overhead đó.

Đây không phải kiểu tính năng làm thay đổi code của bạn. Đây là kiểu tính năng có thể cải thiện "kinh tế vận hành" của code hiện tại khi heap đầy những object nhỏ.

Vì Sao Nó Quan Trọng

Theo JEP chính thức, các thử nghiệm cho thấy:

• giảm lượng heap sử dụng,
• giảm số lần garbage collection trong một số workload,
• và cải thiện CPU time ở một số benchmark.

Một ví dụ trong JEP cho biết SPECjbb2015 dùng ít hơn 22% heap và ít hơn 8% CPU time trong một cấu hình, đồng thời giảm số lần GC trong một cấu hình khác.

Điều đó không có nghĩa là mọi ứng dụng đều sẽ có mức cải thiện giống nhau, nhưng hướng đi thì rất rõ: giảm object-header overhead có thể cải thiện cả hiệu quả bộ nhớ lẫn hành vi GC.

Điều Cần Lưu Ý

Tính năng này là product feature trong Java 25, nhưng không phải layout mặc định cho object header.

Điểm này rất quan trọng về mặt vận hành. Bạn nên xem đây là thứ cần benchmark có chủ đích, chứ không phải thứ tự động có sau khi nâng cấp.

Ai Nên Quan Tâm Nhiều Nhất

Compact object headers đặc biệt đáng quan tâm với:

• service nhạy cảm về bộ nhớ,
• cache chứa nhiều object,
• workload backend cấp phát object liên tục,
• và các team chạy heap lớn, nơi chỉ vài phần trăm cải thiện cũng có ý nghĩa về chi phí.

2. Ahead-of-Time Command-Line Ergonomics

JEP 514 tự nó không phải là một tối ưu runtime trực tiếp. Thay vào đó, nó làm cho workflow tạo ahead-of-time cache của Java dễ dùng hơn đáng kể.

Vấn Đề Trước Java 25

Trước thay đổi này, việc tạo AOT cache yêu cầu workflow hai bước khá vướng:

1. Chạy training phase để record AOT configuration.
2. Chạy lệnh thứ hai để build cache.

Workflow đó linh hoạt, nhưng nó tạo ra friction. Mà friction thì quan trọng, vì performance feature nào khó dùng quá thì cuối cùng thường cũng không được dùng.

Java 25 Bổ Sung Gì

Java 25 bổ sung cách đi một lệnh đơn giản hơn với -XX:AOTCacheOutput=...

Ví dụ:

java -XX:AOTCacheOutput=app.aot -cp app.jar com.example.App

Sau đó:

java -XX:AOTCache=app.aot -cp app.jar com.example.App

Mục tiêu ở mức cao rất đơn giản: làm cho các workflow tối ưu startup trở nên thực tế hơn với team thật.

Vì Sao Điều Này Quan Trọng

Thay đổi này quan trọng vì tối ưu startup trong Java đang dần đi theo hướng rõ ràng hơn:

• training run,
• cache,
• tăng tốc warmup,
• và tuning startup có chủ đích hơn.

JEP 514 giúp giảm chi phí vận hành khi muốn thử các kỹ thuật đó.

Lưu Ý

JEP chính thức có nhắc một điểm quan trọng: workflow một bước có thể cần nhiều bộ nhớ hơn khi tạo cache, vì sub-invocation tạo cache dùng heap riêng của nó.

Lời khuyên thực tế là:

• ưu tiên workflow một bước khi cần sự tiện lợi,
• nhưng vẫn nhớ workflow hai bước cho môi trường bị giới hạn tài nguyên hoặc pipeline cần tùy biến hơn.

3. Ahead-of-Time Method Profiling

JEP 515 là một trong những thay đổi chiến lược quan trọng nhất về hiệu năng trong Java 25.

Vấn Đề Nó Giải Quyết

Ứng dụng Java thường không đạt peak performance ngay lập tức. JIT compiler cần thời gian để quan sát ứng dụng, xác định hot method và tối ưu chúng.

Giai đoạn warmup đó là overhead rất thật trong:

• process sống ngắn,
• service autoscale,
• workload kiểu serverless,
• và các hệ thống coi trọng tốc độ phục hồi.

Java 25 Bổ Sung Gì

Java 25 mở rộng AOT cache để có thể lưu method-execution profiles được thu thập từ một training run trước đó.

Điều đó có nghĩa là JVM có thể khởi động với hiểu biết tốt hơn về phần nào là hot, thay vì phải học lại từ đầu trong production.

Tác Động Thực Tế

Điều JEP muốn nhấn mạnh không phải là Java bỗng nhiên biến thành ngôn ngữ biên dịch ahead-of-time hoàn toàn. Điểm chính là Java có thể warm up nhanh hơn vì thông tin profiling từ lần chạy trước đã có sẵn ngay lúc startup.

Đây là một khác biệt nhỏ về câu chữ nhưng rất quan trọng về bản chất.

• Đây không phải là "thay JIT".
• Đây là "giúp JIT khởi động thông minh hơn".

Ví dụ chính thức trong JEP cho thấy một chương trình nhỏ dùng Stream cải thiện từ 90 ms xuống còn 73 ms, tức khoảng 19%, sau khi thêm cached profiles.

Ứng dụng thực tế sẽ khác nhau, nhưng ý tưởng cốt lõi rất đáng chú ý: chuyển một phần "trí nhớ warmup" từ production run sang training run.

Ai Nên Đánh Giá Tính Năng Này

Tính năng này đặc biệt phù hợp với:

• nền tảng coi trọng startup time,
• service thường xuyên scale lên xuống,
• ứng dụng có workload lặp lại tương đối ổn định,
• và các team đã bắt đầu quan tâm đến hướng tối ưu kiểu Project Leyden.

4. Generational Shenandoah

JEP 521 đưa generational mode của Shenandoah từ experimental feature thành product feature trong Java 25.

Vì Sao Điều Này Quan Trọng

Collector có pause time thấp rất giá trị, nhưng generational collection cũng là một trong những ý tưởng bền vững nhất trong thiết kế GC. Phần lớn object chết rất sớm, nên việc thu gom object trẻ khác với object già thường sẽ hiệu quả hơn.

Java 25 kết hợp hai ý tưởng đó gọn gàng hơn cho Shenandoah.

Thực Tế Thay Đổi Gì

Trong JDK 24, generational Shenandoah cần experimental flags. Trong JDK 25, nó không còn cần -XX:+UnlockExperimentalVMOptions nữa.

Điều đó làm giảm rào cản khi đánh giá và cũng cho thấy mức độ trưởng thành cao hơn.

Điều Cần Lưu Ý

Theo JEP, generational Shenandoah không trở thành chế độ mặc định trong Java 25. Shenandoah vẫn mặc định là single-generation mode nếu bạn không chủ động đổi.

Một lần nữa, đây là tính năng để đánh giá có chủ đích, chứ không phải thay đổi mặc định sau khi nâng cấp.

Ai Nên Quan Tâm

Generational Shenandoah hấp dẫn nhất với:

• hệ thống nhạy cảm với độ trễ,
• workload nhạy với hành vi GC,
• team đã dùng Shenandoah,
• và performance engineer đang so sánh các collector bằng traffic gần production.

5. JFR CPU-Time Profiling

JEP 509 bổ sung CPU-time profiling cho JFR trên Linux, ở trạng thái experimental.

Vì Sao Nó Quan Trọng

Execution-time sampling truyền thống và CPU-time profiling thực thụ không giống nhau.

Một method có thể:

• tốn nhiều wall-clock time vì phải chờ IO,
• hoặc tốn nhiều CPU vì nó thực sự đang tính toán.

Đó là hai bài toán tối ưu hoàn toàn khác nhau.

Java 25 Bổ Sung Gì

Java 25 cho phép JFR ghi nhận CPU-time samples trên Linux bằng cơ chế CPU timer của kernel. Điều đó giúp việc profile CPU chính xác hơn so với chỉ dựa vào execution-time sampling thông thường.

JEP cũng nhấn mạnh một lợi ích đáng giá: CPU-time profiling có thể phản ánh tốt hơn lượng CPU bị tiêu tốn khi Java code tương tác với native code.

Vì Sao Nó Thú Vị Về Mặt Vận Hành

Điều này làm JFR trở nên đáng tin hơn như một công cụ profiling tích hợp sẵn cho production, đặc biệt trong các môi trường triển khai chủ yếu trên Linux.

Thay vì xem profiler bên thứ ba là lựa chọn nghiêm túc duy nhất, team Java giờ có một con đường built-in mạnh hơn để phân tích CPU.

Lưu Ý

Tính năng này:

• chỉ có trên Linux trong Java 25,
• không bật mặc định,
• và vẫn ở trạng thái experimental.

Vì vậy, các team nên xem nó là rất hứa hẹn, nhưng chưa phải thứ áp dụng phổ quát ngay lập tức.

6. JFR Cooperative Sampling

JEP 518 cải thiện độ ổn định của stack sampling trong JFR.

Vấn Đề Cũ

Lấy mẫu stack cho chính xác là việc không đơn giản. Nếu chỉ lấy mẫu ở safepoint thì có thể bị bias, nhưng nếu lấy mẫu bất đồng bộ ngoài safepoint thì lại tiềm ẩn rủi ro và độ phức tạp cao.

Trong lịch sử, sự căng kéo này tạo ra cả vấn đề về độ chính xác lẫn độ ổn định.

Java 25 Thay Đổi Điều Gì

Java 25 thiết kế lại cơ chế sampling của JFR để việc stack walking chỉ diễn ra ở safepoint, đồng thời vẫn giảm safepoint bias bằng cách tiếp cận cooperative.

Điểm rút ra ở mức thực tế là:

• stack sampling an toàn hơn,
• logic nội bộ gọn hơn,
• và sampler thread scale tốt hơn.

Vì Sao Bạn Nên Quan Tâm

Đa số application developer sẽ không nhìn thấy điều này trực tiếp, nhưng có thể cảm nhận gián tiếp qua trải nghiệm JFR ổn định hơn.

Đây là kiểu hạ tầng nền làm tăng niềm tin vào tool của platform.

Nó cũng quan trọng vì JEP 509 dựa trên cơ chế được giới thiệu ở đây.

7. JFR Method Timing and Tracing

JEP 520 mở rộng JFR với method timing và method tracing thông qua bytecode instrumentation.

Điều Này Mở Ra Gì

Thay vì chỉ dựa vào sampling mang tính thống kê, Java 25 bổ sung cách thu thập timing và trace chính xác cho một nhóm method được chọn.

Điều này rất hữu ích khi bạn muốn trả lời những câu hỏi rất cụ thể như:

• method nào đang kích hoạt một startup path chậm,
• code path nào đang gây ra initialization tốn kém,
• hoặc một hot method thực sự được gọi bao nhiêu lần.

Vì Sao Nó Khác Với Profiling Thông Thường

Sampling rất mạnh khi bạn cần góc nhìn rộng trên toàn ứng dụng.

Method timing và tracing phù hợp hơn khi bạn cần quan sát có chủ đích vào một nhóm method nhỏ.

Sự đánh đổi này rất quan trọng vì instrumentation chính xác có thể cực kỳ hữu ích, nhưng bạn không muốn áp nó lên quá nhiều method cùng lúc.

Lời Khuyên Thực Tế Khi Vận Hành

Hãy dùng tính năng này cho:

• điều tra có trọng điểm,
• phân tích startup,
• xác nhận các performance fix,
• và debug đúng chỗ cần nhìn.

Đừng xem nó là thứ thay thế hoàn toàn cho low-overhead continuous sampling.

Đa Số Team Nên Đánh Giá Gì Trước

Nếu bạn đang nâng cấp lên Java 25 và muốn có một checklist ngắn nhưng đáng tiền, hãy bắt đầu ở đây:

1. Compact Object Headers nếu bạn quan tâm đến memory footprint và GC pressure.
2. Ahead-of-Time Method Profiling nếu startup và warmup là vấn đề lớn.
3. Generational Shenandoah nếu bạn đã quan tâm nhiều đến collector behavior và độ trễ thấp.
4. JFR CPU-Time Profiling và JFR Method Timing/Tracing nếu team của bạn làm production diagnostics nghiêm túc.

Đây là lộ trình đánh giá đầu tiên hợp lý cho phần lớn team mà không phải chạm vào mọi knob mới cùng một lúc.

Kết Luận

Câu chuyện JVM và hiệu năng trong Java 25 mạnh ở chỗ nó cải thiện nhiều giai đoạn khác nhau trong vòng đời ứng dụng:

• trước startup, nhờ workflow AOT tốt hơn,
• trong warmup, nhờ cached method profiles,
• trong steady state, nhờ cải thiện về memory và GC,
• và trong lúc điều tra sự cố, nhờ bộ công cụ JFR mạnh hơn rõ rệt.

Đây chính xác là kiểu việc mà một bản LTS trưởng thành nên làm.

Nó không hứa hẹn phép màu. Thay vào đó, nó trao cho các team quan tâm đến hiệu năng những building block tốt hơn, khả năng chẩn đoán tốt hơn, và ít lý do hơn để trì hoãn việc benchmark nghiêm túc.

Trong bài tiếp theo, chúng ta sẽ rời khỏi JVM và nhìn sang phía standard library để xem các API và thư viện mới trong Java 25 có gì đáng chú ý.