Thread in a hashtable
Frank Cisco
reference to it become null?
ie.
Runner r = new Runner();
hashmap.put(key,r);
r.start();
Does the reference to it by using:
hashmap.get(key);
become null after System.gc()? Because the thread is no exited and useless?
Lew
No.
Aside: System.gc() is a call that hints to the JVM that a full GC would be
good now. The JVM is not obligated to take the hint, although it usually
does. A full GC may be overkill if a young-generation GC would've done the
trick. It's a bad practice to call System.gc().
--
Lew
Xagyg
object (and hence reference to it) will exist for as long as the object
exists (i.e. is referenced by something).
Why is the thread "useless" when it finishes executing? You should be able
to run it again using "start".
Since the object is being held in the hashmap, it continues to be
referenced, so will not be garbage collected until it is no longer used -
out of scope - not referenced by any other object.
"Frank Cisco" <tdyjkdft...@dtyjdtyjdtyjdty.com> wrote in message
news:zhKKm.29878$TK7....@newsfe18.ams2...
Arved Sandstrom
> No. Generally, objects are allocated memory from the heap. The space for
> the object (and hence reference to it) will exist for as long as the
> object exists (i.e. is referenced by something).
>
> Why is the thread "useless" when it finishes executing? You should be
> able to run it again using "start".
You might want to read the Javadoc API for Thread.start().
AHS
Joshua Cranmer
> If you put a thread in a hashtable and it runs once and exits run() does
> the reference to it become null?
No. You are storing a strong reference, so it cannot be garbage
collected until you release the strong reference.
Now, if you stored a weak reference, it could be cleared without any
problems.
> Because the thread is no exited and useless?
Threads that have finished execute may be prohibited from being
restarted, but you can still do useful queries on it. Specifically,
isAlive, isInterrupted, getThreadGroup, join (though it may essentially
be a no-op), getId, and getState are some of the more useful ones.
If you're trying to check if a thread is dead, you can just use isAlive
or getState.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Xagyg
"Arved Sandstrom" <dce...@hotmail.com> wrote in message
news:JEKKm.52489$PH1.30517@edtnps82...
Frank Cisco
Robert Klemme
> Aside: System.gc() is a call that hints to the JVM that a full GC would
> be good now. The JVM is not obligated to take the hint, although it
> usually does. A full GC may be overkill if a young-generation GC
> would've done the trick. It's a bad practice to call System.gc().
There's even a command line option to switch off System.gc:
-XX:-DisableExplicitGC
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
IMHO System.gc() is one of the things that Sun did not get right
initially (much the same as synchronizing Vector and Hashtable and a few
more).
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Frank Cisco
"Robert Klemme" <short...@googlemail.com> wrote in message
news:7msqihF...@mid.individual.net...
what's up with synchronizing vector and hashtable?
Lew
>> IMHO System.gc() is one of the things that Sun did not get right
>> initially (much the same as synchronizing Vector and Hashtable and a
>> few more).
Frank Cisco wrote:
> what's up with synchronizing vector [sic] and hashtable [sic]?
That is a difficult question to parse. Taking it at face value, it looks like
the same point Robert made - doing so was a mistake. Sun fixed that mistake
with ArrayList and HashMap.
Now we're just stuck with the redundant options of using
Collections.synchronizedList( someArrayList ) vs. Vector and correspondingly
for HashMap/Hashtable. Of course, they're not actually redundant; the
Collections.synchronizedX() methods are far more flexible.
With the marked improvements in synchronization performance over the years the
pain of using the legacy classes is lessened, but they still aren't good
choices for fresh code over their replacements.
--
Lew
Joshua Cranmer
> what's up with synchronizing vector and hashtable?
My guess is that Sun felt that since Vector and Hashtable represent
rather primitive constructs, they might be used concurrently, and opted
to plan for that use case by making them synchronized.
Java is full of design mistakes, and those two classes were one of them.
Kevin McMurtrie
"Frank Cisco" <tdyjkdft...@dtyjdtyjdtyjdty.com> wrote:
. . .
> what's up with synchronizing vector and hashtable?
>
Guesses:
- Improve multithreading adoption at a time when most coders were afraid
of it or considered it voodoo
- Most of the JFCs were Java example code too
- There would have been Applet security holes if synchronization didn't
prevent unpredictable updates to the basic data types like HashMap,
Vector, Properties, and StringBuffer. (If StringBuffer wasn't
synchronized, it would have been possible to create a String that
changes.)
--
I won't see Goolge Groups replies because I must filter them as spam