RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use > alternative to finalization (Roger Riggs)
Peter Levart
peter.levart at gmail.com
Sat Oct 3 20:32:06 UTC 2015
On 10/02/2015 10:16 PM, Roger Riggs wrote:
> Hi Mike,
>
> Thanks for the review and comments...
>
> On 10/2/2015 3:33 PM, Mike Duigou wrote:
>> Hi Roger;
>>
>> This looks like an interesting proposal and would be a good
>> replacement for alternative solutions.
>>
>> I am curious why the thread is run at max priority. Also, why not set
>> priority and daemon status in the factory?
> Yes, that should probably be left to the factory and for built-in
> factory would be moved to the InnocuousThreadFactory.
>>
>> You should clear the Thread intrerruption if you are going to ignore
>> it. Thread.interrupted();
> Will do.
>>
>> I would suggest surrounding the thunk.run() with a catch of Throwable
>> or Exception. In the current implementation one bad egg spoils the
>> party for everyone. There is a catch of RuntimeException described as
>> "catch (RuntimeException e) { // ignore exceptions from the cleanup
>> thunk }" but I would suggest that this is insufficiently paranoid.
> Good point, catches more bad eggs.
>>
>> Consider a pattern like:
>>
>> private static final ReferenceQueue<Object> weakListeners = new
>> ReferenceQueue<>();
>>
>>
>> private static class CleanerThread extends Thread {
>> { setDaemon(true); setPriority(Thread.MIN_PRIORITY); }
>> @Override
>> @SuppressWarnings("unchecked")
>> public void run() {
>> // Using weak ref to queue allows shutdown if class is unloaded
>> WeakReference<ReferenceQueue<Object>> weakQueue = new
>> WeakReference<>(weakListeners);
>> ReferenceQueue<Object> queue = null;
>> while((queue = (queue == null ? weakQueue.get() : queue) != null)
>> try {
>> Object dead = queue.remove(10000);
>> if(dead != null) {
>> // do stuff with "dead"
>> } else {
>> queue = null; // recheck to see if queue is gone.
>> }
>> } catch(InterruptedException woken) {
>> Thread.interrupted();
>> }
>> }
>> }
>>
>> When 'weakListeners' is cleared when the containing class is unloaded
>> then the thread will shut down after roughly 10 seconds.
>>
>> I have been meaning to check whether CleanerThread needs to be in a
>> separate class--an inner class, even a static one, may prevent it's
>> containing class from being GCed. IDK.
> I think that 'nested' classes aka static class has no links to the
> outer class and can be GC'ed but will check.
>
> Thanks, Roger
Hi Mike, Roger,
Nested classes are typically loaded by the same ClassLoader as their
outer classes. Normal named classes (as opposed to VM-annonymous
classes) can't be GC-ed individually. Their defining ClassLoader keeps
them referenced in it's ClassLoader#classes Vector. Each class has an
implicit reference to it's defining ClassLoader, therefore each class
indirectly references every class defined by the same ClassLoader as
itself, and by delegation of ClassLoaders also every class defined by
predecessor ClassLoaders. Only when all classes defined by a particular
ClassLoader become unreachable and the ClassLoader too, do they become
eligible for GC at the same time.
In Roger's API, the class loader of those classes is bootstrap
classloader which never goes away, so any objects referenced by static
fields in bootstrap classes are never released.
Above code has a flaw even if the weakListeners ReferenceQueue is passed
to the CleanerThread via constructor parameter and immediately wrapped
by WeakReference, like:
private static class CleanerThread extends Thread {
WeakReference<ReferenceQueue<Object>> weakQueue;
CleanerThread(ReferenceQueue<Object> weakListeners) {
setDaemon(true); setPriority(Thread.MIN_PRIORITY);
weakQueue = new WeakReference<>(weakListeners);
}
public void run() {
ReferenceQueue<Object> queue = null;
while((queue = (queue == null ? weakQueue.get() : queue) !=
null) try {
Object dead = queue.remove(10000);
if(dead != null) {
// do stuff with "dead"
} else {
queue = null; // recheck to see if queue is gone.
}
} catch(InterruptedException woken) {
Thread.interrupted();
}
}
}
There is a big chance that this loop will run forever even after
'weakListeners' is not referenced from other parts of code any more. The
problem is the queue.remove(10000) call which spends 10 seconds waiting
for a Reference to be enqueued, which never happens, but keeps the
'queue' alive all that time. There's only a brief window of time between
'queue = null' assignment and 'weakQueue.get()' which re-obtains a
strong reference to the queue and happens periodically every 10
seconds.If GC never runs in this small window of opportunity, the
weakQueue will never be cleared and the thread will run forever.
Regards, Peter
More information about the core-libs-dev
mailing list