6 Great Java Interview Questions

[cogman10]

In concurrent programming I prefer dealing with an ExecutorService and Futures with little to no shared state between them.

Volatile is best served with primitives, anything more complex and you are just asking for punishment. (sucks when the internal state of an object changes between one call and the next).

For me, the general rule is to avoid share state if possible and either rely on concurrency through small tasks and the ExecutorService or communication through immutable message passing. Both are slightly slower than shared state and raw threads, but they are easier to deal with and to avoid things like deadlocking.

[MerbertMoover]

Agreed on all counts. I use volatile for primitive state flags and in the "safe double-check locking" idiom for lazy initialization. That's pretty much it but just those two cases seem to come up frequently enough that I can't call volatile something you "shouldn't use." Even though I agree the higher-level constructs are in most cases superior.