Can objects with active threads be garbage collected?

M

Mark McKay

I've written a small thread which calls another object to listen to a
socket, and report back anything it hears. At the moment, the thread is
spending most of it's time in the other object (let's call it
SocketListener), blocked and waiting for the socket to yeild information.

Currently, this thread will run into explicitly closed. To program
defensively, I would like to have my thread automatically close if it is
the only object that still has a reference to SocketListener (most of
the time, a second object will have a hard reference to SocketListener).
While I can partially accomplish this by turning my thread's reference
to SocketListener into a WeakReference, since my thread is still
spending most of it's time blocked inside SocketListener, I'm thinking
the garbage collector will never detect this and my thread will be
running until the program shuts down.

Am I correct thinking this? Is there an elegant way around this?

Mark McKay
 
P

Phil...

what is your need to be "defensive"?
why should this thread terminate if "it" (I suppose a thread is an object)
is the only one left?
The advise I usually see about GC is to forget about it.
 
S

Steve Horsley

I've written a small thread which calls another object to listen to a
socket, and report back anything it hears. At the moment, the thread is
spending most of it's time in the other object (let's call it
SocketListener), blocked and waiting for the socket to yeild information.

Currently, this thread will run into explicitly closed. To program
defensively, I would like to have my thread automatically close if it is
the only object that still has a reference to SocketListener (most of the
time, a second object will have a hard reference to SocketListener).
While I can partially accomplish this by turning my thread's reference
to SocketListener into a WeakReference, since my thread is still spending
most of it's time blocked inside SocketListener, I'm thinking the garbage
collector will never detect this and my thread will be running until the
program shuts down.

Am I correct thinking this? Is there an elegant way around this?

Mark McKay

It is my understanding that an object cen never be garbage-collected while
a thread is inside one of its methods, if only because its "this"
reference is reachable.

Regardles of that, I don't think using a weak reference to figure out if
you're the only thread left in town will work, because under those
circumstances there will be no activity to triger the GC and clear the
weak reference out.

Steve
 
J

John C. Bollinger

Mark said:
I've written a small thread which calls another object to listen to a
socket, and report back anything it hears. At the moment, the thread is
spending most of it's time in the other object (let's call it
SocketListener), blocked and waiting for the socket to yeild information.

Currently, this thread will run into explicitly closed. To program
defensively, I would like to have my thread automatically close if it is
the only object that still has a reference to SocketListener (most of
the time, a second object will have a hard reference to SocketListener).
While I can partially accomplish this by turning my thread's reference
to SocketListener into a WeakReference, since my thread is still
spending most of it's time blocked inside SocketListener, I'm thinking
the garbage collector will never detect this and my thread will be
running until the program shuts down.

Am I correct thinking this? Is there an elegant way around this?

No object will be garbage collected while any thread is in one of its
methods. Note here the distinction between thread [of execution] and
Thread [object]. The latter can be regarded as a handle, or a control
panel, for the former. In any case, the JVM holds a reference to the
object in which each thread is running in each applicable stack frame.
Whether a reference is held by any object in your application is not
relevant in this case.

Do note that your problem may be (slightly) worse than you think -- the
running thread will prevent the JVM from shutting down at all unless you
make it a daemon thread.

I don't think there is any way around this at all. There is no way to
dynamically determine how many live references there are to any object,
and if your thread is blocked then it will never have a chance to
attempt to make such a determination anyway. Code defensively first by
taking care of your objects.


John Bollinger
(e-mail address removed)
 
S

Steven Coco

Mark said:
I've written a small thread which calls another object to listen to a
socket, and report back anything it hears. At the moment, the thread is
spending most of it's time in the other object (let's call it
SocketListener), blocked and waiting for the socket to yeild information.

Currently, this thread will run into explicitly closed. To program
defensively, I would like to have my thread automatically close if it is
the only object that still has a reference to SocketListener (most of
the time, a second object will have a hard reference to SocketListener).
While I can partially accomplish this by turning my thread's reference
to SocketListener into a WeakReference, since my thread is still
spending most of it's time blocked inside SocketListener, I'm thinking
the garbage collector will never detect this and my thread will be
running until the program shuts down.

My guess is that you really should re-design this system. If your
thread is collecting information from this socketlistener, whatever
object it's handing that information to should be able to tell it that
it's done with it. Not to mention the thread is using 'user' time so
the more efficiently you explicitly start and stop it, the less
resources you'll waste.

Good luck.

--

..Steven Coco.
.........................................................................
When you're not sure:
"Confess your heart" says the Lord, "and you'll be freed."
 
X

xarax

Mark McKay said:
I've written a small thread which calls another object to listen to a
socket, and report back anything it hears. At the moment, the thread is
spending most of it's time in the other object (let's call it
SocketListener), blocked and waiting for the socket to yeild information.

While the thread has a strong reference, the instance will
not be GC'd. The strong reference will be on the stackframe
of the blocking read() method.
Currently, this thread will run into explicitly closed. To program
defensively, I would like to have my thread automatically close if it is
the only object that still has a reference to SocketListener (most of
the time, a second object will have a hard reference to SocketListener).

This is a clue to the possible solution...
While I can partially accomplish this by turning my thread's reference
to SocketListener into a WeakReference, since my thread is still
spending most of it's time blocked inside SocketListener, I'm thinking
the garbage collector will never detect this and my thread will be
running until the program shuts down.

The SoftReference, WeakReference, or PhantomReference for the
SocketListener object will never pop while there is a strong
reference that is reachable by a live thread.
Am I correct thinking this? Is there an elegant way around this?

Mark McKay

It depends on the purpose of the mysterious "second object". You
imply that the "second object" has a field reference to the
SocketListener object and the GC of the second object indicates
that there is no other useful strong reference to the SocketListener.

Assuming that the GC of the second object indicates that you
are done with the SocketListener, you can achieve your goal thus:

1. Put the second object reference into a SoftReference or a
WeakReference or a PhantomReference. Be sure to use a ReferenceQueue.
I suggest using a SoftReference, but you could experiment with the
other kinds.

2. Create another (daemon) thread that will block on the
ReferenceQueue.

3. When the second object loses its last strong reference, the
ReferenceQueue will pop. The daemon thread clears the referent,
then interrupts the first thread and exits.

4. The first thread gets the InterruptedException and closes
the SocketListener, then exits gracefully.

5. If the first thread decides to exit early, then the other
daemon thread will go away on its own when the JVM terminates.

Give it a try and let us know what happens.

Good luck.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top