Concurrency

Trang này chứa các mẹo và tài nguyên để chuẩn bị cho các cuộc phỏng vấn đồng thời.

Sự khác biệt giữa Tiến trình (Process) và Luồng (Thread) là gì?

Cả tiến trình và luồng đều là các đơn vị đồng thời, nhưng chúng có một sự khác biệt cơ bản: các tiến trình không chia sẻ bộ nhớ chung, trong khi các luồng thì có.

Từ quan điểm của hệ điều hành, một tiến trình là một phần mềm độc lập chạy trong không gian bộ nhớ ảo riêng của nó. Bất kỳ hệ điều hành đa nhiệm nào (nghĩa là hầu hết mọi hệ điều hành hiện đại) đều phải phân tách các tiến trình trong bộ nhớ để một tiến trình bị lỗi không kéo theo tất cả các tiến trình khác bằng cách làm xáo trộn bộ nhớ chung.

Do đó, các tiến trình thường được cô lập và chúng hợp tác thông qua giao tiếp giữa các tiến trình (inter-process communication), được hệ điều hành định nghĩa như một loại API trung gian.

Ngược lại, một luồng là một phần của ứng dụng chia sẻ bộ nhớ chung với các luồng khác của cùng một ứng dụng. Việc sử dụng bộ nhớ chung cho phép giảm bớt nhiều chi phí phát sinh, thiết kế các luồng để hợp tác và trao đổi dữ liệu giữa chúng nhanh hơn nhiều.

---

Làm thế nào để tạo một thể hiện luồng và chạy nó?

Để tạo một thể hiện của luồng, bạn có hai tùy chọn. Đầu tiên, truyền một thể hiện Runnable vào hàm tạo của nó và gọi start(). Runnable là một giao diện hàm (functional interface), vì vậy nó có thể được truyền dưới dạng một biểu thức lambda:

Thread thread1 = new Thread(() ->
  System.out.println("Hello World từ Runnable!"));
thread1.start();

Thread cũng triển khai Runnable, vì vậy một cách khác để khởi động một luồng là tạo một lớp con ẩn danh, ghi đè phương thức run() của nó và sau đó gọi start():

Thread thread2 = new Thread() {
    @Override
    public void run() {
        System.out.println("Hello World từ lớp con!");
    }
};
thread2.start();

---

Mô tả các trạng thái khác nhau của một Luồng và khi nào thì các chuyển đổi trạng thái xảy ra.

Trạng thái của một Luồng có thể được kiểm tra bằng phương thức Thread.getState(). Các trạng thái khác nhau của một Luồng được mô tả trong enum Thread.State. Chúng là:

• NEW (MỚI) — một thể hiện Luồng mới chưa được khởi động thông qua Thread.start().

• RUNNABLE (CÓ THỂ CHẠY) — một luồng đang chạy. Nó được gọi là "có thể chạy" vì tại bất kỳ thời điểm nào nó có thể đang chạy hoặc chờ lượng thời gian tiếp theo từ bộ lập lịch luồng. Một luồng NEW chuyển sang trạng thái RUNNABLE khi bạn gọi Thread.start() trên nó.

• BLOCKED (BỊ CHẶN) — một luồng đang chạy bị chặn nếu nó cần vào một phần được đồng bộ hóa nhưng không thể thực hiện được do một luồng khác đang giữ monitor của phần này.

• WAITING (ĐANG CHỜ) — một luồng chuyển sang trạng thái này nếu nó chờ một luồng khác thực hiện một hành động cụ thể. Ví dụ: một luồng chuyển sang trạng thái này khi gọi phương thức Object.wait() trên một monitor mà nó đang giữ, hoặc phương thức Thread.join() trên một luồng khác.

• TIMED_WAITING (ĐANG CHỜ CÓ THỜI GIAN) — tương tự như trên, nhưng một luồng chuyển sang trạng thái này sau khi gọi các phiên bản có thời gian của Thread.sleep(), Object.wait(), Thread.join() và một số phương thức khác.

• TERMINATED (ĐÃ KẾT THÚC) — một luồng đã hoàn thành việc thực thi phương thức Runnable.run() của nó và đã kết thúc.

---

Sự khác biệt giữa giao diện Runnable và Callable là gì? Chúng được sử dụng như thế nào?

Giao diện Runnable có một phương thức duy nhất là run. Nó đại diện cho một đơn vị tính toán cần được chạy trong một luồng riêng biệt. Giao diện Runnable không cho phép phương thức này trả về giá trị hoặc ném ra các ngoại lệ không được kiểm tra (unchecked exceptions).

Giao diện Callable có một phương thức duy nhất là call và đại diện cho một tác vụ có giá trị. Đó là lý do tại sao phương thức call trả về một giá trị. Nó cũng có thể ném ra các ngoại lệ. Callable thường được sử dụng trong các thể hiện ExecutorService để khởi động một tác vụ không đồng bộ và sau đó gọi thể hiện Future được trả về để lấy giá trị của nó.

---

Luồng Daemon là gì, các trường hợp sử dụng của nó là gì? Làm thế nào để tạo một Luồng Daemon?

Luồng Daemon là một luồng không ngăn JVM thoát. Khi tất cả các luồng không phải daemon kết thúc, JVM sẽ đơn giản bỏ qua tất cả các luồng daemon còn lại. Luồng daemon thường được sử dụng để thực hiện một số tác vụ hỗ trợ hoặc dịch vụ cho các luồng khác, nhưng bạn nên lưu ý rằng chúng có thể bị bỏ rơi bất kỳ lúc nào.

Để khởi động một luồng dưới dạng daemon, bạn nên sử dụng phương thức setDaemon() trước khi gọi start():

Thread daemon = new Thread(()
  -> System.out.println("Xin chào từ daemon!"));
daemon.setDaemon(true);
daemon.start();

Điều thú vị là, nếu bạn chạy đoạn mã này như một phần của phương thức main(), thông báo có thể không được in. Điều này có thể xảy ra nếu luồng main() kết thúc trước khi daemon đến điểm in thông báo. Nói chung, bạn không nên thực hiện bất kỳ thao tác I/O nào trong các luồng daemon, vì chúng thậm chí sẽ không thể thực thi các khối finally của chúng và đóng tài nguyên nếu bị bỏ rơi.

---

Cờ ngắt (Interrupt Flag) của Luồng là gì? Làm thế nào để đặt và kiểm tra nó? Nó liên quan như thế nào đến ngoại lệ InterruptedException?

Cờ ngắt, hoặc trạng thái ngắt, là một cờ nội bộ của Luồng được đặt khi luồng bị ngắt. Để đặt nó, chỉ cần gọi thread.interrupt() trên đối tượng luồng.

Nếu một luồng hiện đang ở bên trong một trong các phương thức ném ra InterruptedException (ví dụ: wait, join, sleep, v.v.), thì phương thức này sẽ ngay lập tức ném ra InterruptedException. Luồng có thể xử lý ngoại lệ này theo logic riêng của nó.

Nếu một luồng không ở bên trong một phương thức như vậy và thread.interrupt() được gọi, thì không có gì đặc biệt xảy ra. Luồng có trách nhiệm kiểm tra định kỳ trạng thái ngắt bằng phương thức tĩnh Thread.interrupted() hoặc phương thức thể hiện isInterrupted(). Sự khác biệt giữa các phương thức này là phương thức tĩnh Thread.interrupted() xóa cờ ngắt, trong khi isInterrupted() thì không.

---

Executor và ExecutorService là gì? Sự khác biệt giữa các giao diện này là gì?

Executor và ExecutorService là hai giao diện liên quan của framework java.util.concurrent. Executor là một giao diện rất đơn giản với một phương thức execute duy nhất chấp nhận các thể hiện Runnable để thực thi. Trong hầu hết các trường hợp, đây là giao diện mà mã thực thi tác vụ của bạn nên phụ thuộc vào.

ExecutorService mở rộng giao diện Executor với nhiều phương thức để xử lý và kiểm tra vòng đời của một dịch vụ thực thi tác vụ đồng thời (chấm dứt tác vụ trong trường hợp tắt máy) và các phương thức để xử lý tác vụ không đồng bộ phức tạp hơn, bao gồm Futures.

Tóm lại:

• Executor:

  • Đơn giản hơn, chỉ có phương thức execute(Runnable command).

  • Chỉ chịu trách nhiệm thực thi các tác vụ Runnable.

  • Không cung cấp các phương tiện để quản lý vòng đời hoặc lấy kết quả của các tác vụ.

• ExecutorService:

  • Mở rộng Executor, cung cấp nhiều chức năng hơn.

  • Cho phép quản lý vòng đời của các tác vụ (ví dụ: tắt dịch vụ).

  • Hỗ trợ lấy kết quả của các tác vụ thông qua Future.

  • Cung cấp các phương thức để gửi các tác vụ Callable và Runnable.

---

Các triển khai có sẵn của ExecutorService trong thư viện chuẩn là gì?

Giao diện ExecutorService có ba triển khai tiêu chuẩn:

• ThreadPoolExecutor: Được sử dụng để thực thi các tác vụ bằng cách sử dụng một nhóm luồng. Khi một luồng hoàn thành việc thực thi tác vụ, nó sẽ quay trở lại nhóm. Nếu tất cả các luồng trong nhóm đều bận, thì tác vụ phải đợi đến lượt.

• ScheduledThreadPoolExecutor: Cho phép lên lịch thực thi tác vụ thay vì chạy ngay khi có luồng khả dụng. Nó cũng có thể lên lịch các tác vụ với tốc độ cố định hoặc độ trễ cố định.

• ForkJoinPool: Là một ExecutorService đặc biệt để xử lý các tác vụ thuật toán đệ quy. Nếu bạn sử dụng ThreadPoolExecutor thông thường cho một thuật toán đệ quy, bạn sẽ nhanh chóng thấy tất cả các luồng của mình đều bận chờ các cấp độ đệ quy thấp hơn hoàn thành. ForkJoinPool triển khai cái gọi là thuật toán "work-stealing" (ăn cắp công việc), cho phép nó sử dụng các luồng có sẵn hiệu quả hơn.

---

Mô hình Bộ nhớ Java (JMM) là gì? Mô tả mục đích và các ý tưởng cơ bản của nó.

Mô hình Bộ nhớ Java (Java Memory Model - JMM) là một phần của đặc tả ngôn ngữ Java được mô tả trong Chương 17.4. Nó chỉ định cách nhiều luồng truy cập bộ nhớ chung trong một ứng dụng Java đồng thời và cách các thay đổi dữ liệu của một luồng được hiển thị cho các luồng khác. Mặc dù khá ngắn gọn và súc tích, JMM có thể khó nắm bắt nếu không có nền tảng toán học vững chắc.

Sự cần thiết của mô hình bộ nhớ phát sinh từ thực tế là cách mã Java của bạn truy cập dữ liệu không phải là cách nó thực sự xảy ra ở các cấp độ thấp hơn. Các thao tác ghi và đọc bộ nhớ có thể được sắp xếp lại hoặc tối ưu hóa bởi trình biên dịch Java, trình biên dịch JIT và thậm chí cả CPU, miễn là kết quả quan sát được của các thao tác đọc và ghi này là giống nhau.

Điều này có thể dẫn đến các kết quả trái ngược với trực giác khi ứng dụng của bạn được mở rộng sang nhiều luồng, vì hầu hết các tối ưu hóa này đều tính đến một luồng thực thi duy nhất (các trình tối ưu hóa đa luồng vẫn cực kỳ khó triển khai). Một vấn đề lớn khác là bộ nhớ trong các hệ thống hiện đại là đa lớp: nhiều lõi của bộ xử lý có thể giữ một số dữ liệu chưa được xả trong bộ nhớ cache hoặc bộ đệm đọc/ghi của chúng, điều này cũng ảnh hưởng đến trạng thái của bộ nhớ được quan sát từ các lõi khác.

Tệ hơn nữa, sự tồn tại của các kiến trúc truy cập bộ nhớ khác nhau sẽ phá vỡ lời hứa "viết một lần, chạy mọi nơi" của Java. May mắn cho các lập trình viên, JMM chỉ định một số đảm bảo mà bạn có thể dựa vào khi thiết kế các ứng dụng đa luồng. Việc tuân thủ các đảm bảo này giúp lập trình viên viết mã đa luồng ổn định và có thể di chuyển giữa các kiến trúc khác nhau.

Các khái niệm chính của JMM là:

• Actions (Hành động): Đây là các hành động giữa các luồng có thể được thực thi bởi một luồng và được phát hiện bởi một luồng khác, chẳng hạn như đọc hoặc ghi biến, khóa/mở khóa monitor, v.v.

• Synchronization actions (Hành động đồng bộ hóa): Một tập hợp con nhất định của các hành động, chẳng hạn như đọc/ghi biến volatile hoặc khóa/mở khóa monitor.

• Program Order (PO - Thứ tự chương trình): Thứ tự tổng thể quan sát được của các hành động bên trong một luồng duy nhất.

• Synchronization Order (SO - Thứ tự đồng bộ hóa): Thứ tự tổng thể giữa tất cả các hành động đồng bộ hóa — nó phải nhất quán với Thứ tự chương trình, nghĩa là, nếu hai hành động đồng bộ hóa xảy ra trước sau trong PO, chúng xảy ra theo cùng thứ tự trong SO.

• synchronizes-with (SW - đồng bộ hóa với) quan hệ: Giữa một số hành động đồng bộ hóa nhất định, chẳng hạn như mở khóa monitor và khóa cùng monitor (trong một luồng khác hoặc cùng luồng).

• Happens-before Order (Thứ tự xảy ra trước): Kết hợp PO với SW (điều này được gọi là bao đóng bắc cầu trong lý thuyết tập hợp) để tạo ra một thứ tự bán phần của tất cả các hành động giữa các luồng. Nếu một hành động xảy ra trước một hành động khác, thì kết quả của hành động đầu tiên có thể được quan sát bởi hành động thứ hai (ví dụ: ghi một biến trong một luồng và đọc trong một luồng khác).

• Happens-before consistency (Tính nhất quán xảy ra trước): Một tập hợp các hành động là HB-nhất quán nếu mỗi thao tác đọc quan sát thao tác ghi cuối cùng vào vị trí đó theo thứ tự xảy ra trước hoặc một số thao tác ghi khác thông qua cuộc đua dữ liệu.

• Execution (Thực thi): Một tập hợp nhất định các hành động được sắp xếp và các quy tắc nhất quán giữa chúng.

Đối với một chương trình nhất định, chúng ta có thể quan sát nhiều lần thực thi khác nhau với các kết quả khác nhau. Nhưng nếu một chương trình được đồng bộ hóa đúng cách, thì tất cả các lần thực thi của nó đều xuất hiện tuần tự nhất quán, nghĩa là bạn có thể suy luận về chương trình đa luồng như một tập hợp các hành động xảy ra theo một số thứ tự tuần tự. Điều này giúp bạn tránh khỏi rắc rối khi suy nghĩ về việc sắp xếp lại, tối ưu hóa hoặc lưu dữ liệu vào bộ nhớ cache bên dưới.

---

Trường volatile là gì và JMM giữ những đảm bảo nào cho trường đó?

Một trường volatile có các thuộc tính đặc biệt theo Mô hình Bộ nhớ Java (JMM). Các thao tác đọc và ghi một biến volatile là các hành động đồng bộ hóa, có nghĩa là chúng có một thứ tự tổng thể (tất cả các luồng sẽ quan sát một thứ tự nhất quán của các hành động này). Một thao tác đọc một biến volatile được đảm bảo quan sát thao tác ghi cuối cùng vào biến đó, theo thứ tự này.

Nếu bạn có một trường được truy cập từ nhiều luồng, với ít nhất một luồng ghi vào nó, thì bạn nên cân nhắc việc biến nó thành volatile, nếu không, có rất ít đảm bảo về những gì một luồng cụ thể sẽ đọc từ trường này.

Một đảm bảo khác cho volatile là tính nguyên tử của việc ghi và đọc các giá trị 64 bit (long và double). Nếu không có bổ ngữ volatile, một thao tác đọc một trường như vậy có thể quan sát một giá trị được ghi một phần bởi một luồng khác.

---

Trong các thao tác sau, thao tác nào là nguyên tử?

• ghi vào một biến int không volatile;

• ghi vào một biến int volatile;

• ghi vào một biến long không volatile;

• ghi vào một biến long volatile;

• tăng một biến long volatile?

Trả lời:

• Việc ghi vào một biến int (32-bit) được đảm bảo là nguyên tử, dù nó có volatile hay không.

• Một biến long (64-bit) có thể được ghi trong hai bước riêng biệt, ví dụ: trên kiến trúc 32-bit, vì vậy theo mặc định, không có đảm bảo về tính nguyên tử. Tuy nhiên, nếu bạn chỉ định bổ ngữ volatile, một biến long được đảm bảo được truy cập một cách nguyên tử.

• Thao tác tăng (increment) thường được thực hiện trong nhiều bước (lấy giá trị, thay đổi nó và ghi lại), vì vậy nó không bao giờ được đảm bảo là nguyên tử, dù biến đó có volatile hay không. Nếu bạn cần triển khai tăng nguyên tử của một giá trị, bạn nên sử dụng các lớp AtomicInteger, AtomicLong, v.v.

---

JMM giữ những đảm bảo đặc biệt nào cho các trường final của một lớp?

Về cơ bản, JVM đảm bảo rằng các trường final của một lớp sẽ được khởi tạo trước khi bất kỳ luồng nào nắm giữ đối tượng đó. Nếu không có sự đảm bảo này, một tham chiếu đến một đối tượng có thể được xuất bản, tức là trở nên hiển thị, cho một luồng khác trước khi tất cả các trường của đối tượng này được khởi tạo, do sắp xếp lại hoặc các tối ưu hóa khác. Điều này có thể gây ra truy cập tranh đua (racy access) vào các trường này.

Đó là lý do tại sao, khi tạo một đối tượng bất biến (immutable), bạn luôn nên đặt tất cả các trường của nó là final, ngay cả khi chúng không thể truy cập được thông qua các phương thức getter.

---

Ý nghĩa của từ khóa synchronized trong định nghĩa của một phương thức là gì? của một phương thức tĩnh? trước một khối lệnh?

• synchronized trước một khối lệnh:

  • Điều này có nghĩa là bất kỳ luồng nào vào khối lệnh này đều phải giành quyền sở hữu monitor (đối tượng trong ngoặc đơn). Nếu monitor đã được một luồng khác giành quyền sở hữu, luồng trước đó sẽ chuyển sang trạng thái BLOCKED và đợi cho đến khi monitor được giải phóng.

  synchronized(object) {
      // ...
  }

• Phương thức thể hiện synchronized:

  • Có ngữ nghĩa tương tự, nhưng chính thể hiện đó đóng vai trò là monitor.

  synchronized void instanceMethod() {
      // ...
  }

• Phương thức tĩnh synchronized:

  • Monitor là đối tượng Class đại diện cho lớp khai báo.

  static synchronized void staticMethod() {
      // ...
  }

Tóm lại, từ khóa synchronized đảm bảo rằng chỉ một luồng có thể thực thi một khối mã hoặc phương thức cụ thể tại một thời điểm. Điều này ngăn chặn các điều kiện đua và đảm bảo tính nhất quán của dữ liệu.

---

Nếu hai luồng gọi một phương thức synchronized trên các thể hiện đối tượng khác nhau đồng thời, một trong các luồng này có thể bị chặn không? Điều gì xảy ra nếu phương thức đó là tĩnh?

• Phương thức thể hiện:

  • Nếu phương thức là một phương thức thể hiện (instance method), thì chính thể hiện đó hoạt động như một monitor cho phương thức.

  • Hai luồng gọi phương thức trên các thể hiện khác nhau sẽ giành quyền sở hữu các monitor khác nhau.

  • Do đó, không có luồng nào bị chặn.

• Phương thức tĩnh:

  • Nếu phương thức là phương thức tĩnh (static method), thì monitor là đối tượng Class.

  • Đối với cả hai luồng, monitor là giống nhau.

  • Do đó, một trong số chúng có thể sẽ bị chặn và đợi luồng kia thoát khỏi phương thức synchronized.

---

Mục đích của các phương thức wait, notify và notifyAll của lớp Object là gì?

Một luồng sở hữu monitor của đối tượng (ví dụ: một luồng đã vào một phần synchronized được bảo vệ bởi đối tượng) có thể gọi object.wait() để tạm thời giải phóng monitor và cho các luồng khác cơ hội giành quyền sở hữu monitor. Điều này có thể được thực hiện, ví dụ, để chờ một điều kiện nhất định.

Khi một luồng khác giành quyền sở hữu monitor thực hiện điều kiện, nó có thể gọi object.notify() hoặc object.notifyAll() và giải phóng monitor. Phương thức notify đánh thức một luồng duy nhất trong trạng thái chờ, và phương thức notifyAll đánh thức tất cả các luồng đang chờ monitor này, và tất cả chúng cạnh tranh để giành lại khóa.

Triển khai BlockingQueue sau đây cho thấy cách nhiều luồng làm việc cùng nhau thông qua mẫu wait-notify. Nếu chúng ta đặt một phần tử vào một hàng đợi trống, tất cả các luồng đang chờ trong phương thức take sẽ thức dậy và cố gắng nhận giá trị. Nếu chúng ta đặt một phần tử vào một hàng đợi đầy, phương thức put sẽ đợi cuộc gọi đến phương thức get. Phương thức get loại bỏ một phần tử và thông báo cho các luồng đang chờ trong phương thức put rằng hàng đợi có một chỗ trống cho một mục mới.

public class BlockingQueue<T> {

    private List<T> queue = new LinkedList<T>();

    private int limit = 10;

    public synchronized void put(T item) {
        while (queue.size() == limit) {
            try {
                wait();
            } catch (InterruptedException e) {}
        }
        if (queue.isEmpty()) {
            notifyAll();
        }
        queue.add(item);
    }

    public synchronized T take() throws InterruptedException {
        while (queue.isEmpty()) {
            try {
                wait();
            } catch (InterruptedException e) {}
        }
        if (queue.size() == limit) {
            notifyAll();
        }
        return queue.remove(0);
    }
}

Tóm lại:

• wait(): Giải phóng monitor và đưa luồng vào trạng thái chờ.

• notify(): Đánh thức một luồng duy nhất đang chờ monitor.

• notifyAll(): Đánh thức tất cả các luồng đang chờ monitor.

---

Mô tả các điều kiện của Deadlock, Livelock và Starvation. Mô tả các nguyên nhân có thể gây ra những điều kiện này.

1. Deadlock:

• Mô tả:

  • Deadlock xảy ra khi một nhóm các luồng không thể tiến triển vì mỗi luồng trong nhóm cần giành quyền sở hữu một số tài nguyên đã được một luồng khác trong nhóm giành quyền sở hữu.

  • Tình huống đơn giản nhất là khi hai luồng cần khóa cả hai tài nguyên để tiến triển, tài nguyên đầu tiên đã bị một luồng khóa và tài nguyên thứ hai bị luồng kia khóa. Những luồng này sẽ không bao giờ giành được khóa cho cả hai tài nguyên và do đó sẽ không bao giờ tiến triển.

• Nguyên nhân:

  • Mutual exclusion (Loại trừ lẫn nhau): Tài nguyên chỉ có thể được một luồng sử dụng tại một thời điểm.

  • Hold and wait (Giữ và chờ): Một luồng giữ một tài nguyên trong khi chờ đợi một tài nguyên khác.

  • No preemption (Không thu hồi): Tài nguyên không thể bị thu hồi khỏi một luồng đang giữ nó.

  • Circular wait (Chờ đợi vòng tròn): Một chuỗi các luồng đang chờ tài nguyên được giữ bởi luồng tiếp theo trong chuỗi.

2. Livelock:

• Mô tả:

  • Livelock là trường hợp nhiều luồng phản ứng với các điều kiện hoặc sự kiện do chính chúng tạo ra.

  • Một sự kiện xảy ra trong một luồng và phải được xử lý bởi một luồng khác. Trong quá trình xử lý này, một sự kiện mới xảy ra cần được xử lý trong luồng đầu tiên, v.v.

  • Những luồng như vậy vẫn hoạt động và không bị chặn, nhưng vẫn không tiến triển vì chúng làm quá tải lẫn nhau bằng công việc vô ích.

• Nguyên nhân:

  • Các luồng liên tục cố gắng phản ứng với trạng thái của nhau, dẫn đến một vòng lặp vô tận của các hành động không hiệu quả.

  • Ví dụ hai luồng đang cố gắng lấy hai khóa, nếu chúng phát hiện thấy khóa đang bị luồng kia giữ, thay vì chờ, chúng lại nhả khóa mà chúng đang giữ để luồng kia có thể lấy. sau đó lại cùng nhau cố gắng lấy khóa và lại nhả ra.

3. Starvation:

• Mô tả:

  • Starvation là trường hợp một luồng không thể giành được tài nguyên vì các luồng khác (hoặc luồng) chiếm giữ nó quá lâu hoặc có mức độ ưu tiên cao hơn.

  • Một luồng không thể tiến triển và do đó không thể thực hiện công việc hữu ích.

• Nguyên nhân:

  • Mức độ ưu tiên luồng không công bằng: Các luồng có mức độ ưu tiên cao hơn liên tục chiếm giữ tài nguyên, ngăn các luồng có mức độ ưu tiên thấp hơn truy cập.

  • Việc sử dụng tài nguyên không công bằng: Một số luồng chiếm giữ tài nguyên trong thời gian dài, ngăn các luồng khác truy cập.

  • Thời gian biểu của hệ điều hành: Hệ điều hành có thể liên tục chọn các luồng khác nhau để chạy, ngăn một luồng cụ thể có được thời gian chạy cần thiết.

---

Mô tả mục đích và các trường hợp sử dụng của Framework Fork/Join.

Framework Fork/Join cho phép song song hóa các thuật toán đệ quy. Vấn đề chính với việc song song hóa đệ quy bằng cách sử dụng một cái gì đó như ThreadPoolExecutor là bạn có thể nhanh chóng hết luồng vì mỗi bước đệ quy sẽ yêu cầu luồng riêng của nó, trong khi các luồng trên ngăn xếp sẽ nhàn rỗi và chờ đợi.

Điểm vào của framework Fork/Join là lớp ForkJoinPool, đây là một triển khai của ExecutorService. Nó triển khai thuật toán "work-stealing" (ăn cắp công việc), trong đó các luồng nhàn rỗi cố gắng "ăn cắp" công việc từ các luồng bận rộn. Điều này cho phép phân tán các tính toán giữa các luồng khác nhau và tiến triển trong khi sử dụng ít luồng hơn so với yêu cầu của một nhóm luồng thông thường.

Mục đích:

• Tối ưu hóa việc thực thi các thuật toán đệ quy bằng cách phân chia công việc thành các tác vụ nhỏ hơn và thực thi chúng song song.

• Cải thiện hiệu suất của các ứng dụng đa luồng bằng cách sử dụng hiệu quả các tài nguyên hệ thống.

Các trường hợp sử dụng:

• Thuật toán đệ quy:

  • Các thuật toán như sắp xếp hợp nhất (merge sort), quick sort, tìm kiếm cây nhị phân, v.v., có thể được song song hóa hiệu quả bằng Fork/Join.

• Xử lý dữ liệu lớn:

  • Chia một tập dữ liệu lớn thành các phần nhỏ hơn và xử lý chúng song song có thể tăng tốc độ xử lý đáng kể.

• Tính toán song song:

  • Các ứng dụng yêu cầu tính toán phức tạp có thể tận dụng Fork/Join để phân chia công việc và tăng tốc độ tính toán.

• Xử lý hình ảnh và video:

  • Các tác vụ xử lý hình ảnh và video có thể được song song hóa bằng fork/join để tăng tốc độ xử lý.

• Tìm kiếm và phân tích dữ liệu:

  • Các tác vụ tìm kiếm và phân tích trên các tập dữ liệu lớn có thể được song song hóa để tăng tốc độ xử lý.

Tóm lại, Fork/Join là một công cụ mạnh mẽ để song song hóa các thuật toán đệ quy và các tác vụ tính toán song song khác, giúp cải thiện hiệu suất của các ứng dụng đa luồng.