Garbage Collection of Threads

Discussion in 'Java' started by WonderboyFromMars@googlemail.com, Nov 13, 2005.

  1. Guest

    Hello everyone.

    I have a problem with instanciating many threads and the destruction of
    these objects.
    Does the garbage collector actually delete threads?
    I'm writing a network application which has to create 2 threads which
    read and write to PipeStreams on each new conenction. And I have alot
    of
    connections. the problem is that the application has a big mem.-leak
    and
    I narrowed it down to the fact that the Garbage Collector actually
    won't
    clean up stopped or interrupted threads. JProfiler tells me that more
    an
    more instances of the threads are created although the threads are
    inactive (the thread-column in the Windows taskmanager jumps to a
    thread-peak but drops down to the actual number of threads). I think
    that the thread memory still remains on the heap. I'm actually a c++
    programmer who does eventually something in java ;) the code looks
    something like this

    while(...)
    {
    socket.accept()

    ThreadWorker1 tw1 = new ThreadWorker1(...);
    ThreadWorker2 tw2 = new ThreadWorker2(...);
    tw1.start();
    tw2.start();
    }

    the threadworkers start their own threads internally which get
    interrupted when the work is done. does this construction lead to
    mem.-leaks? If I let the app run for let's say an hour and then look at
    the instance count of ThreadWorker1 and ThreadWorker2 in JProfiler, I
    can see that the instance count never goes down but up (after 1 h i
    have
    100 instances of TW1 and TW2). The threads are definitly stopped
    sometime (or Windows Taskmanager is lying ;) ) but obviously never
    released.

    Thanks in advance
    Anusch
     
    , Nov 13, 2005
    #1
    1. Advertising

  2. Roedy Green Guest

    On 13 Nov 2005 01:50:58 -0800, wrote,
    quoted or indirectly quoted someone who said :

    >Does the garbage collector actually delete threads?


    If you create them but never start them, they will hang around
    forever. Normally though they die as soon your run method returns and
    the Thread along with its whacking great stack is gced.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Nov 13, 2005
    #2
    1. Advertising

  3. Roedy Green Guest

    On 13 Nov 2005 01:50:58 -0800, wrote,
    quoted or indirectly quoted someone who said :

    >clean up stopped or interrupted threads. JProfiler tells me that more
    >an


    You are not supposed to stop threads. That method is deprecated. Who
    knows what happens then.

    Interrupted threads are still very much alive so of course should NOT
    be gced.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Nov 13, 2005
    #3
  4. Guest

    First of, thanks for your reply Roedy!

    I do actually interrupt the threads! I should just let the threads "run
    out" of their run methods? Should this really solve the problem? It
    would be great! Is it better to let some sort of ThreadPool manage the
    lifetime of the threads? I am really uncomfortable producing so many
    threads and fire and forgetting them but this was the easiest and
    fastest way to implement this application.
     
    , Nov 13, 2005
    #4
  5. Roedy Green Guest

    On 13 Nov 2005 02:44:20 -0800, wrote,
    quoted or indirectly quoted someone who said :

    >I do actually interrupt the threads! I should just let the threads "run
    >out" of their run methods? Should this really solve the problem? It
    >would be great! Is it better to let some sort of ThreadPool manage the
    >lifetime of the threads? I am really uncomfortable producing so many
    >threads and fire and forgetting them but this was the easiest and
    >fastest way to implement this application.


    Have a look at http://mindprod.com/jgloss/queue.html
    and follow the links in into the Sun documentation on the new
    concurrent classes. They give you all sorts of ways of managing thread
    pools.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Nov 13, 2005
    #5
  6. Chris Smith Guest

    Roedy Green <> wrote:
    > If you create them but never start them, they will hang around
    > forever. Normally though they die as soon your run method returns and
    > the Thread along with its whacking great stack is gced.


    It's worth mentioning that there's a big difference between a thread and
    an object of class Thread. The object should be understood as a
    control-panel that can be used to control the thread... not the thread
    itself.

    In particular, the release of memory used for a thread's stack is NOT
    related to garbage collection. The stack space is in no way associated
    with the Thread instance. It is released the very instant that the
    thread exits.

    This is also important because the Thread object can last far longer
    than the thread itself. It's not uncommon, for example, to keep around
    a reference to a thread so that you can call join, interrupt, isAlive,
    etc. on the object. If the thread were kept around as long as you keep
    a reference to that object, then you might start to think that doing so
    is a bad idea. It's not, though.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Nov 13, 2005
    #6
  7. wrote:
    > First of, thanks for your reply Roedy!
    >
    > I do actually interrupt the threads! I should just let the threads "run
    > out" of their run methods? Should this really solve the problem? It
    > would be great! Is it better to let some sort of ThreadPool manage the
    > lifetime of the threads? I am really uncomfortable producing so many
    > threads and fire and forgetting them but this was the easiest and
    > fastest way to implement this application.
    >


    I strongly suspect that Threads don't become eligible for GC
    until after they return from run(). I presume that stopping the
    thread prevents it from ever retuning.

    I don't see what interrupting it has to do with this though. You
    may change its course, wake it from some blocking state, but
    until it returns from run() it is alive and cannot be GCd
    whatever it is doing.

    The normal way to kill threads is to tell them you wish them to
    quit - set a flag they look at from time to time (interrupting
    sets a flag they can check with isInterrupted IIRC). When they
    see they are no longer wanted, then they can clean up, releasing
    any locks or other resources they hold and return (run out from
    run) in their own time. They don't have to explicitly de-allocate
    Objects that they hold, because the GC will clean those up.

    Steve
     
    Steve Horsley, Nov 13, 2005
    #7
  8. coughed up:
    > First of, thanks for your reply Roedy!
    >
    > I do actually interrupt the threads! I should just let the threads "run
    > out" of their run methods? Should this really solve the problem? It
    > would be great! Is it better to let some sort of ThreadPool manage the
    > lifetime of the threads? I am really uncomfortable producing so many
    > threads and fire and forgetting them but this was the easiest and
    > fastest way to implement this application.



    Could you elaborate a little on why you think you need a great number of
    threads?

    Most of the times I've seen this, the designer was very much mistaken.



    --
    "So I just, uh... I just cut them up like regular chickens?"
    "Sure, just cut them up like regular chickens."
     
    Thomas G. Marshall, Nov 14, 2005
    #8
  9. DrChaos Guest

    I would agree that this is the best code safe way to deal with live
    threads. Manageable and predictable. From a thread manager, track who
    is alive if they where asked to quit and when they have actually
    returned/quit.
    -DrChaos

    Steve Horsley wrote:
    > wrote:
    >
    >> First of, thanks for your reply Roedy!
    >>
    >> I do actually interrupt the threads! I should just let the threads "run
    >> out" of their run methods? Should this really solve the problem? It
    >> would be great! Is it better to let some sort of ThreadPool manage the
    >> lifetime of the threads? I am really uncomfortable producing so many
    >> threads and fire and forgetting them but this was the easiest and
    >> fastest way to implement this application.
    >>

    >
    > I strongly suspect that Threads don't become eligible for GC until after
    > they return from run(). I presume that stopping the thread prevents it
    > from ever retuning.
    >
    > I don't see what interrupting it has to do with this though. You may
    > change its course, wake it from some blocking state, but until it
    > returns from run() it is alive and cannot be GCd whatever it is doing.
    >
    > The normal way to kill threads is to tell them you wish them to quit -
    > set a flag they look at from time to time (interrupting sets a flag they
    > can check with isInterrupted IIRC). When they see they are no longer
    > wanted, then they can clean up, releasing any locks or other resources
    > they hold and return (run out from run) in their own time. They don't
    > have to explicitly de-allocate Objects that they hold, because the GC
    > will clean those up.
    >
    > Steve
     
    DrChaos, Nov 17, 2005
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kevin Jackson
    Replies:
    1
    Views:
    414
    Alvin Bruney [MVP]
    May 28, 2004
  2. Andrew Mallinson

    Threads and Garbage Collection

    Andrew Mallinson, Jan 30, 2004, in forum: Java
    Replies:
    2
    Views:
    351
    Andrew Mallinson
    Jan 30, 2004
  3. Shirish Rai

    Garbage Collection and Threads

    Shirish Rai, Jun 9, 2004, in forum: Java
    Replies:
    3
    Views:
    349
    Chris Smith
    Jun 9, 2004
  4. Øyvind Isaksen
    Replies:
    1
    Views:
    980
    Øyvind Isaksen
    May 18, 2007
  5. Brian Candler

    Threads preventing garbage collection?

    Brian Candler, Sep 17, 2008, in forum: Ruby
    Replies:
    11
    Views:
    206
    ara.t.howard
    Sep 18, 2008
Loading...

Share This Page