是阻塞队列所需的同步块

Question

public BlockingQueue<Message> Queue;
Queue = new LinkedBlockingQueue<>();

I know if I use, say a synchronized List, I need to surround it in synchronized blocks to safely use it across threads

Is that the same for Blocking Queues?

Answer 1

No you do not need to surround with synchronized blocks.

From the JDK javadocs ...

BlockingQueue implementations are thread-safe. All queuing methods achieve their effects atomically using internal locks or other forms of concurrency control. However, the bulk Collection operations addAll, containsAll, retainAll and removeAll are not necessarily performed atomically unless specified otherwise in an implementation. So it is possible, for example, for addAll(c) to fail (throwing an exception) after adding only some of the elements in c.

Just want to point out that from my experience the classes in the java.util.concurrent package of the JDK do not need synchronization blocks. Those classes manage the concurrency for you and are typically thread-safe. Whether intentional or not, seems like the java.util.concurrent has superseded the need to use synchronization blocks in modern Java code.

Answer 2

Depends on use case, will explain 2 scenarios where you may need synchronized blocks or dont need it.

1. Case 1: Not required while using queuing methods eg put, take etc.

   Why not required is explained here , important line is below:

   BlockingQueue implementations are thread-safe. All queuing methods achieve their effects atomically using internal locks or other forms of concurrency control.

2. Case 2: Required while iterating over blocking queues and most concurrent collections

   Since iterator (one example from comments) is weakly consistent, meaning it reflects some but not necessarily all of the changes that have been made to its backing collection since it was created. So if you care about reflecting all changes you need to use synchronized blocks/ Locks while iterating.

Answer 3

You are thinking about synchronization at too low a level. It doesn't have anything to do with what classes you use. It's about protecting data and objects that are shared between threads.

If one thread is able to modify any single data object or group of related data objects while other threads are able to look at or modify the same object(s) at the same time, then you probably need synchronization. The reason is, it often is not possible for one thread to modify data in a meaningful way without temporarily putting the data into an invalid state.

The purpose of synchronization is to prevent other threads from seeing the invalid state and possibly doing bad things to the same data or to other data as a result.

---

Java's Collections.synchronizedList(...) gives you a way for two or more threads to share a List in such a way that the list itself is safe from being corrupted by the action of the different threads. But, It does not offer any protection for the data objects that are in the List . If your application needs that protection, then it's up to you to supply it.

If you need the equivalent protection for a queue, you can use any of the several classes that implement java.util.concurrent.BlockingQueue . But beware! The same caveat applies. The queue itself will be protected from corruption, but the protection does not automatically extend to the objects that your threads pass through the queue.