Is the synchronised keyword still required (ignore backwards compatibility, I'm thinking in terms of writing new code, today) or should we all be using the features available in the Concurrent and Collection packages?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
Indeed it is needed (in specific situations). Just read through Java Concurrency in Practice, it is used there many times over.
Of course, since Java 5 we can usually happily solve problems using (almost) exclusively the
Note also that locks are cheaper than they used to be as the JVM improves with every release. Long ago, this price was what turned off many developers from using them, but it is not so strongly justified anymore (and even if it is, only a concrete measurement can prove whether the performance bottleneck really is in locking).
The one place that
Example code from Javadocs
The only way I know to get around this limitation is to queue all operations in a SingleThreadExecutor, but that's a very expensive and archaic solution.
Well, it depends.
You can basically solve any problem using the concurrent and collection packages.
I suppose, this is an unlikely problem to run into and usually, redesigning the thread responsibility will provide a cleaner solution than optimizing it by hand, while being sufficiently fast. I couldn't get my hands on the source of those packages, but I wouldn't be surprised if they actually used synchronised for implementation (but the opposite wouldn't surprise me either).
Yes, the synchronized modifier is very much alive and required. Sure, you can use Locks and other stuff from the
So yes, for a good multithreaded program the use of the synchronized keyword is indeed required.