We're getting just a bit off-topic, but I'll continue briefly in hope
it sheds some useful light somewhere...
With what tool were you identifying a "zombie" thread? Did you examine
where it was on its stack?
If it has an active Java stack, then it's still busy, and not a
zombie.
A thread OBJECT will certainly stay around until all references are
gone. That's very different than the OS/JVM thread it controls. The OS/
JVM threads are not affected by the GC, but the instance of the Thread
class is. You could certainly leak them. They shouldn't be all that
big, but if you start enough brief threads, and then leak the Thread
objects, it could hurt.
Still, that's not good way to use threads, since there's a fair amount
of overhead involved in allocating and starting threads (though how
much varies with platform). That's one reason thread pools were
invented. (The other is to allow you to manage how many threads are
active at once).
But as I said before, I agree that it's good practice to null out
references to threads that you're finished with. I'm just trying to
clarify the difference between that and those big OS/JVM threads and
any zombie behavior.
do while(!KILL){} is often not enough. Usually, you also have to
carefully manage the conditions under which it waits, and preferably
do a notify() on what it's waiting on, if you can.
If you can't -- for example, if it's IO that you're waiting on, and
the IO waits forever for input that never comes -- then your thread
will never complete, and with the java.io facilities, you'll not be
able to do anything about it. But that's not a zombie. It's still
working.
If that's a problem, then use the java.nio facilities instead. Or if
the problem is just that you need to allow the application to exit
even if the thread hasn't finished, then make it a daemon thread, and
don't worry about shutting it down.
If it's some other library that's waiting, and you have no way of
telling it to stop waiting, then you're screwed, but that's a
deficiency in that library's APl, and not zombie threads, either. But
maybe that's what you're calling a zombie thread?
The traditional meaning of a zombie is something that hangs around
*after it's done*. For example unix processes that have not yet had
their return status read. Or processes that can't be terminated
because they have IO streams that cannot be successfully closed. I'm
not trying to be pedantic about terminology here -- I'm just trying to
see if we're talking about the same thing or not.
On Mar 13, 5:36 pm, Ken Warner <[email protected]> wrote:
> I'm not trying to argue -- but I've seen dead threads (zombies) hang
> around for a long time. Null all possible references in your code
> *AFTER* you are done with the thread and do an explicit gc(). I didn't
> say that nulling a reference would kill the thread. It only helps
> garbage collection.
>
> The flag (or semaphore) I'm talking about is going to be app specific.
> Many times I will start a thread that will run for a while in a loop.
> For my apps, I do while(!KILL){} loop then set the KILL flag true when
> I want the thread to exit the loop and finish. And I certainly do
> know first hand about deadlock and how hard it is to find where and
> why and how to fix.
>
> I understand now that AsyncTask is not a thread -- I didn't before.
> So the programming tricks for threads I suggested don't apply here.
> A group of managed threads is a whole different deal.
>
> I've never used AsyncTask. I don't even know if it's in the JDK
> because I've never looked for it. I usually manage my own threads.
>
> Is AsyncTask a part of the Android SDK?
>
>
>
> Bob Kerns wrote:
> > What evidence do you have of this? What exactly do you mean by a
> > zombie thread?
>
> > I've been programming Java since sometime near when it came out --
> > well over a decade, on various platforms. I've never seen anything I'd
> > term a zombie thread, nor a thread problem that would be solved by
> > nulling thread references to null.
>
> > I hesitate to say you're incorrect without more specifics, however.
>
> > I'm not sure what sort of exit flag you're suggesting. One that
> > indicates a thread has exited, or one that indicates it should exit?
>
> > I'll add that it's certainly possible in Java to write a program that
> > leaves a thread blocked forever, waiting for something that never
> > happens. You can also introduce deadlocks -- when two thread each lock
> > an object, and then try to get a lock on the object locked by the
> > other.
>
> > But this is an issue with ANY thread programming, not Java, and is not
> > something I'd term zombie threads, nor a Java problem.
>
> > Coordinating threads properly is tricky. That's one reason why
> > AsyncTask is provided, so that you don't have to worry about how to do
> > it correctly and safely.
>
> > BTW, nulling out references to a thread isn't going to make the thread
> > stop running. In fact, the thread's stack is one of the things that
> > the GC has to trace through.to find things to keep. The GC cannot just
> > eliminate the running thread during its run -- and at any point, the
> > thread's code could ask for the current thread.
>
> > Still, I'm not arguing against nulling out the references once you no
> > longer need them. It documents where you no longer expect to reference
> > them, and it forces any references after that point to get a
> > NullPointerException, which will allow you to detect bugs closer to
> > the point of origin (or worse, detect bugs that might not be noticed).
>
> > On Mar 13, 9:44 am, Ken Warner <[email protected]> wrote:
> >> Null out all references to the thread. Java has a problem
> >> with zombie threads -- this is a java app right?
>
> >> I can't say exactly how you should do the following but make
> >> sure there is an explicit way to exit each thread. I usually
> >> set a flag to tell the thread to exit.
>
> >> Those two things -- null all references and setting an explicit
> >> exit flag are the most you can do.
>
> >> After you null all references to the thread, do an explicit
> >> gc() if that's available.
>
> >> Gabriel Sim es wrote:
> >>> Hello,
> >>> Today, while debugging and app that uses AsyncTask to record audio and
> >>> update UI I noticed that everytime that an AsyncTask object ends
> >>> running (finishes doInBackground() and onPostExecute() or
> >>> onCancelled()) it s thread stays alive (running status).
> >>> At least for me that should not be the behavior of the class since the
> >>> doInBackground task may not stay running forever (as an example the
> >>> android manual says that a status bar should be updated by an
> >>> asynctask, and it won t last for the whole app running time).
> >>> Is there anything I m missing, as a method to destroy it, or should I
> >>> just ignore and keep creating threads as I need and the VM will handle
> >>> them as it needs resources?
> >>> Thank you,
> >>> Gabriel Sim es
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
