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

Khái niệm Race Condition

Race Condition xảy ra khi kết quả của một chương trình phụ thuộc vào thứ tự hoặc thời điểm thực thi của các luồng (threads). Khi nhiều luồng cùng truy cập và thay đổi dữ liệu dùng chung (shared data) mà không có cơ chế kiểm soát, trạng thái của dữ liệu sẽ trở nên không nhất quán.

Bản chất vấn đề

Việc tạo mới một Thread (new Thread()) là một thao tác tốn kém tài nguyên hệ thống (CPU và bộ nhớ cho Stack). Nếu ứng dụng tạo quá nhiều luồng, hệ thống sẽ bị quá tải (Overhead) và dẫn đến hiện tượng OutOfMemoryError.

Blocking I/O

Trong mô hình Blocking, khi một luồng thực hiện tác vụ I/O (như đọc file hoặc gọi API), luồng đó sẽ bị tạm dừng (block) và không thể làm việc khác cho đến khi tác vụ hoàn tất. Điều này gây lãng phí tài nguyên luồng.

Khái niệm Context Switching

Context Switching là quá trình hệ điều hành lưu lại trạng thái (context) của một tiến trình hoặc luồng đang chạy, sau đó tải trạng thái của một tiến trình hoặc luồng khác để tiếp tục thực thi. Trạng thái này bao gồm thanh ghi CPU, bộ đếm chương trình và các thông tin bộ nhớ.

Bản chất vấn đề

Do cơ chế tối ưu hóa của CPU và trình biên dịch, các luồng thường lưu trữ giá trị biến vào bộ nhớ đệm (Cache) của CPU thay vì ghi trực tiếp vào bộ nhớ chính (Main Memory). Điều này khiến các luồng khác không cập nhật được giá trị mới nhất.

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

Việc sử dụng từ khóa Synchronized yêu cầu cơ chế khóa (locking) ở cấp độ hệ điều hành, dẫn đến việc các luồng phải tạm dừng (blocking) và chờ đợi, gây ra chi phí Context Switching lớn. Ngược lại, Atomic Variables sử dụng cơ chế Non-blocking thông qua chỉ thị CPU gọi là Compare-And-Swap (CAS).

Khái niệm

Future hoặc Promise đại diện cho một giá trị chưa tồn tại ngay lập tức nhưng sẽ có trong tương lai khi một tác vụ bất đồng bộ hoàn thành. Thay vì chặn luồng chính (Main Thread) để chờ kết quả, hệ thống sẽ tiếp tục thực thi các tác vụ khác.

Định nghĩa

Busy Waiting là kỹ thuật trong đó một luồng liên tục kiểm tra một điều kiện trong vòng lặp vô tận cho đến khi điều kiện đó thay đổi. Luồng không bao giờ nhường quyền điều khiển cho CPU mà liên tục tiêu tốn tài nguyên tính toán.

Phân tích cơ chế

1. Pessimistic Locking: Khóa bản ghi ngay khi bắt đầu đọc, ngăn cản các luồng khác truy cập cho đến khi giao dịch kết thúc. Phù hợp với môi trường tranh chấp dữ liệu cực cao.
2. Optimistic Locking: Không khóa dữ liệu. Khi cập nhật, hệ thống kiểm tra xem dữ liệu có bị thay đổi bởi luồng khác không (thông qua version hoặc timestamp). Nếu có, giao dịch sẽ bị từ chối hoặc thử lại.

Tại sao chọn Optimistic Locking

• Tăng khả năng mở rộng (Scalability): Không gây nghẽn cổ chai do không giữ khóa lâu.
• Phù hợp với kiến trúc phân tán: Trong Microservices, việc giữ khóa trên nhiều service là rất khó và dễ gây Deadlock.

Lưu ý thực chiến

Sử dụng Optimistic Locking khi tần suất xảy ra xung đột dữ liệu thấp. Nếu hệ thống có tần suất ghi cực cao vào cùng một bản ghi, hãy cân nhắc lại thiết kế kiến trúc thay vì chỉ dựa vào cơ chế khóa.

Định nghĩa

Một Class được coi là Thread-safe nếu nó hoạt động đúng đắn ngay cả khi được truy cập đồng thời bởi nhiều luồng mà không yêu cầu thêm bất kỳ sự phối hợp nào từ phía người sử dụng Class đó.

Thread-safe là thuộc tính của mã nguồn đảm bảo rằng khi nhiều luồng cùng thực thi, trạng thái của chương trình vẫn đúng đắn. Reentrancy là một khái niệm cụ thể hơn: một hàm được gọi là Reentrant nếu nó có thể bị ngắt quãng giữa chừng và được gọi lại (ví dụ bởi một tín hiệu hoặc một luồng khác) mà không làm hỏng dữ liệu. Một hàm Reentrant không sử dụng các biến toàn cục hoặc tài nguyên chia sẻ không được bảo vệ. Sự khác biệt chính: Một hàm Thread-safe có thể sử dụng khóa (Lock) để bảo vệ dữ liệu, nhưng hàm Reentrant không cần khóa vì nó không chia sẻ trạng thái. Trong lập trình Enterprise, viết code Reentrant giúp giảm thiểu độ phức tạp của việc quản lý trạng thái và tránh các lỗi tranh chấp dữ liệu khó phát hiện.

Thread Local Storage (TLS) là một cơ chế lưu trữ dữ liệu mà mỗi luồng sở hữu một bản sao riêng biệt của biến đó. Khi một luồng truy cập vào biến ThreadLocal, nó không ảnh hưởng đến các luồng khác. Điều này cực kỳ hữu ích trong các ứng dụng Enterprise như: 1. Quản lý thông tin xác thực (User Context) trong các Request-per-thread model. 2. Quản lý kết nối Database (Transaction Context). Bằng cách sử dụng TLS, lập trình viên loại bỏ hoàn toàn nhu cầu sử dụng Mutex hay Synchronized cho các biến này, từ đó tăng hiệu năng hệ thống đáng kể. Lưu ý: Cần phải dọn dẹp (remove) dữ liệu trong ThreadLocal sau khi xử lý xong để tránh Memory Leak, đặc biệt khi sử dụng Thread Pool.

Livelock xảy ra khi hai hoặc nhiều luồng liên tục thay đổi trạng thái để đáp ứng với nhau nhưng không luồng nào có thể tiến triển công việc. Khác với Deadlock (nơi các luồng đứng yên chờ đợi tài nguyên), trong Livelock, các luồng vẫn đang hoạt động nhưng bị mắc kẹt trong một vòng lặp vô tận của việc phản ứng lại hành động của nhau. Ví dụ thực tế: Hai người đi ngược chiều nhau trong hành lang hẹp, cả hai cùng né sang trái rồi cùng né sang phải để tránh nhau, kết quả là cả hai vẫn chặn đường nhau. Cách khắc phục: Thêm yếu tố ngẫu nhiên (random backoff) vào logic xử lý để phá vỡ sự đồng bộ trong phản ứng của các luồng.

Immutable Objects là các đối tượng mà trạng thái không thể thay đổi sau khi khởi tạo. Trong môi trường đa luồng, vấn đề lớn nhất là Race Condition khi nhiều luồng cùng đọc và ghi vào một đối tượng. Nếu đối tượng là Immutable, nó mặc định là Thread-safe vì không có luồng nào có thể thay đổi trạng thái của nó. Lợi ích: 1. Không cần sử dụng khóa (Lock-free), giúp tăng hiệu năng. 2. Dễ dàng chia sẻ giữa các luồng mà không lo bị thay đổi ngoài ý muốn. 3. Giảm thiểu lỗi logic phức tạp. Trong các hệ thống Enterprise, việc ưu tiên sử dụng các cấu trúc dữ liệu bất biến (như các thư viện Immutable trong Java hoặc các kiểu dữ liệu Read-only trong C#) giúp code trở nên dễ kiểm thử và bảo trì hơn rất nhiều.

Khái niệm Thread Starvation

Thread Starvation (hiện tượng đói luồng) xảy ra khi một hoặc nhiều luồng không bao giờ nhận được đủ tài nguyên CPU hoặc quyền truy cập vào các tài nguyên chia sẻ (như Lock hoặc Monitor) để hoàn thành tác vụ của chúng. Điều này khiến luồng bị treo vô thời hạn mặc dù hệ thống vẫn đang hoạt động.