Câu hỏi của tôi liên quan đến câu hỏi này đã hỏi trước đó. Trong các tình huống mà tôi đang sử dụng hàng đợi để giao tiếp giữa các chủ đề của nhà sản xuất và người tiêu dùng, mọi người thường khuyên bạn nên sử dụng LinkedBlockingQueuehay ConcurrentLinkedQueue?
Ưu điểm / nhược điểm của việc sử dụng cái này so với cái kia là gì?
Sự khác biệt chính mà tôi có thể thấy từ góc độ API là a LinkedBlockingQueuecó thể được giới hạn tùy chọn.
Câu trả lời:
Đối với chuỗi nhà sản xuất / người tiêu dùng, tôi không chắc đó có phải ConcurrentLinkedQueuelà một lựa chọn hợp lý hay không - nó không triển khai BlockingQueue, đó là giao diện cơ bản cho hàng đợi nhà sản xuất / người tiêu dùng IMO. Bạn sẽ phải gọi điện poll(), đợi một chút nếu bạn không tìm thấy gì, và sau đó thăm dò lại, v.v. .
Từ các tài liệu cho BlockingQueue:
BlockingQueuetriển khai được thiết kế để sử dụng chủ yếu cho hàng đợi của nhà sản xuất-người tiêu dùng
Tôi biết nó không hoàn toàn nói rằng chỉ nên sử dụng hàng đợi chặn cho hàng đợi của nhà sản xuất-người tiêu dùng, nhưng ngay cả như vậy ...
ConcurrentLinkedQueuecũng hữu ích nếu luồng của bạn đang kiểm tra nhiều hàng đợi. Ví dụ: trong một máy chủ nhiều người thuê. Giả sử vì lý do cô lập, thay vào đó bạn không sử dụng một hàng đợi chặn duy nhất và một bộ phân biệt đối tượng thuê.
take() và put()chỉ tiêu tốn thêm tài nguyên (các khoảng đồng bộ hóa) hơn ConcurrentLinkedQueue . mặc dù trường hợp sử dụng hàng đợi có giới hạn cho các kịch bản Nhà sản xuất-người tiêu dùng
Câu hỏi này xứng đáng có một câu trả lời tốt hơn.
Java's ConcurrentLinkedQueuedựa trên thuật toán nổi tiếng của Maged M. Michael và Michael L. Scott cho các hàng đợi không khóa không khóa .
"Không chặn" như một thuật ngữ ở đây cho một tài nguyên cạnh tranh (hàng đợi của chúng tôi) có nghĩa là bất kể trình lập lịch của nền tảng làm gì, như làm gián đoạn một chuỗi hoặc nếu chuỗi được đề cập đơn giản là quá chậm, các chuỗi khác sẽ tranh giành cùng một tài nguyên vẫn sẽ có thể tiến triển. Ví dụ: nếu liên quan đến một khóa, chuỗi đang giữ khóa có thể bị gián đoạn và tất cả các chuỗi đang chờ khóa đó sẽ bị chặn. Khóa nội tại ( synchronizedtừ khóa) trong Java cũng có thể đi kèm với một hình phạt nghiêm trọng cho hiệu suất - như khi khóa thiên vịcó liên quan và bạn có tranh chấp hoặc sau khi máy ảo quyết định "thổi phồng" khóa sau thời gian gia hạn quay vòng và chặn các chủ đề cạnh tranh ... đó là lý do tại sao trong nhiều bối cảnh (tình huống tranh chấp thấp / trung bình), thực hiện so sánh-và -sets trên tham chiếu nguyên tử có thể hiệu quả hơn nhiều và đây chính xác là điều mà nhiều cấu trúc dữ liệu không chặn đang làm.
Java ConcurrentLinkedQueuekhông chỉ không bị chặn, mà còn có đặc tính tuyệt vời mà nhà sản xuất không cạnh tranh với người tiêu dùng. Trong kịch bản một nhà sản xuất / một người tiêu dùng duy nhất (SPSC), điều này thực sự có nghĩa là sẽ không có gì phải bàn cãi. Trong một kịch bản nhiều nhà sản xuất / một người tiêu dùng, người tiêu dùng sẽ không cạnh tranh với các nhà sản xuất. Hàng đợi này không có sự tranh chấp khi nhiều nhà sản xuất cố gắng offer(), nhưng đó là đồng thời theo định nghĩa. Về cơ bản, đó là một mục đích chung và hàng đợi không chặn hiệu quả.
Đối với nó không phải là một BlockingQueue, tốt, chặn một luồng để chờ trên hàng đợi là một cách khủng khiếp khủng khiếp để thiết kế các hệ thống đồng thời. Đừng. Nếu bạn không thể tìm ra cách sử dụng một ConcurrentLinkedQueuekịch bản dành cho người tiêu dùng / nhà sản xuất, thì chỉ cần chuyển sang các nội dung trừu tượng cấp cao hơn, như một khuôn khổ tác nhân tốt.
LinkedBlockingQueuechặn người tiêu dùng hoặc nhà sản xuất khi hàng đợi trống hoặc đầy và luồng người tiêu dùng / nhà sản xuất tương ứng được chuyển sang trạng thái ngủ. Nhưng tính năng ngăn chặn này đi kèm với một cái giá phải trả: mọi hoạt động bán hoặc nhận đều có sự cạnh tranh giữa người sản xuất hoặc người tiêu dùng (nếu nhiều người), vì vậy trong các tình huống có nhiều nhà sản xuất / người tiêu dùng, hoạt động có thể chậm hơn.
ConcurrentLinkedQueuekhông sử dụng khóa, nhưng CAS , trong hoạt động bán / nhận của mình có khả năng làm giảm sự cạnh tranh với nhiều nhà sản xuất và người tiêu dùng. Nhưng là một cấu trúc dữ liệu "đợi miễn phí", ConcurrentLinkedQueuesẽ không chặn khi trống, có nghĩa là người tiêu dùng sẽ cần phải xử lý các giá trị take()trả về nullbằng cách "bận chờ đợi", ví dụ, với luồng tiêu dùng ăn hết CPU.
Vì vậy, cái nào là "tốt hơn" phụ thuộc vào số lượng chủ đề của người tiêu dùng, vào tốc độ họ tiêu thụ / sản xuất, v.v. Cần có một điểm chuẩn cho mỗi tình huống.
Một trường hợp sử dụng cụ thể ConcurrentLinkedQueuerõ ràng là tốt hơn khi người sản xuất lần đầu tiên sản xuất một thứ gì đó và hoàn thành công việc của họ bằng cách đặt sản phẩm vào hàng đợi và chỉ sau khi người tiêu dùng bắt đầu tiêu thụ, biết rằng chúng sẽ được thực hiện khi hàng đợi trống. (ở đây không có sự đồng thời giữa người sản xuất và người tiêu dùng mà chỉ giữa người sản xuất-người sản xuất và người tiêu dùng-người tiêu dùng)
unbounded blockingqueueđược sử dụng nó sẽ là tốt hơn so với CAS dựa đồng thờiConcurrentLinkedQueue
Một giải pháp khác (không mở rộng quy mô tốt) là các kênh điểm hẹn: java.util.concurrent SynchronousQueue