Các trường hợp sử dụng cho các tiện ích đồng thời Java

Question

Tôi đã đọc Java Concurrency in Practice và đây là một tham chiếu tuyệt vời, nhưng tôi muốn xem tóm tắt một trang ngắn gọn về các trường hợp sử dụng của gói java.util.concurrent.

Ví dụ:

• Tại sao sử dụng một bộ sưu tập đồng thời trên một bộ sưu tập đồng bộ?
• Khi nào các lớp nguyên tử được ưu tiên hơn khóa rõ ràng?
• Khi nào Khóa nên được sử dụng qua đồng bộ hóa?
• Các lựa chọn thay thế để chờ() và thông báo(), thông báo choAll() là gì?
• Khi nào dịch vụ CompletionService được sử dụng?

Ưu điểm/nhược điểm và cạm bẫy cần lưu ý là gì?

Answer 1

• Tại sao sử dụng bộ sưu tập đồng thời trên bộ sưu tập được đồng bộ hóa?

Vì bộ sưu tập synchronized chỉ bảo vệ dữ liệu khỏi bị hỏng do truy cập đồng thời. Điều này không có nghĩa là các bộ sưu tập synchronized được tối ưu hóa để truy cập đồng thời. Thực tế, nó là một cơ chế tốt hơn cho compareAndSet hơn là khóa toàn bộ Map để đọc.

• Khi nào các lớp nguyên tử được ưu tiên hơn khóa rõ ràng?

Các lớp AtomicInteger và AtomicLong phải luôn được sử dụng (theo ý kiến) qua khóa bằng tay với nguyên thủy vì chúng ngắn gọn hơn. Xem xét:

synchronized (lock) { 
    int old = counter; 
    counter++; 
    return old; 
} 

Khi so sánh với:

int old = counter.getAndIncrement(); 

tôi phải nói mặc dù, rằng các lớp học bị họ thiếu waitability. Ví dụ, bạn thường muốn một số boolean được đồng bộ hóa, nơi bạn wait về điều kiện boolean. Chúng có sẵn là WaitableBoolean trong thư viện đồng thời Doug Lea cũ nhưng chúng đã bị bỏ trong j.u.c, tôi không chắc chắn tại sao.

• Khi nào Khóa nên được sử dụng khi đồng bộ hóa?

Đây là câu hỏi phức tạp hơn vì việc sử dụng Locks mang một số chi phí. Trên thực tế, người ta thường nói rằng không có pint khi sử dụng một trường hợp ReadWriteLock trong điển hình là. Một trường hợp nơi khóa phải được sử dụng là nơi khóa tài nguyên và mở khóa tài nguyên không thể được thực hiện trong cùng phạm vi từ vựng. synchronized là bất lực để giúp đỡ trong các trường hợp như vậy.

• Các lựa chọn thay thế để chờ() và thông báo(), thông báoAll() là gì?

await, signal và signalAll

• Khi một CompletionService nên được sử dụng?

Một dịch vụ hoàn rất hữu ích trong trường hợp việc tiêu thụ một kết quả của một tính toán không cần phải được truy cập tại điểm tính toán đã được gửi nhưng nơi điều quan trọng là rằng khi hoàn thành việc tính toán (hoặc kết quả của nó, hoặc thành công) được chương trình của bạn biết đến. Điều này có thể là, ví dụ, để theo dõi tỷ lệ các nhiệm vụ thất bại (mà đã ném ngoại lệ), hoặc nó có thể là để dọn dẹp tài nguyên.

Answer 2

What are the alternatives to wait() and notify(), notifyAll() 

Một rất tốt để thay thế cho wait(), notify() và notifyAll() là không sử dụng chúng AT ALL.

200Khuôn mã đơn tại đây là nhiều hơn đa luồng. Chúng tôi đang lây lan tải trên vô số lõi và có quân đội của nhà sản xuất/người tiêu dùng chương trình, vv

Instances của wait(), notify() hoặc notifyAll() trong mã của chúng tôi?

Không.

Tôi đặt lại sự nhấn mạnh vào thực tế rằng nó là một ứng dụng đa luồng rất nhiều: * chốt, thuốc độc, java.util.concurrent. ** và whatnots ở mọi nơi. Nhưng chờ(), thông báo() hoặc thông báoAllAll(): số không.

Đây là thực sự nội dung cấp thấp chỉ nên sử dụng trong các tiện ích/khung công tác đồng thời.

Từ Joshua Bloch, trong "Effective Java", vào đầu rất của "Chủ đề" chương:

"Nếu có một thư viện mà có thể giúp bạn tiết kiệm từ làm ở mức độ thấp đa chương trình đã đọc, bằng mọi cách sử dụng nó. "