Lý thuyết Java Core

Đừng trộn compiler, class loader và JIT

Contract: loading tìm biểu diễn class; linking gồm verification, preparation và resolution. Resolution có thể diễn ra sớm hoặc khi symbolic reference được dùng, không nhất thiết resolve toàn bộ chương trình trước main. Initialization mới thực thi static initializer theo quy tắc ngôn ngữ. Interpreting/JIT là cách triển khai runtime, không phải cam kết mọi method đều được JIT hay đều nhanh hơn sau một số lần gọi cố định. [R02 · JLS 12: Execution] · [R03 · JVMS 2: Runtime areas]

Thực hành build: lưu chương trình đầu tiên thành HelloJava.java, chạy lệnh ở thư mục chứa file. Kết quả là Xin chào Java 21!. Lệnh dưới ghi rõ encoding nguồn và release đích; --release không tự chứng minh dependency bên thứ ba tương thích runtime đích. [javac, Java 21]

javac -encoding UTF-8 --release 21 HelloJava.java
java HelloJava

Encoding đầu ra: nếu terminal hiển thị sai dấu tiếng Việt, kiểm riêng encoding/font của terminal và encoding source; biên dịch UTF-8 không tự cấu hình mọi console.

Widening không đồng nghĩa giữ mọi chữ số

Contract: int → long giữ nguyên giá trị, nhưng một số widening sang floating-point có thể mất precision. Cast 3_000_000_000L sang int trong ví dụ nguồn cho -1294967296, không ném lỗi chỉ vì vượt miền int. Unboxing một wrapper null gây NullPointerException. Primitive không phải object; wrapper như Integer mới là reference type. [JLS 5]

int n = 16_777_217;
float f = n;
System.out.println((int) f); // 16777216: mat precision
Integer missing = null;
// int value = missing;     // Neu bo comment: NullPointerException

Đọc ví dụ truyền tham số: giả sử Person có field String name và constructor Person(String name). Với p = new Person("Lan"), rename(p) sửa object mà p đang trỏ tới thành tên “An”; replace(p) không thay object mà biến p của caller đang trỏ tới. final trên reference ngăn gán lại biến, không làm object được tham chiếu thành immutable.

“Phủ đủ nhánh” có phạm vi cụ thể

Ví dụ nguồn giả định enum Status { NEW, RUNNING, DONE } và một biến Status status khác null. Mỗi nhánh → trả một nhãn; block nhiều statement trong switch expression dùng yield để trả giá trị. Không nhầm với switch kiểu case ...: có thể fall-through. [JLS 14] · [JLS 15]

Contract: exhaustive khi compile không đồng nghĩa null-safe. Với Java 21, selector reference bằng null cần nhánh case null nếu muốn xử lý nó trong switch; chỉ có default không bắt null. Khi enum/sealed hierarchy được biên dịch lại riêng và thêm biến thể, binary cũ cũng không được bảo đảm xử lý mọi giá trị mới. [JEP 441]

Quy tắc đọc code: trong x != null && x.isReady(), điều kiện đầu bảo vệ lời gọi sau. Enhanced for không cấp quyền sửa cấu trúc collection tùy ý: chọn API sửa phù hợp với implementation, thay vì trông chờ vòng lặp tự xử lý mutation.

Dispatch khác với lựa chọn overload

Contract: overload được chọn lúc compile theo kiểu khai báo của biểu thức và các quy tắc áp dụng method. Với instance method có thể override, runtime dispatch chọn implementation theo object thực tế. Static method được hide chứ không override như instance method; field access cũng không có dynamic dispatch theo cách đó. [JLS 8] · [JLS 15]

Phạm vi Java 21: “đã load class” chưa có nghĩa static block đã chạy. Trong quá trình tạo instance, superclass được khởi tạo trước phần instance initializer và constructor body tương ứng của subclass. Gọi method overridable từ constructor có thể đi vào subclass khi state subclass vẫn chưa hoàn chỉnh. [R02 · JLS 12: Execution]

Trade-off thiết kế: chọn inheritance khi subtype thực sự giữ contract và invariant của base type, không chỉ để dùng lại vài dòng code. Chọn composition khi cần thay dependency, test độc lập hoặc tránh ràng buộc lifecycle. Interface không phải “class không có code”: default/static/private method có vai trò riêng; abstract class phù hợp khi hierarchy cần state và construction chung.

Những tính năng ở đây không cần preview trên Java 21

Để chạy đoạn PaymentResult, đặt các khai báo sealed/record trong cùng file bài tập, khai báo PaymentResult result = new Paid("tx-01"); trước switch trong method. Kết quả nhánh đó là Thành công: tx-01. Ví dụ Money chỉ minh họa compact constructor kiểm amount; chưa kiểm currency, đơn vị tiền hoặc toàn bộ invariant nghiệp vụ.

record Team(java.util.List<String> members) {
    Team {
        members = java.util.List.copyOf(members);
    }
}

Scope guarantee: List.copyOf ở đây tạo list không sửa được và tách khỏi thay đổi cấu trúc của list đầu vào; không deep-copy phần tử. Các phần tử đang là String immutable. Nếu thay bằng object mutable, vẫn phải định nghĩa ownership hoặc copy phần tử. [R06 · List API]

String pool không biến primitive thành object

String a = "abc";
String b = "ab" + "c";
String c = new String("abc");
System.out.println(a == b);         // true
System.out.println(a == c);         // false
System.out.println(a.equals(c));    // true
System.out.println(a == c.intern()); // true

Contract: literal và string constant expression có interning theo quy tắc ngôn ngữ; new String("abc") tạo object khác. intern() trả reference canonical; nó không đổi identity của biến c. String literal vẫn là object String. Metadata constant pool của class file và tập các object string được intern không phải cùng một khái niệm. [String API] · [JLS 15] · [R03 · JVMS 2: Runtime areas]

Trade-off: pooling không phải lý do để dùng == so nội dung String đến từ input. Không dựa vào integer wrapper cache để so logical value. Dùng key có equality ổn định; việc map đã giữ reference không “đóng băng” state của key. StringBuilder phù hợp tích lũy trong loop; một biểu thức nối chuỗi đơn giản không mặc nhiên cần viết lại thủ công.

Unchecked còn bao gồm Error

Contract đã hiệu chỉnh: nhóm unchecked gồm RuntimeException, Error và các subclass của chúng. catch (Exception e) không bắt Error. Không biến điều này thành quy tắc bắt Throwable rồi tiếp tục; nhiều Error phản ánh tình trạng ứng dụng không có khả năng phục hồi thông thường. [JLS 11]

import java.io.IOException;

public class ResourceFailureDemo {
    static final class Resource implements AutoCloseable {
        @Override
        public void close() throws IOException {
            throw new IOException("close");
        }
    }

    public static void main(String[] args) {
        try (var resource = new Resource()) {
            throw new IOException("body");
        } catch (IOException failure) {
            System.out.println(failure.getMessage());
            System.out.println(failure.getSuppressed()[0].getMessage());
        }
    }
}

Ví dụ đọc file nguồn là phần thân một method trả List<String> và nhận Path path, với import từ java.io, java.nio.file. Lỗi phát sinh trong traversal của reader.lines() có thể được bọc thành UncheckedIOException, không đi vào riêng nhánh catch (IOException) trong ví dụ. toList() giữ kết quả trong memory; file lớn cần chiến lược xử lý streaming/bounded thay vì mặc định tải toàn bộ. [R16 · BufferedReader API]

Review rule: log nguyên cause và suppressed exceptions ở boundary chịu trách nhiệm; không return/throw từ finally làm che mất lỗi gốc. Khi bắt InterruptedException, truyền lên hoặc khôi phục interrupt flag theo contract của layer, không nuốt tín hiệu dừng. [JLS 14] · [R09 · ExecutorService API]

Wildcard là giới hạn phép toán, không phải phép đổi kiểu miễn phí

static <T> void copyAll(
        java.util.List<? extends T> source,
        java.util.List<? super T> target) {
    for (T value : source) {
        target.add(value);
    }
}

Với ? extends T, đọc phần tử như T nhưng không thêm tùy ý một T khác null vì kiểu cụ thể có thể hẹp hơn. Với ? super T, thêm T được nhưng đọc chỉ chắc chắn là Object. Đây là quy tắc type safety, không đảm bảo collection hỗ trợ mutation tại runtime; target không sửa được vẫn có thể ném UnsupportedOperationException.

Hiệu chỉnh phát biểu instanceof: không thể từ một giá trị có kiểu Object dùng instanceof List<String> để xác nhận kiểu của mọi phần tử. Dùng List<?> để kiểm “là list”, rồi validate nội dung ở boundary. Tuy nhiên, Java 16+ cho phép một số phép kiểm parameterized type đã an toàn từ static type, ví dụ List<String> x với x instanceof ArrayList<String>. Vì vậy không được diễn giải erasure thành “mọi instanceof có generic đều bị cấm”. [JLS 15]

Trade-off: tránh raw type và unchecked cast khi có thể diễn đạt bằng generic signature. Compile với cảnh báo và kiểm boundary deserialize/input. Erasure không xóa toàn bộ metadata generic khỏi class file; vấn đề là runtime không kiểm từng type argument như một reified container contract.

Không sửa được chưa chắc là snapshot

var original = new java.util.ArrayList<>(java.util.List.of("A"));
var view = java.util.Collections.unmodifiableList(original);
var snapshot = java.util.List.copyOf(original);
original.add("B");
System.out.println(view);     // [A, B]
System.out.println(snapshot); // [A]

Contract: unmodifiable view vẫn phản ánh backing collection; List.copyOf không phản ánh những thay đổi cấu trúc sau đó của nguồn. Cả hai không tự deep-copy phần tử; các factory List.of/copyOf không nhận phần tử null. [R06 · List API] · [R07 · Collections API]

Scope của bảng chọn cấu trúc: O(1) của hash lookup là điều kiện trung bình với phân bố hash phù hợp, không phải latency SLO. Access order của LinkedHashMap cần chế độ cấu hình tương ứng; map có order không tự trở thành cache có giới hạn hoặc thread-safe. Tree ordering phải được chọn nhất quán với logical equality mong muốn.

Vận hành: fail-fast iterator của HashMap chỉ cố gắng phát hiện structural modification, không phải cơ chế đồng bộ và không đảm bảo luôn ném ConcurrentModificationException. Với shared state, chọn đúng collection và atomic operation; không ghép containsKey rồi put và mặc nhiên cho là atomic. [HashMap API]

Lazy execution không bảo đảm mọi lambda đều chạy

Ví dụ nguồn giả định List<String> words không chứa null và import Map, Locale, Function, Collectors. Với ["Java", "JAVA", "JVM"], kết quả đếm là java=2, jvm=1; không suy ra thứ tự in map. Locale.ROOT biểu đạt chủ ý normalize độc lập locale hiển thị, không phải giải pháp đầy đủ cho mọi quy tắc tìm kiếm ngôn ngữ.

Contract: behavioral parameter phải non-interfering và thường stateless; stream implementation có thể lược bỏ operation nếu không làm đổi kết quả. Đừng đặt business side effect bắt buộc trong peek/map rồi coi đó là guarantee. Một stream không được traversal lại sau terminal operation. Captured reference effectively-final vẫn có thể trỏ tới object mutable, do đó không tự giải quyết thread safety. [Stream API]

Scope implementation: common ForkJoinPool là hành vi thường gặp của parallel stream trong OpenJDK, không phải quyền chọn executor được Stream API bảo đảm. Với blocking I/O hoặc nhu cầu isolation, thiết kế executor riêng thay vì dựa vào mẹo phụ thuộc implementation. Đo sequential và parallel bằng cùng workload trước khi chọn.

Optional: ưu tiên biểu đạt absent/present ở return type. orElse nhận một giá trị đã được tính theo quy tắc gọi method; orElseGet gọi supplier khi cần giá trị thay thế. Vì vậy fallback tốn kém hoặc có side effect nên được cân nhắc riêng. [Optional API] · [JLS 15]

Visibility không biến read–modify–write thành atomic

Contract: unlock monitor happens-before lock sau đó trên cùng monitor; write volatile happens-before các read sau đó của chính biến volatile ấy. Quan hệ này có thể publish cả những write trước đó, không chỉ giá trị flag. Nó không khóa một chuỗi thao tác read → tính → write như count++. Nhiều field cùng tạo một invariant cần protocol bảo vệ chung. [JLS 17]

static final class Message {
    private int payload;
    private volatile boolean ready;

    void publish() {
        payload = 42;
        ready = true;
    }

    int readWhenReady() {
        return ready ? payload : -1;
    }
}

Trong protocol một-lần ở trên, đọc ready == true cho phép quan sát payload == 42; không được tổng quát hóa sang nhiều writer hoặc tái sử dụng instance không có protocol mới. LongAdder trong ví dụ nguồn phù hợp counter thống kê có contention: sum() không là atomic snapshot khi vẫn có update, nên không dùng nó làm phép check-and-reserve quota. [R08 · LongAdder API]

Deadlock: bốn điều kiện kinh điển là mutual exclusion, hold-and-wait, no preemption và circular wait. Khi review, vẽ graph thứ tự lấy lock và external call. Timeout giúp thoát chờ theo policy, không tự bảo đảm dữ liệu đang sửa đã rollback hay không còn deadlock ở nơi khác.

Future hoàn tất không có nghĩa công việc nền đã dừng

Contract: các stage async của CompletableFuture không truyền executor thường dùng common pool theo API; stage không có Async có thể chạy trên thread hoàn tất stage. allOf trả CompletableFuture<Void>, không tự trả list kết quả. orTimeout làm future hoàn tất lỗi khi quá hạn, không có contract tự dừng I/O phía dưới; cancel(true) trên CompletableFuture cũng không bảo đảm interrupt computation. Phải thiết kế deadline và cancellation ở client/task thực tế. [CompletableFuture API]

Lifecycle: ví dụ nguồn giả định method bao quanh xử lý InterruptedException, ExecutionException và có callRemoteService(). get() đang chờ không giới hạn; ExecutorService.close() chờ task hoàn tất. Vì vậy chỉ thêm timeout cho get chưa bảo đảm toàn bộ block try-with-resources kết thúc đúng deadline. [R09 · ExecutorService API]

Trade-off: virtual threads không làm CPU-bound task nhanh hơn. Tạo thread theo task nhưng vẫn giới hạn concurrency vào database/downstream. Với platform-thread executor, xác định pool size, queue bound và rejection policy; queue vô hạn có thể chuyển overload thành tăng memory và thời gian chờ. Cần đo in-flight task, queue wait, timeout, rejected task và downstream saturation, không chỉ thread count. [JEP 444] · [R10 · ThreadPoolExecutor API]

Encoding, resource và timezone phải có chủ ý

Contract: stream từ Files.lines cần được đóng; dùng try-with-resources, chọn charset theo hợp đồng dữ liệu và không mặc định đọc toàn bộ file lớn vào heap. Đường dẫn và quyền truy cập thuộc môi trường triển khai; một đường dẫn hợp lệ trên máy phát triển không phải guarantee trên máy đích. [R15 · Files API]

try (var lines = java.nio.file.Files.lines(
        path, java.nio.charset.StandardCharsets.UTF_8)) {
    long nonBlank = lines.filter(line -> !line.isBlank()).count();
    System.out.println(nonBlank);
}

Date/time: Duration là lượng thời gian theo seconds/nanos; Period là lượng theo ngày/tháng/năm trong lịch ISO. Cộng “một ngày lịch” vào ZonedDateTime có thể khác cộng 24 giờ ở nơi đổi daylight saving time. LocalDate không tự xác định một instant vì thiếu giờ và zone. [R12 · Period API]

Reflection có giới hạn: setAccessible(true) không phải cách vượt qua mọi module boundary. JPMS và việc package được opens cho caller ảnh hưởng deep reflection; trySetAccessible() có thể trả false. Nếu framework cần mở package, ghi lại phạm vi tối thiểu và kiểm bằng đúng chế độ deployment, không chỉ classpath trên IDE. [R13 · AccessibleObject API]

Không suy ra process memory chỉ từ -Xmx

Scope: JVM specification mô tả runtime areas về mặt logic, không bắt mọi JVM dùng cùng layout. “Metaspace trong native memory” là mô hình HotSpot. Stack của virtual thread được triển khai bằng các stack chunk trong heap; không thể lấy số virtual thread nhân một native stack cố định để dự đoán memory. [R03 · JVMS 2: Runtime areas] · [JEP 444]

GC không phải lifecycle API: object không còn strong-reachable mới có cơ hội được thu hồi theo cơ chế GC/reference processing; không có lời hứa thu hồi ngay tại cuối scope. GC không thay close() cho file, connection hay resource bên ngoài. Khi điều tra leak, tìm đường giữ reference và retained size, không chỉ tổng allocation.

NMT: cần bật bằng startup option, ví dụ -XX:NativeMemoryTracking=summary. Nó có overhead và chỉ theo dõi phạm vi memory của HotSpot, không phải mọi allocation native của thư viện bên ngoài. Chọn baseline khi hệ thống đã ở trạng thái đại diện rồi so diff; đối chiếu với OS memory thay vì coi NMT bằng RSS. [R14 · Native Memory Tracking]

jcmd <pid> VM.native_memory baseline
jcmd <pid> VM.native_memory summary.diff
jcmd <pid> Thread.dump_to_file -format=json threads.json

Với virtual threads, bổ sung dump theo lệnh Thread.dump_to_file thay vì coi Thread.print truyền thống là toàn cảnh mọi virtual thread. Mỗi loại dump có mức thông tin khác nhau; kết hợp JFR, GC log và dấu thời gian request để phân biệt CPU, lock, queue và downstream. [JEP 444] · [jcmd, Java 21]

Từ nền tảng sang chuyên đề, rồi quay lại thực hành

Bốn thẻ phía trên giữ nguyên phạm vi chuyên đề mở rộng của nguồn. Chọn Class loading khi cần giải thích lỗi liên kết hoặc module boundary; chọn Platform API khi vướng charset, resource, HTTP hay metadata; chọn Concurrency nâng cao khi cần executor/cancellation protocol; chọn GC & diagnostics khi phải đi từ triệu chứng vận hành tới bằng chứng runtime.

Những nhánh đã dẫn ở đầu bài và trong nội dung vẫn là phần của lộ trình: OOP design, String Pool, Collections architecture, Collections Internals, Sorting algorithms và Design Patterns.

Trang này có 15 nhóm kiến thức; con số 15–18 trên bốn thẻ là nhãn chuyên đề trong nguồn, không phải bốn nhóm bổ sung vào tổng 15 của trang. Điểm tự kiểm trong bài là phần bổ sung cho việc đọc lý thuyết, không thay hoặc cộng vào bộ câu hỏi/lab chính thức của Part 01.