How Vector and Hashtable are thread-safe in collection?

Go To


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.

2012-04-04 02:43
by Rathan
use CuncurrentHashMap instead of HashTableLuiggi Mendoza 2012-04-04 02:45
Synchronization primitives like mutexes are used for mutual exclusion - Niklas B. 2012-04-04 02:45
@Luiggi, I think you're missing the point. The OP is asking why Hashtable is already thread safe (because all the methods are synchronized) - Kirk Woll 2012-04-04 02:46
Did you read the source - SLaks 2012-04-04 02:46
@KirkWoll I've read the question, I haven't read the implementations to say they're really thread safe, but Oracle recommends using ConcurrentHashMap instead of Hashtable for a syncronized Map implementation. It's for his knowledg - Luiggi Mendoza 2012-04-04 02:50
@Luiggi, I'm not diagreeing with you! I'm just saying that your comment is irrelevant. ; - Kirk Woll 2012-04-04 02:51
@KirkWoll ok, OP should ask about ConcurrentHashMap for being a thread-safe collection too : - Luiggi Mendoza 2012-04-04 02:55
ive never been asked that question in real life or academia - Woot4Moo 2012-04-04 03:04
Most significantly, Vector and Hashtable have sufficient synchronization to assure internal consistency (for most operations -- I haven't looked at the "recent" additions), whereas HashMap et al do not - Hot Licks 2012-04-04 03:07


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.

2012-04-04 02:47
by Óscar López


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.

2012-04-04 02:47
by user207421
I thought the reason new collection classes weren't synchronized is because there's a significant performance penalty for synchronization, and most data structures are not used in a multi-threaded situation. I agree there are many situations when the simplistic synchronization pattern provided by these classes is inadequate, but I think you take it too far when you say that they aren't thread-safe at all - Kirk Woll 2012-04-04 02:48
I would argue that @EJP draws a critical distinction. Using a nominally thread-safe class doesn't automatically confer correct synchronization - trashgod 2012-04-04 03:01
@trashgod -- Though "correct synchronization" (whatever that means) doesn't always confer correct synchronization. Vector and Hashtable provide sufficient synchronization to suffice in many (maybe all) circumstances, but, as usual, thought is required - Hot Licks 2012-04-04 03:05
@KirkWoll (1) As synchronization isn't particularly expensive your alternative reason does not hold water. (2) Thread-safety is a binary condition. Two possible vales: true or false - user207421 2012-04-04 03:05
@EJB, let's start with 2) yes, of course a given piece of code is either thread safe or not. What is not clear-cut is whether or not the minimal thread-synchronization implemented by 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
The cost of synchronization is K (whatever you want). The point is that most of the time, data strucutres are not consumed in a multi-threaded context. That means that when using the original Java data structures such as 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
@LotLicks - consider the iterators. The individual operations may be synchronized, but you still get into trouble if you assume that an iteration is atomic - Stephen C 2012-04-04 03:42
@Stephen, that's a great example. For what it's worth, I actually think thread-safe collections are unhelpful and I always synchronize on my own lock objects. All that being said, it doesn't take away from Hot Lick's original point; in many situations, the locking provided by these collections are in fact sufficient - Kirk Woll 2012-04-04 03:47
It is difficult to define what thread-safety really means. Read what Brian Goetz says on this in "Java Concurrency in Practice". Calling thread-safety a binary condition is maybe an oversimplification - Stephen C 2012-04-04 03:48
@KirkWoll the user's nick is EJP, not EJB : - Óscar López 2012-04-04 03:56
@ÓscarLópez Don't worry about it, everybody makes that mistake. I have the opposite problem, I can't type EJB accurately without thinking a bit ;- - user207421 2012-04-04 09:20
@KirkWoll "What is not clear-cut is whether or not the minimal thread-synchronization implemented by Hashtable is sufficient in a particular situation to actually be thread-safe." This is where we disagree. I claim it is is perfectly clear-cut, because non-thread-safe is non-thread-safe, period, regardless of 'particular situation[s]'. You can't agree with that and disagree with it at the same time, which is what you are doing here - user207421 2012-04-04 09:22


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) {
if (index > elementCount) {
    throw new ArrayIndexOutOfBoundsException(index
                         + " > " + elementCount);
ensureCapacityHelper(elementCount + 1);
System.arraycopy(elementData, index, elementData, index + 1, elementCount - index);
elementData[index] = obj;

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.

2012-04-04 02:47
by corsiKa
The contract says that "Unlike the new collection implementations, Vector is synchronized" - user207421 2012-04-04 02:48
You can split hairs about exactly what thread safe means if you like, sure - corsiKa 2012-04-04 02:49
I am referring to your final sentence. The contract specifies that the methods are synchronized, and it doesn't specify thread-safety, which isn't the same thing by a country mile - user207421 2012-04-04 10:47
@EJP "A piece of code is thread-safe if it only manipulates shared data structures in a manner that guarantees safe execution by multiple threads at the same time." Would you care to elaborate how "XXX is synchronized" could mean anything but that definition - corsiKa 2012-04-05 12:56
Iteration over such classes isn't thread-safe, and it can't be made thread-safe by adding 'synchronized' to any method of the class - user207421 2012-04-06 09:51
It is thread safe. Iterating over a Vector will not corrupt the data, ergo it is thread safe. You're saying it's not reliable to do so, and you're right it's not reliable to do so. But it is thread safe - corsiKa 2012-04-06 15:11
If someone else is modifying the vector simultaneously it is not thread-safe. Ergo it isn't thread-safe, period - user207421 2012-04-07 06:48
@EJP I'm sorry but that's not my definition of thread safe. There are subtle differences in what some people see as the definition. Your definition and my definition are the two most common 'camps'. There's a very good writeup here: - Basically my definition of thread safety refers to individual operations while you're looking for consistency in a sequence of operations. We could go back and forth for hours with the same comments, but both our views are summarized in the article - corsiKa 2012-04-07 11:58 is not thread-safe. QED - user207421 2012-04-07 12:35
@EJP But that's exactly the point I'm trying to make: At no time will a call to 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
If you iterate over a Vector while someone else is modifying it, the result is not thread-safe and you will get unexpected behaviour. It is not thread-safe against the actions of other threads. You can't just keep restricting the meaning of the term until it fits your conception, like the bed of Procrustes - user207421 2012-04-09 01:52
@EJP sigh It's not me restricting a meaning. I'm saying there is a wide division on what the meaning really is. Unexpected behavior does not imply non-thread-safety. By definition, all methods that don't modify the internal structure of a structure are inherently thread-safe. I'm sorry that you have a different definition of what thread-safe means. But if you've read the wiki entry on thread safety, or the article I linked on msdn, you'd realize exactly what I'm talking about. This will be my final comment on the matter - corsiKa 2012-04-09 09:47
But those 'other' definitions don't make any sense. By the same logic, iteration is thread-safe even though it may not be syncrhonized; 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:

2012-04-04 03:27
by Eugene Retunsky


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.

2012-04-04 04:24
by Tommy B


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.)

2014-04-21 12:01
by Akshay Lokur