Expert, Software Engineer (Tech Lead)

N+1 xảy ra khi bạn lấy N bản ghi bằng 1 query, rồi mỗi lần truy cập quan hệ lazy lại phát sinh thêm 1 query. Ví dụ lấy 100 đơn hàng, rồi gọi order.getCustomer() trong vòng lặp là thành 101 query.

Cách xử lý:

• JOIN FETCH trong JPQL: select o from Order o join fetch o.customer.
• @EntityGraph(attributePaths = "customer") trên method của repository.
• @BatchSize hoặc hibernate.default_batch_fetch_size để gom lazy load thành câu IN (...).
• Với màn hình chỉ đọc, trả thẳng DTO projection thay vì entity.

Phát hiện bằng cách bật log SQL (spring.jpa.show-sql hoặc log của Hibernate) khi dev, hoặc dùng thống kê của Hibernate.

Hay sai: đổi sang FetchType.EAGER cho xong. Cách này chỉ đổi chỗ lỗi và làm mọi truy vấn khác nặng hơn. Fetch join nhiều collection cùng lúc cũng dễ gây tích Descartes.

Hai vùng chính: stack (mỗi thread một stack, chứa biến cục bộ và tham chiếu) và heap (chứa object, dùng chung). Ngoài ra có Metaspace chứa thông tin class.

• GC tìm các object không còn được tham chiếu từ "GC roots" (biến trên stack, field static...) và thu hồi.
• Heap chia theo thế hệ: object mới nằm ở young generation, sống lâu thì được chuyển lên old generation.
• G1 là GC mặc định; ZGC hợp khi cần pause rất ngắn với heap lớn.

Java vẫn leak khi object không dùng nữa mà vẫn còn tham chiếu:

• Cache hoặc static Map chỉ thêm, không bao giờ xoá.
• ThreadLocal không remove() trong thread pool.
• Listener đăng ký mà không huỷ.

Người phỏng vấn muốn nghe: phân biệt được OutOfMemoryError: Java heap space với lỗi Metaspace, và biết dùng heap dump để tìm ai đang giữ object.

Virtual thread là thread nhẹ do JVM quản lý, được gắn lên một số ít platform thread (carrier). Khi gặp I/O blocking, nó nhả carrier để chạy việc khác, nên bạn có thể có hàng trăm nghìn thread mà vẫn viết code blocking dễ đọc.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    ids.forEach(id -> executor.submit(() -> callApi(id)));
}

• Hợp với tải nhiều I/O (gọi DB, HTTP). Không giúp gì với tác vụ nặng CPU.
• Spring Boot 3.2+ bật bằng spring.threads.virtual.enabled=true.
• Không đưa virtual thread vào pool: tạo mới cho mỗi task là cách dùng đúng.
• Giới hạn tài nguyên (connection pool DB) vẫn là giới hạn thật; dùng Semaphore nếu cần.
• Trên Java 21, blocking bên trong synchronized có thể "pin" carrier; các bản JDK mới hơn đã cải thiện. Cẩn thận với ThreadLocal chứa object lớn.

Người phỏng vấn muốn nghe: virtual threads tăng throughput, không làm từng request nhanh hơn.

Super-loop chạy tuần tự các việc trong một vòng while(1), đơn giản nhưng một việc chậm sẽ làm trễ mọi việc khác. RTOS có scheduler preemptive theo độ ưu tiên, giúp các việc cần thời gian thực được đáp ứng đúng hạn.

• Mutex: khoá loại trừ cho tài nguyên dùng chung, có khái niệm sở hữu (ai khoá thì người đó mở) và thường có priority inheritance để giảm đảo ưu tiên.
• Binary semaphore: dùng để báo hiệu giữa ISR và task hoặc giữa các task, không có sở hữu.
• Counting semaphore: quản lý N tài nguyên giống nhau.

Hay sai: dùng semaphore thay mutex để bảo vệ tài nguyên, gặp priority inversion: task ưu tiên cao chờ task thấp đang giữ khoá, trong khi task trung bình chiếm CPU.

Người phỏng vấn muốn nghe: bạn biết đặt độ ưu tiên task và kích thước stack hợp lý, và từng phát hiện stack overflow.

Undefined behavior (UB) là những thao tác mà chuẩn ngôn ngữ không quy định kết quả. Compiler được phép giả định UB không bao giờ xảy ra và tối ưu theo giả định đó, nên lỗi có thể chỉ lộ ra ở bản build -O2 hoặc trên một compiler khác.

Ví dụ hay gặp:

• Tràn số nguyên có dấu (tràn số không dấu thì được định nghĩa là quay vòng).
• Truy cập mảng ngoài phạm vi, dereference con trỏ null hoặc dangling.
• Đọc biến chưa khởi tạo, data race giữa các thread.
• Vi phạm strict aliasing, vd. ép float* sang int* rồi đọc (nên dùng memcpy hoặc std::bit_cast từ C++20).

Phát hiện: bật cảnh báo -Wall -Wextra, chạy test với -fsanitize=address,undefined, dùng static analysis (clang-tidy, cppcheck, MISRA checker).

Người phỏng vấn muốn nghe: "chạy đúng trên máy tôi" không chứng minh code không có UB.

Tận dụng giờ làm trùng nhau cho việc cần trao đổi trực tiếp, phần còn lại làm bất đồng bộ có tài liệu.

• Thống nhất lịch họp cố định trong khung giờ trùng (daily hoặc vài buổi mỗi tuần), có agenda và biên bản.
• Câu hỏi gom lại, viết rõ ràng kèm ngữ cảnh và phương án đề xuất, để khách trả lời được ngay trong một lần.
• Báo cáo định kỳ: đã làm, sẽ làm, rủi ro, quyết định cần khách đưa ra.
• Demo cuối sprint để khách thấy sản phẩm thật; ghi hình nếu khách không tham gia được.
• Lưu ý khác biệt văn hoá: một số khách cần nói thẳng, một số cần trang trọng; chủ động báo tin xấu sớm.

Hay sai: để team chờ câu trả lời của khách cả ngày mà không có việc dự phòng.

Race condition xảy ra khi nhiều thread đọc-sửa-ghi cùng dữ liệu mà không đồng bộ. Mỗi công cụ giải quyết một phần:

• volatile: đảm bảo visibility (thread khác thấy giá trị mới nhất), nhưng không làm count++ thành atomic.
• synchronized: vừa loại trừ lẫn nhau vừa đảm bảo visibility (quan hệ happens-before).
• ReentrantLock: như synchronized nhưng có tryLock với timeout, lock có thể ngắt, nhiều Condition.
• AtomicInteger/LongAdder: đếm không cần lock.
• ConcurrentHashMap: thread-safe với độ tranh chấp thấp. Dùng compute/merge/putIfAbsent cho thao tác kép, đừng get rồi put.

Hay sai: dùng Collections.synchronizedMap rồi duyệt map mà không lock, hoặc kiểm tra if (!map.containsKey(k)) map.put(k, v) trên map đồng thời: hai bước riêng lẻ vẫn bị chen ngang. Cách tốt nhất vẫn là giảm state dùng chung (object bất biến, mỗi thread một bản).

Đi từ số liệu đến bằng chứng, đừng đoán rồi sửa.

1. Xem metrics (Actuator, Micrometer): latency, số request, heap, GC pause, connection pool đang chờ, thời gian gọi DB và API ngoài.
2. CPU cao: lấy thread dump vài lần cách nhau vài giây (jcmd <pid> Thread.print hoặc jstack), tìm thread luôn RUNNABLE ở cùng chỗ. Có thể là vòng lặp, regex xấu, hoặc GC chạy liên tục.
3. Chậm mà CPU thấp: thread đang chờ: hết connection DB, lock, gọi API ngoài không có timeout.
4. OOM hoặc heap tăng dần: bật -XX:+HeapDumpOnOutOfMemoryError, mở heap dump bằng Eclipse MAT, xem ai giữ nhiều bộ nhớ nhất.
5. Java Flight Recorder (jcmd <pid> JFR.start) cho profile chi phí thấp, dùng được trên production.

Người phỏng vấn muốn nghe: có quy trình rõ ràng, biết cả cách giảm thiệt hại tạm thời (rollback, scale) trước khi tìm nguyên nhân gốc.

Đây là bài toán lost update. Có hai hướng chính, chọn theo mức độ tranh chấp:

• Optimistic locking: thêm field @Version. Khi update, Hibernate kèm điều kiện where version = ?; nếu người khác đã sửa trước, bạn nhận OptimisticLockException và có thể retry hoặc báo lỗi. Hợp khi tranh chấp ít.
• Pessimistic locking: @Lock(LockModeType.PESSIMISTIC_WRITE) sinh SELECT ... FOR UPDATE, giữ khoá đến hết transaction. Hợp khi tranh chấp nhiều, đổi lại throughput giảm và có nguy cơ deadlock.
• Đơn giản nhất cho tồn kho: update có điều kiện ngay trong DB:

UPDATE product SET stock = stock - 1
WHERE id = ? AND stock > 0;

Kiểm tra số dòng bị ảnh hưởng: bằng 0 nghĩa là hết hàng.

Hay sai: dùng synchronized trong code Java. Nó vô dụng khi chạy nhiều instance, và cũng không bảo vệ được dữ liệu ở DB.

Chọn điểm yếu thật, không chí mạng với vị trí, và cho thấy bạn đang cải thiện.

Cấu trúc: điểm yếu, ảnh hưởng đã gặp, việc bạn đang làm để khắc phục, tiến bộ đến nay.

Câu mẫu: "Trước đây em hay ngại hỏi khi bị kẹt, tự loay hoay quá lâu, có lần làm trễ task. Giờ em tự đặt giới hạn: kẹt quá một hai giờ mà không có hướng thì em hỏi đồng đội, kèm những gì đã thử. Từ khi làm vậy em xong việc đúng hạn hơn và học được nhanh hơn từ người khác."

Ví dụ khác có thể dùng: chưa quen nói trước đám đông, tiếng Anh nói chưa trôi chảy, hay ôm việc.

Hay sai: "Điểm yếu của em là quá cầu toàn" (nghe như né câu hỏi), hoặc nêu điểm yếu là kỹ năng cốt lõi của vị trí.