I know that both of them have thread safe methods. I want to know how they are thread safe? What is the implementation? This is a common question in all interviews.
Hashtable
is already thread safe (because all the methods are synchronized) - Kirk Woll 2012-04-04 02:46
Take a look inside the code of Vector and Hashtable in OpenJDK, you'll notice that most of the public methods are synchronized
, that's the implementation detail that makes the methods of both collections thread-safe. Also notice that other operations over these collections (iteration, for instance) need external synchronization for being thread-safe.
They aren't. All their methods are synchronized. It isn't the same thing. Iteration over them isn't and can't be thread-safe, unless the block enclosing the iteration is threadsafe, e.g. synchronized. So the caller still has a responsibility to provide thread-safeness. This is the reason the new classes in the Collections Framework didn't have synchronized methods by default.
Hashtable
is sufficient in a particular situation to actually be thread-safe. Now back to 1) Yes, synchronization is in fact somewhat expenesive (despite improvements, I see a difference of about 2:1. I'd be happy to share my tests with you if you're interested.) -- but that's actually irrelevent - Kirk Woll 2012-04-04 03:28
Hashtable
you were usually wasting K amount of time. I think we can all agree that it's ideal when we don't waste time at all unnecessarilly - Kirk Woll 2012-04-04 03:28
The Vector class that shipped with my version of the Sun/Oracle JDK, which is 6 something, uses synchronized methods, like so
public synchronized void insertElementAt(E obj, int index) {
modCount++;
if (index > elementCount) {
throw new ArrayIndexOutOfBoundsException(index
+ " > " + elementCount);
}
ensureCapacityHelper(elementCount + 1);
System.arraycopy(elementData, index, elementData, index + 1, elementCount - index);
elementData[index] = obj;
elementCount++;
}
All the important methods are synchronized in such a way, right in the method signature.
Note, however, that this is not manditory. The contract only says you have to make it thread safe, it does not specify how.
Iterator.next()
cause the internal state of the Vector to go corrupt. QED it is thread-safe. Like I said We are operating under two different definitions of thread-safe. Continuing this discussion is about as useful as discussing emacs vs vim. Read the article, and be more enlightened to the views of others - corsiKa 2012-04-07 12:47
add()
isn't thread-safe even though it is synchronized; and 'thread-safe' only applies to the situation where there aren't any other threads. I don't find definitions or thinking of that sort has much practical value or significance. The definitions exclude things that should be included, and include things that should be excluded - user207421 2012-04-10 09:27
These classes are conditionally thread-safe and using them is not a good style. A better option is using java.util.concurrent.* classes (e.g. ConcurrentHashMap, CopyOnWriteArrayList etc.) which are truly thread-safe and provide good performance
E.g. ConcurrentHashMap scales much better than synchronized HashMap: http://www.javamex.com/tutorials/concurrenthashmap_scalability.shtml
The problem with those two classes is that they give the impression of being thread safe by providing synchronized methods, but their internal state is modifiable by the iterators they provide you access to.
Synchronization in this only buys your thread exclusivity in executing in all the synchronized methods as they share the same synchronization lock.
It is terminology which indicate that the methods in the class are threadsafe i.e. synchronized! (A class in itself can not be Threadsafe. Its just the way of saying so.)
CuncurrentHashMap
instead ofHashTable
Luiggi Mendoza 2012-04-04 02:45