JDK 24 on miti99

Newsletter #28

Thu, 15 May 2025 00:00:00 +0700

Mời bạn thưởng thức Newsletter #28.

How Airbnb Measures Listing Lifetime Value

Nhóm Khoa học dữ liệu của Airbnb giới thiệu khung đo lường giá trị vòng đời của một chỗ ở (Listing Lifetime Value - LTV) trên một nền tảng hai phía, nơi có nhiều người bán và nhiều người mua cùng lúc. Khung này gồm ba đại lượng. LTV cơ sở là tổng số lượt đặt phòng mà một chỗ ở dự kiến nhận được trong 365 ngày tới, được ước lượng bằng học máy từ các đặc trưng như lịch trống, giá, vị trí, thâm niên của chủ nhà, rồi quy về hiện giá. LTV gia tăng lấy LTV cơ sở trừ đi phần “ăn thịt” từ chỗ ở khác, tức những lượt đặt vẫn xảy ra kể cả khi chỗ ở đó không tồn tại. Cuối cùng, LTV gia tăng nhờ tiếp thị đo phần giá trị mà các chiến dịch nội bộ thực sự tạo thêm.

Có ba thách thức khi triển khai. Thứ nhất, nhãn huấn luyện chỉ có sau 365 ngày nên mô hình dễ sai lệch khi thị trường biến động như thời COVID-19; nhóm đã rút ngắn cửa sổ huấn luyện, bổ sung dữ liệu địa lý chi tiết và chuyển sang LightGBM. Thứ hai, không bao giờ quan sát được “sự thật” về tính gia tăng, nên họ ước lượng một hàm sản xuất mô tả cách tổng cung và tổng cầu của từng phân khúc tạo ra lượt đặt: phân khúc cầu cao, cung thấp thì một chỗ ở mới mang lại nhiều giá trị gia tăng hơn. Thứ ba, để xử lý bất định, dự đoán được điều chỉnh hằng ngày dựa trên số lượt đặt đã thực nhận.

Six JDK 24 Features You Should Know About

Simon Ritter (Azul) điểm qua sáu tính năng đáng chú ý nhất của JDK 24, phiên bản phát hành ngày 18/3/2025 với 24 JEP, nhiều nhất kể từ khi Java chuyển sang lịch phát hành sáu tháng một lần. JEP 483 thuộc Project Leyden cho phép các lớp của ứng dụng ở sẵn trạng thái đã nạp và liên kết ngay khi JVM khởi động, dựa trên nền tảng Application Class Data Sharing, nhờ đó giảm thời gian khởi động. JEP 485 (Stream Gatherers) bổ sung giao diện Gatherer để lập trình viên tự định nghĩa thao tác trung gian cho Stream, tương tự cách Collector phục vụ thao tác kết thúc. JEP 491 gỡ bỏ một hạn chế lớn của virtual thread: trước đây khi bị chặn bên trong khối synchronized, virtual thread vẫn “ghim” luồng nền vì monitor gắn với luồng nền; nay monitor được gắn với chính virtual thread.

Ba JEP còn lại mang tính dọn dẹp. JEP 486 vô hiệu hóa vĩnh viễn Security Manager, vốn đã bị đánh dấu lỗi thời từ JDK 17 và hầu như không còn được dùng để bảo vệ mã phía máy chủ; ứng dụng nào còn phụ thuộc vào nó có thể phải thay đổi kiến trúc khi nâng cấp. JEP 498 khiến JVM phát cảnh báo ở lần đầu gọi các phương thức truy cập bộ nhớ trong sun.misc.Unsafe, khuyến khích chuyển sang VarHandle và Foreign Function & Memory API. JEP 501 đánh dấu cổng x86 32-bit (chỉ còn trên Linux, bản Windows đã bị gỡ ở JDK 21) để loại bỏ trong tương lai. Đây là bản tóm tắt gọn giúp bạn chuẩn bị trước khi lên JDK 25, phiên bản hỗ trợ dài hạn tiếp theo.

JavaOne 2025: Function and Memory Access in Pure Java

Bài viết trên InfoQ tường thuật phần trình bày của Per-Åke Minborg (Oracle) tại JavaOne 2025 về Foreign Function & Memory API (FFM, JEP 454), được chính thức đưa vào JDK 22 trong khuôn khổ Project Panama nhằm thay thế JNI. Theo Minborg, JNI buộc lập trình viên kết hợp Java và C một cách mong manh, tốn kém khi bảo trì và triển khai, truyền dữ liệu cồng kềnh, chỉ hỗ trợ kiểu nguyên thủy và đối tượng Java, không giải phóng bộ nhớ một cách chủ động và chỉ định địa chỉ được khoảng 2 GB. Các thư viện như JNA, JNR hay JavaCPP từng thử khắc phục nhưng không được đón nhận rộng rãi.

Ở phần bộ nhớ, MemorySegment đại diện cho một vùng nhớ liên tục với địa chỉ 64-bit, được bảo vệ khỏi truy cập ngoài giới hạn, truy cập sau khi giải phóng và truy cập từ luồng không được phép. Vòng đời vùng nhớ do Arena quản lý với bốn loại Global, Auto, Confined và Shared. ValueLayout và MemoryLayout mô tả dữ liệu theo cấu trúc để lấy ra VarHandle thay vì tự tính độ lệch bằng tay, và khai báo các VarHandle là final rất quan trọng để đạt hiệu năng tốt nhất. Ở phần hàm, công cụ jextract tự sinh liên kết Java từ tệp header của thư viện native, chẳng hạn gọi thẳng hàm qsort của C từ Java. Tóm lại, FFM mang đến cách truy cập bộ nhớ native an toàn, hiệu quả và gọi hàm native bằng mã Java thuần, không phải viết và duy trì mã C.

Ultimate Guide to Project Reactor, Thread-Locals and Context Propagation

Grzegorz Piwowarek giải thích vì sao việc truyền ngữ cảnh (context propagation) luôn là chủ đề khó trong Project Reactor. ThreadLocal<X> về bản chất giống Map<Thread, X>, trong khi một chuỗi phản ứng có thể nhảy sang luồng khác qua các toán tử như publishOn(), khiến giá trị ThreadLocal biến mất giữa chừng. Giải pháp cơ bản là Context của Reactor: ghi giá trị bằng contextWrite() và đọc lại bằng cách đổi map() thành flatMap() kết hợp Mono.deferContextual(). Tác giả cũng lưu ý rằng nếu có thể lấy giá trị trước khi vào chuỗi phản ứng thì cứ dùng biến thông thường cho đơn giản.

Phần khó hơn là tích hợp với các công cụ dựa vào ThreadLocal như ghi nhật ký bằng MDC: phải khôi phục giá trị vào MDC trước mỗi lambda, và mẫu execute-around giúp gói phần lặp lại vào một phương thức tiện ích withMDC. Với doOnNext() vốn không truy cập được Context, có thể dùng doOnEach(), kiểm tra tín hiệu onNext rồi lấy ngữ cảnh từ đối tượng Signal. Cuối cùng là truyền ngữ cảnh tự động: thêm thư viện io.micrometer:context-propagation, gọi Hooks.enableAutomaticContextPropagation() và đăng ký một ThreadLocalAccessor, Reactor sẽ tự khôi phục giá trị ở mỗi bước. Cách này tiện lợi nhưng có thể tốn kém hơn cách thủ công, và vì đây là thiết lập toàn cục cho cả JVM nên nó ảnh hưởng tới mọi chuỗi Reactor trong tiến trình; hãy cân nhắc theo từng trường hợp cụ thể.

JDK 24 G1/Parallel/Serial GC Changes

Thomas Schatzl (Oracle) tổng hợp thay đổi của các bộ thu gom rác dừng toàn bộ (stop-the-world) trong JDK 24. Với Parallel GC, một số thao tác đồng bộ không cần thiết trong vòng lặp di tản đã được loại bỏ (JDK-8269870); Serial GC tiếp tục được dọn dẹp và tái cấu trúc. Thay đổi đáng kể nhất nằm ở G1: để đạt mục tiêu thời gian tạm dừng, G1 dự đoán các chi phí như sao chép bộ nhớ hay cập nhật tham chiếu, nhưng giá trị khởi tạo được đo từ lâu trên một máy SPARC cũ nên rất bảo thủ, khiến G1 cần khoảng 30 lần thu gom mới thích nghi. Với JDK-8343189, giá trị đo thực tế đầu tiên ghi đè thẳng lên giá trị mặc định, giúp G1 thích nghi nhanh hơn nhiều, đổi lại có thể vượt mục tiêu tạm dừng ở vài lần đầu. Ngoài ra, G1 giờ quản lý remembered set của cả thế hệ trẻ như một đơn vị duy nhất (JDK-8336086), giảm trùng lặp và tiết kiệm bộ nhớ native.

Tác giả cũng hé lộ lộ trình JDK 25: việc gộp remembered set cho các vùng thế hệ cũ (JDK-8343782) đã được tích hợp, còn rào chắn ghi (write barrier) của G1 được làm lại hoàn toàn, hứa hẹn tăng thông lượng tới 10%, tạm dừng ngắn hơn và sinh mã tốt hơn, đổi lại cần thêm một khối bộ nhớ tĩnh khoảng 0,2% kích thước heap. Ngoài ra còn có thảo luận về việc đưa Automatic Heap Sizing giống ZGC sang các bộ thu gom này với đóng góp từ Microsoft và Google, cũng như biến G1 thành bộ thu gom mặc định thực sự thay cho Serial GC ở môi trường ít tài nguyên.

Making Makefiles for fun and profit

Darko Mesaroš (AWS) nhìn lại make, công cụ tự động hóa xây dựng đã 48 tuổi do Stuart Feldman tạo ra để lập trình viên không còn quên biên dịch lại những tệp vừa sửa. So với một kịch bản build.sh biên dịch lại mọi thứ, make chỉ xây dựng lại phần đã thay đổi. Tác giả mổ xẻ một Makefile cho dự án C: các biến (make gọi là macro), đích all chạy mặc định, quy tắc liên kết dùng các macro có sẵn $@ và $^, quy tắc mẫu %.o: %.c để biên dịch từng tệp, đích clean để dọn dẹp, và .PHONY để tránh xung đột khi thư mục có tệp trùng tên với đích.

Phần sau cho thấy make hữu ích vượt xa ngôn ngữ C: tự động hóa Terraform với việc nhận diện hệ điều hành và cảnh báo kỹ trước khi chạy terraform destroy, dựng môi trường phát triển cục bộ bằng Docker với Postgres và Redis cho một dự án Rust, quản lý dự án AWS CDK viết bằng TypeScript và Rust với các lệnh cài đặt, xây dựng, triển khai từng phần hoặc toàn bộ và kiểm thử cục bộ cùng DynamoDB Local, cũng như triển khai trang web tĩnh lên S3 kèm AWS Amplify. Để vượt qua cú pháp khó đọc, tác giả dùng Amazon Q Developer CLI sinh Makefile tự động, kể cả việc truy vấn động mã ứng dụng Amplify. Bài viết là lời nhắc rằng công cụ cũ vẫn rất đáng dùng, nhất là khi có trợ lý AI giúp hạ thấp rào cản ban đầu.

Improving Pinterest Search Relevance Using Large Language Models

Nhóm kỹ sư Pinterest chia sẻ cách họ dùng mô hình ngôn ngữ lớn (LLM) để cải thiện độ liên quan của kết quả tìm kiếm, tức mức độ một Pin thực sự đáp ứng nhu cầu của truy vấn thay vì chỉ dựa vào lượt tương tác trong quá khứ. Mô hình “thầy” là một cross-encoder nhận truy vấn cùng văn bản mô tả Pin, được tinh chỉnh trên dữ liệu gán nhãn thủ công như một bài toán phân loại nhiều lớp. Văn bản của Pin được làm giàu từ nhiều nguồn: tiêu đề và mô tả, chú thích ảnh do mô hình BLIP sinh ra, các truy vấn có tương tác cao nhất, tên bảng mà người dùng lưu Pin vào và tiêu đề trang liên kết. Trong các thử nghiệm, Llama-3-8B (tinh chỉnh bằng qLoRA) vượt BERT đa ngôn ngữ 12,5% và mô hình cơ sở 19,7% về độ chính xác,.

Vì LLM quá chậm và tốn kém để phục vụ trực tiếp, Pinterest dùng kỹ thuật chưng cất tri thức: mô hình thầy gán nhãn hằng ngày cho tập dữ liệu hàng tỷ dòng, rồi huấn luyện một mô hình “trò” gọn nhẹ dựa trên các embedding như SearchSAGE, PinSAGE, embedding hình ảnh cùng các đặc trưng khớp văn bản như BM25. Nhờ mô hình thầy đa ngôn ngữ, hệ thống khái quát tốt sang những ngôn ngữ và quốc gia không có dữ liệu gán nhãn. Thử nghiệm A/B cho thấy độ liên quan tăng 2,18% theo nDCG@20 và tỷ lệ hoàn thành tìm kiếm tăng hơn 1,5%. Hướng tiếp theo là phục vụ LLM trực tiếp, dùng mô hình thị giác – ngôn ngữ và học chủ động.

Bài viết đã được viết lại bởi Claude Code với Opus 5.5 vào ngày 27/09/2026.

Newsletter #20

Wed, 07 May 2025 00:00:00 +0700

Mời bạn thưởng thức Newsletter #20.

Performance Improvements in JDK 24

Bài viết trên Inside.java tổng hợp những cải tiến hiệu năng đáng chú ý nhất của JDK 24 so với JDK 23, liệt kê theo từng mục trong hệ thống theo dõi lỗi của JDK. Ở nhóm thư viện lõi, các thao tác hàng loạt của Foreign Function & Memory API như MemorySegment::fill, copy và mismatch giờ được xử lý bằng mã Java thuần khi vùng nhớ đủ nhỏ, tránh chi phí chuyển sang mã native qua Unsafe. Việc nối chuỗi chuyển sang dùng các lớp ẩn (hidden class) có thể lưu đệm và tái sử dụng thay vì dựng nhiều MethodHandle trung gian; các thuật toán SHA3 nhanh hơn tới 27% nhờ giảm chuyển đổi giữa mảng byte và mảng long; còn quá trình chuyển sang ClassFile API được tối ưu để giảm ảnh hưởng tới thời gian khởi động.

Ở tầng runtime, JEP 491 cho phép virtual thread bị chặn trong khối synchronized nhả luồng mang (carrier thread) thay vì bị ghim cố định, giúp mã dùng synchronized mở rộng tốt hơn. String::indexOf nhanh hơn khoảng 1,3 lần trên nền tảng x64 hỗ trợ AVX2. JEP 483 (Ahead-of-Time Class Loading & Linking), sản phẩm đầu tiên của Project Leyden, dùng bộ nhớ đệm AOT để cải thiện thời gian khởi động khoảng 42% trong ví dụ của bài. JEP 450 thử nghiệm header đối tượng chỉ 8 byte, giúp giảm 10–20% bộ nhớ với các khối lượng công việc thông thường. Ngoài ra, nền tảng RISC-V cũng nhận thêm nhiều hàm intrinsic như CRC32, Adler32 cùng các tối ưu cho so sánh chuỗi và đảo byte.

Clean your Memory: From Finalize to Cleaner

Stefano Fago giải thích rằng bộ thu gom rác (GC) của Java chỉ quản lý bộ nhớ, không tự giải phóng các tài nguyên bên ngoài như socket hay file handle; nếu quản lý sai, ứng dụng có thể rò rỉ tài nguyên, chậm dần hoặc sập. Cách cũ là ghi đè finalize(), nhưng phương thức này đã bị đánh dấu lỗi thời vì thời điểm chạy không đoán trước được, đối tượng phải qua thêm một chu kỳ GC mới được thu hồi, có thể gây rò rỉ nếu đối tượng vô tình bị giữ lại, và luồng Finalizer riêng dễ gây tranh chấp. Giải pháp thay thế là Cleaner API, có từ Java 9: bên dưới nó dùng PhantomReference cùng một luồng daemon nền, nhưng che giấu sự phức tạp của các lớp Reference. Bạn đăng ký đối tượng kèm một hành động dọn dẹp, và khi đối tượng không còn truy cập được, hành động đó được đưa vào hàng đợi để chạy trên luồng nền.

Cleaner có thể kết hợp với AutoCloseable: phương thức close() gọi clean() để dọn dẹp ngay khi cần, còn Cleaner đóng vai trò lưới an toàn. Tuy vậy, tác giả nhấn mạnh chỉ nên dùng Cleaner khi không thể giải phóng tài nguyên bằng try-with-resources hoặc gọi close() tường minh, vì cơ chế này dọn dẹp bất đồng bộ và tốn chi phí hơn do cần luồng nền. Khi viết hành động dọn dẹp, nên tránh lambda vì dễ vô tình giữ tham chiếu tới chính đối tượng cần dọn, khiến nó không bao giờ được thu hồi; hành động cũng cần ngắn gọn và không chặn, vì nhiều hành động có thể chạy đồng thời trên cùng một Cleaner.

5 Hidden Git Tips for Java Developers

Trên blog của Azul, Luqman Saeed giới thiệu năm tính năng ít được chú ý của Git, vượt ra ngoài bộ ba quen thuộc commit, push và pull, kèm ví dụ gắn với dự án Java. Đầu tiên là git bisect: khi không rõ commit nào gây lỗi, bạn đánh dấu commit hiện tại là xấu (git bisect bad) và một commit cũ còn chạy đúng là tốt (git bisect good <commit-hash>), rồi Git tìm kiếm nhị phân bằng cách lần lượt checkout commit ở giữa để bạn kiểm thử cho đến khi tìm ra thủ phạm; kết thúc bằng git bisect reset. Tiếp theo, git blame <tên-tệp> cho biết ai sửa từng dòng lần cuối và vào lúc nào (thêm cờ -L 50,60 để chỉ xem một đoạn), giúp bạn hiểu bối cảnh trước khi gỡ lỗi hay tái cấu trúc. Khi phải chuyển việc giữa chừng, git stash cất tạm các thay đổi chưa commit và git stash pop lấy chúng lại; git stash list cùng git stash apply <stash-id> giúp quản lý nhiều lần cất.

Với các tệp tạm do Maven hay Gradle sinh ra như .class hoặc thư mục target/, git clean -n cho xem trước, -f xóa tệp chưa theo dõi, -fd xóa cả thư mục, còn -x xóa luôn các tệp bị bỏ qua như .idea/. Cuối cùng, git hooks là các script tự chạy trước hoặc sau những sự kiện như commit, push hay merge; chẳng hạn một hook pre-commit đặt trong .git/hooks có thể chạy mvn test và hủy commit nếu kiểm thử thất bại. Mẹo bổ sung: git checkout - đưa bạn về nhánh vừa làm việc trước đó mà không cần gõ lại tên nhánh, vừa tiết kiệm thời gian vừa tránh gõ sai.

Simplify Your System by Challenging the Status-Quo and Learning from Other Ecosystems

Trong podcast của InfoQ, Max Rydahl Andersen, Distinguished Engineer tại Red Hat và tác giả của JBang, kể rằng sau một năm tạm rời Java, khi quay lại ông nhận ra cộng đồng đã tích tụ quá nhiều độ phức tạp, giống như “một nghìn vết cắt giấy” (thousand paper cuts): mỗi tính năng nhỏ đều hữu ích nhưng cộng lại thành gánh nặng. Quarkus, dự án ông tham gia, đảo ngược cách làm truyền thống bằng cách dời phần lớn xử lý sang thời điểm build thay vì runtime, nhờ đó ứng dụng khởi động rất nhanh. Tốc độ này còn mở ra trải nghiệm phát triển tốt hơn: tải lại nóng (hot reload), kiểm thử liên tục, Dev Services tự dựng các dịch vụ như PostgreSQL hay Kafka, và giao diện chat để thử dịch vụ AI qua LangChain4J ngay trong Dev UI.

Với JBang, ông lấy cảm hứng từ Python và Node.js để chạy Java chỉ từ một tệp duy nhất, thậm chí tự tải JDK nếu máy chưa cài; ông tuyên bố nếu tìm được môi trường phát triển nào dễ cài đặt hơn thì đó là lỗi của JBang. Max cũng cho rằng AI không thay thế được nền tảng kỹ thuật phần mềm và tư duy hệ thống, đồng thời cảnh báo AI sẽ giúp khai thác lỗ hổng (CVE) nhanh hơn, nên các hệ thống cũ cần được cập nhật thường xuyên hơn. Thông điệp chung của buổi trò chuyện: hãy thách thức hiện trạng và học hỏi từ các hệ sinh thái khác để giữ hệ thống đơn giản.

About “vibe coding”

Sorin Costea viết ngắn gọn về trào lưu “vibe coding”, tức để AI viết mã nguồn thay cho lập trình viên. Sau khi đọc bài “Vibe coding vs Reality”, ông thấy không chỉ riêng ông hoài nghi, vì chính ông đã thử Cursor với một dự án Java Maven và công cụ này thậm chí không đổi tên nổi một lớp: lúc thì chỉ đổi tên lớp mà không đổi tên tệp, lúc được yêu cầu lại thì tạo ra một tệp rỗng mang tên mới, và chuyện đó lặp lại hai lần.

Khi chia sẻ trên Hacker News, ông chỉ nhận được những phản hồi kiểu “haha Java”, khiến ông tự hỏi Cursor chỉ được huấn luyện cho các framework frontend thịnh hành hay những người ủng hộ nó không quan tâm đến ứng dụng thực tế. Kết quả là ông gỡ Cursor và càng hoài nghi các giải pháp AI “thần kỳ”, dù vẫn để ngỏ khả năng thay đổi: “Nhưng năm sau? Năm sau sẽ biết.”

Visual-Focused Algorithms Cheat Sheet

Nick M tổng hợp một bảng tra cứu (cheat sheet) thiên về hình ảnh cho các thuật toán quan trọng được dùng trong thực tế, nối tiếp bảng tra cứu cấu trúc dữ liệu trước đó của ông; mỗi thuật toán được giải thích bằng ví dụ đời thường và hình minh họa. Phần sắp xếp đi từ Selection Sort và Insertion Sort, đơn giản nhưng có độ phức tạp O(n²), đến Heap Sort, Quick Sort và Merge Sort với O(n log n), rồi Tim Sort, thuật toán lai giữa Insertion Sort và Merge Sort được dùng trong Python và Java. Phần tìm kiếm gồm Binary Search với O(log n) cùng DFS và BFS để duyệt đồ thị theo chiều sâu và chiều rộng. Phần đồ thị trình bày Prim và Kruskal để tìm cây khung nhỏ nhất, Dijkstra và Bellman-Ford để tìm đường đi ngắn nhất (Bellman-Ford xử lý được cả trọng số âm), A* dùng hàm ước lượng (heuristic), cùng Union-Find và Ford-Fulkerson.

Các phần tiếp theo bao quát tìm kiếm chuỗi, nén và mã hóa dữ liệu (Huffman, LZ, biến đổi Fourier, nén ảnh JPEG), tối ưu hóa (Simplex, Simulated Annealing), học máy và khoa học dữ liệu, cùng các thuật toán bảo mật và mật mã. Cuối bài là mục tài liệu luyện phỏng vấn như “14 Patterns to Ace Any Coding Interview” và “5 Simple Steps for Solving Dynamic Programming Problems”, rất hữu ích cho các bạn mới vào nghề đang chuẩn bị phỏng vấn.

Bonus: Vài ảnh hay ho đến từ ByteByteGo

Bài viết đã được viết lại bởi Claude Code với Opus 5.5 vào ngày 27/09/2026.