Thư Viện Câu Hỏi Phỏng Vấn

Bản chất vấn đề

Việc sử dụng từ khóa Synchronized trên toàn bộ phương thức (Method-level synchronization) tạo ra một 'điểm nghẽn' (bottleneck) lớn. Khi một luồng đang thực thi phương thức, tất cả các luồng khác muốn truy cập vào bất kỳ thành phần nào của đối tượng đó đều phải chờ đợi, ngay cả khi chúng truy cập vào các vùng dữ liệu không liên quan đến nhau.

Bản chất của Race Condition

Race Condition (Điều kiện tranh chấp) xảy ra khi hai hoặc nhiều luồng cùng đọc và ghi dữ liệu chia sẻ mà không có cơ chế đồng bộ hóa, dẫn đến kết quả phụ thuộc vào thứ tự thực thi của các luồng (thứ tự này không thể đoán trước do hệ điều hành quản lý).

Định nghĩa Context Switching

Context Switching (Chuyển đổi ngữ cảnh) là quá trình hệ điều hành lưu lại trạng thái (Context, bao gồm giá trị thanh ghi, bộ đếm chương trình - Program Counter) của luồng đang chạy, và khôi phục trạng thái của luồng tiếp theo được lên lịch để chạy trên CPU.

Định nghĩa Callback Hell

Callback Hell (Địa ngục hàm gọi lại) là hiện tượng mã nguồn trở nên lồng nhau quá nhiều tầng các hàm callback (bất đồng bộ phụ thuộc lẫn nhau), tạo thành hình dạng giống kim tự tháp (Pyramid of Doom). Hiện tượng này thường xuất hiện khi xử lý các tác vụ tuần tự như: Kết nối DB -> Truy vấn dữ liệu -> Gọi API ngoài -> Xử lý file.

Bản chất của Context Switching

Context Switching (Chuyển đổi ngữ cảnh) là quá trình CPU lưu lại trạng thái (context) của một Thread hoặc Process đang chạy, sau đó khôi phục trạng thái của một Thread hoặc Process khác để tiếp tục thực thi. Quá trình này bao gồm việc lưu các thanh ghi của CPU, con trỏ lệnh (Program Counter), và các thông tin quản lý bộ nhớ đếm.

1. Phân biệt khái niệm

• CPU-bound Task (Tác vụ nặng về tính toán): Là các tác vụ đòi hỏi sức mạnh xử lý thuần túy của CPU như mã hóa dữ liệu, nén file, xử lý thuật toán phức tạp, xử lý ảnh. Thời gian hoàn thành phụ thuộc trực tiếp vào tốc độ và số lượng Core của CPU.
• I/O-bound Task (Tác vụ chờ đợi vào Input/Output): Là các tác vụ mà ứng dụng phải dành phần lớn thời gian để chờ đợi phản hồi từ các hệ thống bên ngoài như truy vấn Database, gọi HTTP API, đọc ghi file từ ổ cứng, hoặc nhận dữ liệu qua mạng.

2. Mô hình xử lý tối ưu

• Đối với CPU-bound Task:
  • Mô hình tối ưu là Multithreading với số lượng Thread xấp xỉ bằng số lượng Core vật lý của CPU.
  • Việc tạo nhiều Thread hơn số Core sẽ gây ra hiện tượng Context Switching lãng phí vì CPU lúc nào cũng ở trạng thái 100% công suất.
• Đối với I/O-bound Task:
  • Mô hình tối ưu là Asynchronous / Event-driven Non-blocking (ví dụ như Node.js Event Loop, Java NIO, hoặc Async/Await trong C#).
  • Thay vì block một Thread trong lúc chờ đợi I/O phản hồi, hệ thống sẽ giải phóng Thread đó để xử lý các request khác, và chỉ quay lại xử lý tiếp tục khi có sự kiện I/O hoàn thành.

3. Kinh nghiệm thực chiến

Khi thiết kế API backend, Junior cần phân loại rõ ràng bản chất của từng API. Các API thực hiện báo cáo thống kê phức tạp (CPU-bound) nên được tách biệt ra các Worker riêng hoặc sử dụng Queue (như RabbitMQ, Kafka) để xử lý nền, tránh làm nghẽn Main Thread phục vụ các request HTTP thông thường.

1. Bản chất của Thread Interference

Thread Interference xảy ra khi hai hoặc nhiều luồng cùng truy cập và thực hiện thao tác ghi (write) lên cùng một biến hoặc vùng nhớ chia sẻ mà không có cơ chế kiểm soát đồng bộ. Do các thao tác tăng giá trị (ví dụ: count++) không phải là Atomic (nguyên tử) mà bao gồm 3 bước riêng biệt:

1. Phân biệt khái niệm

• Thread Interference (Can thiệp luồng): Là một dạng lỗi cụ thể xảy ra khi các luồng ghi đè dữ liệu lẫn nhau do thiếu tính nguyên tử (Atomicity).
• Race Condition (Điều kiện tranh chấp): Là một lỗi logic tổng quát hơn, xảy ra khi tính đúng đắn của chương trình phụ thuộc vào thứ tự thực thi ngẫu nhiên hoặc thời gian chạy của các luồng (Timing/Ordering). Mọi Thread Interference đều là Race Condition, nhưng không phải Race Condition nào cũng là Thread Interference (có thể xảy ra ngay cả khi chỉ đọc dữ liệu nhưng sai thứ tự thời gian).

2. Ví dụ thực tế trong hệ thống Enterprise

Xét tính năng trừ tiền trong ví điện tử của người dùng:

1. Bản chất của Callback Hell

Callback Hell (còn gọi là Pyramid of Doom) xảy ra trong lập trình bất đồng bộ khi các hàm callback được lồng vào nhau quá sâu (Nested Callbacks). Hiện tượng này thường xuất hiện khi phải thực hiện chuỗi các tác vụ I/O tuần tự bất đồng bộ (Ví dụ: Đọc file -> Gửi HTTP Request -> Lưu vào Database -> Gửi Email).

Phân tích bản chất

• Multithreading: Hệ điều hành cấp phát nhiều luồng (thread) để thực thi các tác vụ song song. Mỗi luồng có stack riêng, tiêu tốn tài nguyên bộ nhớ (RAM) và yêu cầu cơ chế Context Switching phức tạp.
• Asynchronous Programming: Dựa trên cơ chế Event Loop (như trong Node.js) hoặc Task-based (như trong C#/.NET). Nó không tạo luồng mới mà tận dụng I/O non-blocking để xử lý nhiều yêu cầu trên một luồng duy nhất.

Khi nào nên sử dụng?

• Multithreading: Phù hợp cho các tác vụ CPU-bound (xử lý ảnh, mã hóa, tính toán phức tạp) để tận dụng tối đa đa nhân CPU.
• Asynchronous: Phù hợp cho các tác vụ I/O-bound (truy vấn database, gọi API bên thứ ba, đọc ghi file) để tăng khả năng chịu tải (throughput) mà không làm treo hệ thống.

Lưu ý thực chiến

Sử dụng sai mô hình dẫn đến lãng phí tài nguyên hoặc gây nghẽn Event Loop, làm giảm hiệu năng hệ thống nghiêm trọng.

Bản chất vấn đề

Biến toàn cục chia sẻ vùng nhớ chung giữa các luồng. Khi nhiều luồng cùng đọc và ghi vào một biến tại cùng một thời điểm, hiện tượng Data Race xảy ra, dẫn đến dữ liệu bị sai lệch hoặc crash ứng dụng.

Chiến lược xử lý

Để giải quyết bài toán này, kiến trúc Enterprise thường áp dụng các mẫu thiết kế sau:

Tại sao tạo mới luồng là Anti-pattern?

• Chi phí khởi tạo: Việc cấp phát bộ nhớ và khởi tạo luồng tốn kém tài nguyên CPU và thời gian.
• Rủi ro hệ thống: Nếu số lượng request quá lớn, việc tạo vô hạn luồng sẽ gây ra lỗi OutOfMemoryException hoặc làm kiệt quệ tài nguyên hệ thống (Thread Exhaustion).

Cơ chế Thread Pool

• Thread Pool duy trì một tập hợp các luồng đã được khởi tạo sẵn. Khi có tác vụ mới, hệ thống sẽ lấy một luồng từ pool để xử lý, sau đó trả lại luồng đó vào pool thay vì hủy bỏ.
• Điều này giúp tái sử dụng tài nguyên và giới hạn số lượng luồng tối đa, bảo vệ hệ thống khỏi các cuộc tấn công từ chối dịch vụ (DoS) do quá tải request.

Lời khuyên

Luôn cấu hình kích thước Thread Pool phù hợp với tài nguyên phần cứng (CPU cores) và đặc thù của ứng dụng.

Phân tích

• Blocking: Khi một luồng thực hiện tác vụ I/O, nó sẽ đứng yên chờ đợi kết quả. Trong thời gian đó, luồng này không thể xử lý bất kỳ yêu cầu nào khác. Nếu tất cả luồng trong pool đều bị block, server sẽ không thể tiếp nhận thêm request mới.
• Non-blocking: Luồng gửi yêu cầu I/O và ngay lập tức quay lại xử lý các tác vụ khác. Khi I/O hoàn tất, một callback hoặc sự kiện sẽ thông báo để xử lý kết quả.

Tác động hiệu năng

• Blocking dẫn đến hiện tượng 'Thread Starvation' (đói luồng), làm tăng thời gian phản hồi (latency) và giảm khả năng mở rộng (scalability).
• Non-blocking giúp server xử lý hàng ngàn kết nối đồng thời với số lượng luồng tối thiểu, tối ưu hóa việc sử dụng tài nguyên phần cứng.

Lưu ý

Lập trình Non-blocking thường khó debug hơn do luồng xử lý không tuần tự, cần nắm vững cơ chế Promise/Async-Await để quản lý luồng dữ liệu.

Bản chất của Distributed Lock

Trong một hệ thống Microservices, các instance chạy trên các tiến trình hoặc server khác nhau, do đó chúng không chia sẻ chung bộ nhớ (Memory Space). Các cơ chế Lock nội bộ như synchronized trong Java hay lock trong C# chỉ có tác dụng trong phạm vi một tiến trình duy nhất.