hashtable.size is synchronized in JDK 1.4
Hi,
Currently we have an issue with our portal; occasionally the system hangs and stops responding completely. After analyzing the thread dump we noticed that all (most of) our threads are hanging at line,
if(hashtable == null || hashtable.size() < 1)
return null;
We are currently using JDK 1.3.1 where the hashtable.size() method is not synchronized. However JDK 1.4.2 has this method synchronized.
Is there a way to find out why this method is synchronized in JDK 1.4.2?
Could this be to fix an issue that we are having?
Thanks in advance,
Regards,
Rajesh
[624 byte] By [
Raj75a] at [2007-10-1 2:07:47]
As per the documentation for v1.3 implementation of Hashtable
"Hashtable is synchronized"
http://java.sun.com/j2se/1.3/docs/api/java/util/Hashtable.html
Hashtable has always been synchronized. If you don't want a synchronized hashtable use a HashMap which is not synchronized.
Note: If you are sharing this object as you appear to be, it should be synchronized. In stead you should find the thread which is locking this object and find out why it is not releasing the lock.
I.e. fix the cause not the symptom.
Thank you for the reply.
My question was specific to the method "size()".
javap java.util.Hashtable | grep -i size
Upto JDK1.3, running this command returns
public int size();
However, in JDK1.4, running this command returns
public synchronized int size();
That means this method was made synchronized in 1.4, I was wondering what was the reason this method was made synchronized in 1.4? Does this have anything to do with the problem that we are facing?
Regards,
Rajesh
This method wasn't synchronized in 1.3
public int size() {
return count;
}
However the behaviour of 1.4 is more consistent and correct.
You problem is that you cannot peak at the size when another thread has the hastable locked. Solve why this is happening and your problem will be resolved.
> This method wasn't synchronized in 1.3
> >public int size() {
> return count;
>}
>
> However the behaviour of 1.4 is more consistent and
> correct.
> You problem is that you cannot peak at the size when
> another thread has the hastable locked. Solve why
> this is happening and your problem will be resolved.
That's indeed potentially dangerous behaviour, especially if the other thread is deleting stuff and you're going to use that number as a loop condition...
