Re: Do I need to sync Get methods that return thread-safe collections
Royan wrote:
I'm trying to find potential pitfall in unsynchronized methods that
return thread-safe collections. Assume i'm [sic] designing a thread-safe
class.
public class ThreadSafe {
private Vector<String> vector;
Vector already has synchronized methods. That doesn't make it thread-safe for
all uses, but it might mean redundant locks when you impose your own lock on
top of Vector's.
/** Normally i'd write something like */
public int someMethod() {
lock.lock();
Why would you use a lock instead of 'synchronized'?
try {
// Do thread-safe things and change vector
vector.clear()
} finally {
lock.unlock();
}
}
/** But is OK to have such method? */
public Vector<String> getVector() {
return vector;
}
}
Of course I would not bother about thread safety if there was just
Vector object, in my project there are plenty of other things that
really need to be synchronized, my only concern is #getVector() method
with respect to my question
Whether it's "OK" to have such a method depends on a lot of things that you
haven't mentioned, in particular, what "OK" means for you in this context.
If you want to know if the method 'getVector()' needs to be synchronized, that
depends on how it's used. The inbuilt synchronization of the Vector object
might be enough for your purposes.
Regardless of the synchronization of the 'getVector()' method, you should do
two things. Do not name the method 'getVector' but something related to the
real purpose of the attribute, which is not to be a Vector but something in
the problem domain. Do not use Vector to implement the collection - use
ArrayList or another modern List implementation, and use
Collections.synchronizedList() on it when you need a List with synchronized
methods.
If the synchronized List turns out to be a concurrency bottleneck, use one of
the java.util.concurrent structures instead.
Read the articles on concurrency by Brian Goetz in IBM DeveloperWorks, and his
book /Java Concurrency in Practice/.
--
Lew