Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Why is an object that was used to run a thread remain in heap?  RSS feed

 
John McDowell
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if the thread can't be re-run anymore after it has completed its job once(i.e finished executing all the statements in run()), what is the point in keeping it in the heap? couldn't this lead to memory starvation. Is there any reason to keep it on the heap and NOT discard it. Please don't redirect me to some site that has tons of documentation or api's
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What makes you think that they're not being discarded? Objects that are no longer referenced are discarded eventually, although maybe not right away if the JVM has enough memory available.

As an aside, is there a socket/network aspect to this question? Just asking because you posted in the "Sockets and Internet Protocols" forum. (no big deal, we can move it).
 
Henry Wong
author
Sheriff
Posts: 22837
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Let's move this topic -- along with the other thread questions posted in the socket forum too.
 
John McDowell
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ulf Dittmer wrote:What makes you think that they're not being discarded? Objects that are no longer referenced are discarded eventually, although maybe not right away if the JVM has enough memory available.

As an aside, is there a socket/network aspect to this question? Just asking because you posted in the "Sockets and Internet Protocols" forum. (no big deal, we can move it).


That's what is told in pg 500 headfirst java 2nd edition in the there are no dumb questions section
 
John McDowell
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Let's move this topic -- along with the other thread questions posted in the socket forum too.


Yeah I posted the question in the wrong forum by mistake.This question was meant for the Beginning Java Section.
 
John McDowell
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
John McDowell wrote:
Ulf Dittmer wrote:What makes you think that they're not being discarded? Objects that are no longer referenced are discarded eventually, although maybe not right away if the JVM has enough memory available.

As an aside, is there a socket/network aspect to this question? Just asking because you posted in the "Sockets and Internet Protocols" forum. (no big deal, we can move it).


That's what is told in pg 500 headfirst java 2nd edition in the there are no dumb questions section


The question goes like...

Can you reuse a Thread object? Can you give It
a new Job to do and then restart It by calling start()
agaln?

And the answer goes like..
No.Once a thread 's runO method has completed,
the thread can never be restarted . In fact, at that
point the thread moves Into a state we haven't talked
about-dead. In the dead state, the thread has
finished Its runO method and can never be restarted.
The Thread object might stili be on the heap, as a
living object that you can call other methods on (If
appropriate), but the Thread object has permanently
lost its 'threadness'. In other words, there Is no longer a
separate call stack, and the Thread object Is no longer
a thread. It's Just an object, at that point, like all other
objects.
But, there are design patterns for making a pool of
threads that you can keep using to perform different
jobs. But you don't do It by restartlng() a dead thread.
 
Henry Wong
author
Sheriff
Posts: 22837
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
John McDowell wrote:
John McDowell wrote:
Ulf Dittmer wrote:What makes you think that they're not being discarded? Objects that are no longer referenced are discarded eventually, although maybe not right away if the JVM has enough memory available.


That's what is told in pg 500 headfirst java 2nd edition in the there are no dumb questions section


The question goes like...

Can you reuse a Thread object? Can you give It
a new Job to do and then restart It by calling start()
agaln?

And the answer goes like..
No.Once a thread 's runO method has completed,
the thread can never be restarted . In fact, at that
point the thread moves Into a state we haven't talked
about-dead. In the dead state, the thread has
finished Its runO method and can never be restarted.
The Thread object might stili be on the heap, as a
living object that you can call other methods on (If
appropriate), but the Thread object has permanently
lost its 'threadness'.
In other words, there Is no longer a
separate call stack, and the Thread object Is no longer
a thread. It's Just an object, at that point, like all other
objects.



This is true for any object. If you maintain references to useless objects, the GC will not be able to collect it. However, the system is not doing that -- the java library is smart enough to no longer refer to thread objects that has been terminated.

Henry
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A running thread will be ineligible for GC even if your code directly has no reference, its in the current thread group (you could look it up) and considered a GC root. Running threads appear slightly special in that they appear to exist when running without you holding a reference which can at first seem slightly odd.

The sentence from the book means ..

After the thread completes if your code has elected to hold a reference to thread that has completed you're preventing GC of that object but you can't restart the thread it represents via the thread objects interface. The holding onto the thread object might be considered wasteful/ leak but it's your code that is causing the leak (causing it to remain on the heap) in that scenario i.e. not the JVM.
 
John McDowell
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Chris Hurst wrote:A running thread will be ineligible for GC even if your code directly has no reference, its in the current thread group (you could look it up) and considered a GC root. Running threads appear slightly special in that they appear to exist when running without you holding a reference which can at first seem slightly odd.

The sentence from the book means ..

After the thread completes if your code has elected to hold a reference to thread that has completed you're preventing GC of that object but you can't restart the thread it represents via the thread objects interface. The holding onto the thread object might be considered wasteful/ leak but it's your code that is causing the leak (causing it to remain on the heap) in that scenario i.e. not the JVM.


Hi thanks a lot for the reply. I however need some further clarification on what you just said. Supposing I have a thread object called myThread and I ran the thread using myThread.start(), What statement should I add after the start statement so that I no longer have any references to the thread object on the heap. This would prevent memory leak.. Can I just put a statement like myThread = null; to de reference the exhausted thread object and make it available for GC?
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Null'ing the reference or just letting the variable go out of scope i.e. if you use a local variable and exit the method (the thread still runs and the JVM has a reference until the thread completes).

If your very curious, take a heap dump and have a look at it with visual VM which came with the JDK.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!