Caspeco - Senior Fullstack Developer (.NET/Java, JS)

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.

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).

Thu thập số liệu trước, đoán sau: xem metrics, chụp dump hoặc trace, rồi phân tích.

1. Theo dõi bằng dotnet-counters: heap size, số lần GC từng gen, thread pool queue length, exception rate.
2. Leak bộ nhớ: chụp hai lần dotnet-gcdump hoặc dotnet-dump cách nhau một khoảng, so sánh loại object tăng và tìm ai đang giữ tham chiếu.
3. CPU cao hoặc treo: dotnet-trace để xem hot path; thread pool queue tăng thường do sync-over-async.

Nguyên nhân hay gặp: event handler không gỡ đăng ký, cache static không giới hạn kích thước, giữ DbContext quá lâu, regex hoặc serialize lặp lại trong vòng lặp nóng.

Người phỏng vấn muốn nghe: một ca thực tế bạn từng xử lý, công cụ đã dùng và kết quả trước/sau.

Hai hướng chính: optimistic concurrency (phát hiện xung đột khi lưu) và pessimistic (khoá trước khi sửa).

Optimistic với EF Core: đánh dấu một cột làm concurrency token, EF thêm điều kiện so sánh vào UPDATE và ném DbUpdateConcurrencyException nếu không có dòng nào bị cập nhật.

public class Product {
    public int Stock { get; set; }
    [Timestamp] public byte[] RowVersion { get; set; } = [];
}

• Bắt exception, tải lại dữ liệu, rồi retry hoặc báo người dùng.
• PostgreSQL thường dùng cột hệ thống xmin làm token.
• Trường hợp đơn giản như trừ tồn kho có thể dùng một câu ExecuteUpdateAsync atomic kèm điều kiện Stock >= qty.

Người phỏng vấn muốn nghe: bạn cân nhắc mức độ tranh chấp: thấp thì optimistic, cao và nghiệp vụ quan trọng thì khoá hoặc đưa vào hàng đợi.

Memory leak ở frontend thường do thứ gì đó vẫn giữ tham chiếu đến object đáng lẽ đã bỏ đi, nhất là trong SPA vì trang không bao giờ tải lại.

Nguyên nhân hay gặp:

• addEventListener trên window/document mà không gỡ khi component bị huỷ.
• setInterval, subscription (WebSocket, store) không huỷ.
• DOM đã bị gỡ khỏi trang nhưng vẫn được biến JS giữ lại (detached DOM).
• Cache hoặc mảng toàn cục chỉ tăng không giảm.

Cách điều tra với Chrome DevTools:

1. Tab Memory: chụp heap snapshot, thực hiện thao tác vài lần, chụp lại, so sánh phần tăng thêm.
2. Lọc "Detached" để tìm DOM bị giữ, xem chuỗi retainers để biết ai đang giữ.
3. Tab Performance bật Memory để xem heap có giảm sau GC không.

Người phỏng vấn muốn nghe: mỗi tài nguyên đăng ký đều có chỗ huỷ tương ứng (cleanup của effect, ngOnDestroy, onUnmounted, AbortController).

Đ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.

IoC container của Spring tạo và quản lý các bean, rồi "tiêm" phụ thuộc vào class cần dùng, thay vì class tự new. Nhờ vậy code ít phụ thuộc cứng, dễ thay implementation và dễ test.

Constructor injection được khuyên dùng vì:

• Field có thể là final, object luôn ở trạng thái đầy đủ sau khi tạo.
• Test unit không cần Spring: chỉ cần new OrderService(mockRepo).
• Constructor quá nhiều tham số là dấu hiệu class đang ôm nhiều việc.
• Class chỉ có một constructor thì không cần ghi @Autowired.

Nên nói thêm về scope: mặc định bean là singleton (một instance cho cả context), ngoài ra có prototype, request, session.

Hay sai: để state thay đổi được (ví dụ biến đếm, list) trong bean singleton. Nhiều request chạy song song sẽ dùng chung và gây race condition.

Chọn một hai điểm mạnh liên quan tới vị trí, và chứng minh bằng ví dụ thật, không liệt kê tính từ.

Cấu trúc: điểm mạnh, ví dụ ngắn, kết quả, liên hệ với công việc mới.

Câu mẫu: "Điểm mạnh của em là chủ động tìm nguyên nhân gốc. Ở dự án trước, hệ thống thỉnh thoảng bị timeout mà không ai tái hiện được. Em tự đọc log, thêm theo dõi ở các điểm nghi ngờ và tìm ra một truy vấn bị khoá bảng vào giờ cao điểm. Sau khi sửa, lỗi đó không còn xuất hiện. Em nghĩ điều này hữu ích với vị trí bên mình vì hệ thống có lượng truy cập lớn."

Hay sai: "Em chăm chỉ, ham học hỏi, chịu được áp lực" mà không có ví dụ. Ai cũng nói vậy nên không đọng lại gì.