Java và dữ liệu bất biến: value class, withers, lazy constants

Một tập podcast về dữ liệu bất biến trong Java

Trong tập 73 của chuỗi "Ask the Architects" thuộc Inside Java Podcast, Nicolai Parlog trò chuyện với Dan Smith — người đóng góp cho các dự án Amber và Valhalla, đồng thời là Senior Java Platform Developer tại Oracle. Chủ đề: làm thế nào để Java trở nên thuận tay hơn khi mô hình hoá dữ liệu bất biến, vượt ra ngoài khuôn khổ của value class. Tập này được ghi trong khuôn khổ JavaOne 2026 và đăng ngày 29/10/2026.

Điểm đáng chú ý nằm ở chỗ: đây không phải một tính năng đơn lẻ, mà là một chùm tính năng đang dần khép lại thành một câu chuyện thiết kế thống nhất. Với người viết backend Java hằng ngày, đó là tín hiệu về hướng đi của ngôn ngữ trong vài năm tới.

Vấn đề: OOP linh hoạt nhưng không phải lúc nào cũng cần

Theo nội dung tập podcast, lập trình hướng đối tượng cho rất nhiều tự do khi mô hình hoá các miền nghiệp vụ đa dạng. Nhưng không phải thành phần nào cũng cần sự tự do đó. Dữ liệu — theo nghĩa thuần tuý là các giá trị được truyền đi, lưu trữ, so sánh — thường được mô tả tốt hơn bằng những kiểu đơn giản, bất biến.

OOP không ngăn cản việc đó, nhưng trước đây Java khiến nó khá lỉnh kỉnh: phải viết constructor, getter, equals, hashCode, toString, rồi xử lý cẩn thận để không ai sửa được đối tượng sau khi tạo. Record đã giải quyết một phần lớn, nhưng vẫn còn những chỗ gợn — đặc biệt khi cần tạo bản sao có thay đổi nhỏ, hoặc khi muốn tối ưu bộ nhớ cho các kiểu giá trị nhỏ nhưng xuất hiện với số lượng lớn.

Những mảnh ghép đang hình thành

Tập podcast điểm qua một loạt JEP liên quan, mỗi cái đứng độc lập nhưng cộng lại thì thay đổi cách viết code dữ liệu:

• JEP 513 – Flexible Constructor Bodies: cho phép đặt câu lệnh trước lời gọi super(...) hoặc this(...) trong constructor, nhờ đó có thể kiểm tra và chuẩn hoá tham số trước khi khởi tạo lớp cha. Với kiểu dữ liệu bất biến, đây là chỗ để chặn giá trị không hợp lệ ngay tại cửa vào.
• JEP 401 – Value Objects (Preview): các lớp giá trị không có identity, cho phép JVM lưu trữ và truyền chúng hiệu quả hơn — mô hình tinh thần gần với "struct" trong các ngôn ngữ khác, nhưng vẫn giữ được phương thức và sự an toàn kiểu của Java.
• JEP 468 – Derived Record Creation (Preview): hay còn gọi là "withers" — tạo bản sao của một record với một vài thành phần được thay đổi, viết gọn bằng cú pháp with. Đây là mảnh ghép rất thực dụng cho dữ liệu bất biến, vì bất biến nghĩa là mọi thay đổi đều phải sinh ra đối tượng mới.
• JEP 547 – Lazy Constants (Fourth Preview): cơ chế hằng số được khởi tạo một lần, trì hoãn, với chi phí truy cập thấp — hữu ích cho dữ liệu bất biến đắt tiền khi khởi tạo nhưng được đọc nhiều lần.

Ảnh: Inside Java

Điểm thú vị mà Dan Smith nhấn trong tập là các tính năng này không tồn tại riêng rẽ. Chúng ăn khớp ở bốn thao tác cơ bản với dữ liệu: định nghĩa kiểu, khởi tạo, sao chép có sửa đổi, và truy cập. Value class lo phần biểu diễn và hiệu năng; record lo phần khai báo ngắn gọn; withers lo phần sao chép; flexible constructor bodies lo phần bảo đảm bất biến ngay từ lúc tạo; lazy constants lo phần truy cập rẻ.

Vì sao đáng quan tâm với độc giả Việt Nam

Với lập trình viên backend, đặc biệt những người làm hệ thống tài chính, thương mại điện tử, logistics hay bất kỳ miền nào có nhiều bản ghi giao dịch, mô hình dữ liệu bất biến không phải chuyện học thuật. Nó ảnh hưởng trực tiếp tới ba thứ rất thực tế:

Thứ nhất là tính đúng đắn. Khi một đối tượng không thể bị sửa sau khi tạo, rất nhiều lớp lỗi biến mất: không còn lo một service nào đó lỡ tay gán lại field, không còn phải phòng thủ bằng defensive copy, không còn tranh chấp khi chia sẻ đối tượng giữa các thread. Với các hệ thống đang chạy Spring Boot, immutable DTO và record đã là thói quen tốt; value class và withers sẽ làm thói quen đó rẻ hơn về cú pháp.

Thứ hai là hiệu năng và bộ nhớ. Value object hứa hẹn giảm chi phí lưu trữ và truy cập cho những kiểu nhỏ như toạ độ, khoảng thời gian, mã tiền tệ, ID — những thứ xuất hiện hàng triệu lần trong bộ nhớ. Đây là lý do dự án Valhalla tồn tại từ lâu, và cũng là lý do các đội backend có khối lượng dữ liệu lớn nên theo dõi tiến độ.

Thứ ba là phong cách code. Khi withers thành chuẩn, pattern "tạo bản sao rồi sửa một field" sẽ gọn hơn nhiều so với builder thủ công hay constructor dài dằng dặc. Các thư viện ánh xạ, validation, serialization cũng sẽ phải cập nhật theo — nghĩa là hệ sinh thái sẽ có một đợt chuyển dịch, và hiểu sớm thì dễ thích nghi hơn.

Cần lưu ý rằng đây là các tính năng ở trạng thái preview hoặc đang trong quá trình hoàn thiện, không phải API đã chốt. Số liệu cụ thể về hiệu năng của value object hay lazy constants chưa được nêu trong nội dung tập podcast; nguồn chưa nêu các con số benchmark.

Ai nên theo dõi, và thử nhanh thế nào

Nhóm nên quan tâm trước tiên là lập trình viên Java viết thư viện nội bộ, người thiết kế mô hình miền, và những ai đang phải tối ưu bộ nhớ cho service chịu tải cao. Nếu bạn chỉ viết CRUD đơn giản trên framework hiện đại, các tính năng này vẫn hữu ích nhưng chưa phải ưu tiên cấp bách.

Cách thử nhanh nhất là bật preview feature trên một JDK có hỗ trợ các JEP tương ứng, rồi viết thử vài đoạn code nhỏ:

# Biên dịch với preview feature (cần JDK có hỗ trợ JEP tương ứng)
javac --release 27 --enable-preview ViDu.java
java --enable-preview ViDu

Sau đó thử ba việc: khai báo một record với kiểm tra tham số trong constructor, tạo bản sao bằng cú pháp withers, và khai báo một value class đơn giản để xem cú pháp hiện tại ra sao. Lưu ý rằng cú pháp preview có thể đổi giữa các bản JDK, nên đừng đưa vào code production; hãy dùng một nhánh thử nghiệm hoặc project sandbox.

Với lazy constants, thử khai báo một hằng số đắt tiền (ví dụ cấu hình đọc từ file, hoặc một bảng tra cứu lớn) và đo thời gian truy cập lần đầu so với các lần sau để cảm nhận cơ chế trì hoãn.

Những điểm cần cân nhắc

Thứ nhất, tất cả các JEP được nhắc trong tập đều chưa phải bản cuối. Value Objects đang ở preview, Derived Record Creation cũng ở preview, Lazy Constants đã tới preview lần thứ tư — nghĩa là thiết kế vẫn đang được tinh chỉnh và cú pháp có thể thay đổi. Đầu tư lớn vào preview API là rủi ro.

Thứ hai, value class không thay thế record. Chúng giải quyết bài toán khác nhau: record là cách khai báo dữ liệu gọn, value class là cách nói với JVM rằng kiểu này không có identity và có thể tối ưu. Việc hiểu nhầm hai khái niệm này sẽ dẫn tới thiết kế sai.

Thứ ba, hệ sinh thái đi sau ngôn ngữ. Framework, ORM, thư viện JSON, công cụ build đều cần thời gian hỗ trợ đầy đủ. Khi một tính năng mới ra khỏi preview, khoảng trống này thường vẫn còn vài mùa release.

Cuối cùng, đây là nội dung do Inside Java — kênh chính thức của nhóm Java tại Oracle — sản xuất, với người tham gia là kỹ sư của Oracle. Thông tin về định hướng ngôn ngữ từ nguồn này có độ tin cậy cao, nhưng góc nhìn đương nhiên là góc nhìn của nhóm phát triển nền tảng, không phải đánh giá độc lập từ bên ngoài.

Kết

Tập 73 của Ask the Architects vẽ ra một bức tranh khá rõ: Java đang dần trang bị đủ bộ công cụ để mô hình hoá dữ liệu bất biến một cách tự nhiên, không cần lách qua các thủ thuật OOP. Value class, withers, flexible constructor bodies và lazy constants là bốn mảnh của cùng một bức tranh. Với người làm backend, theo dõi tiến độ các JEP này là cách chuẩn bị trước cho một vài năm tới, khi các mẫu code quen thuộc có thể trông khác đi đáng kể.

Nguồn: Inside Java