Question

I have a simple bean @Entity Message.java that has some normal properties. The life-cycle of that object is as follows

Instantiation of Message happens on Thread A, which is then enqueued into a blockingQueue

Another thread from a pool obtains that object and do some stuff with it and changes the state of Message, after that, the object enters again into the blockingQueue. This step is repeated until a condition makes it stop. Each time the object gets read/write is potentially from a different thread, but with the guarantee that only one thread at a time will be reading/writing to it.

Given that circumstances, do I need to synchronize the getters/setters ? Perhaps make the properties volatile ? or can I just leave without synchronization ?

Thanks and hope I could clarify what I am having here.

Answer 1

No, you do not need to synchronize access to the object properties, or even use volatile on the member variables.

All actions performed by a thread before it queues an object on a BlockingQueue “happen-before” the object is dequeued. That means that any changes made by the first thread are visible to the second. This is common behavior for concurrent collections. See the last paragraph of the BlockingQueue class documentation:

Memory consistency effects: As with other concurrent collections, actions in a thread prior to placing an object into a BlockingQueue happen-before actions subsequent to the access or removal of that element from the BlockingQueue in another thread.

As long as the first thread doesn’t make any modifications after queueing the object, it will be safe.