Re: Peterson's Algorithm in java, sequencial instruction execution ?
"Daniel Pitts" <googlegroupie@coloraura.com> wrote in message
news:1164611576.917554.15090@l12g2000cwl.googlegroups.com...
Mike Schilling wrote:
"Daniel Pitts" <googlegroupie@coloraura.com> wrote in message
news:1164602190.486099.4240@h54g2000cwb.googlegroups.com...
Mike Schilling wrote:
OK. Can you give me an example of how you'd use a PhantomReference
programmatically? I've asked this before on the n.g, and never gotten
an
answer.
Usually you would extends PhantomReference with your own custom class,
and register it with a reference queue, so you know when the object it
was referencing has gone away.
Its a very edge case, usually you would use WeakReference (such as in
WeakHashMap)
If you look at the WeakHashMap implementation in Sun's JDK, each Entry
object extends WeakReference, where the referenced object is the value
of the Entry.
When would you use PhantomReference instead? The exaplnation given in
the
Javadoc:
Phantom references are most often used for scheduling pre-mortem
cleanup actions in a more flexible way than is possible with the Java
finalization mechanism.
is opaque to me.
I don't know. Most likely you will know when you need to use it when
you come across something you can't do any other way.
I interpret the Javadoc's explanation as "Phatom References allow you
to clean up after objects are ready to be garbage collected, without
the risk of reintroducing the refered Object back into the reachable
object graph (and therefore delaying garbage collection of that object).
The differences between PhantomReference and WeakReference are:
1. The phantom reference is not queued until the object has been finalized,
while the weak reference may be queued before finalization.
2. Weak references are cleared by the GC before being queued, while phantom
references are not.
3. It isn't possible to get an object from a phantom reference (get() always
return null), while it is possible to get an object from a weak reference.
(Not after the weak reference in enqueued, of course: see 2.)
4. A phantom reference much be part of a queue, while a weak reference need
not be.
4 follows from 3: a phantom reference that's not in a queue would be
useless. Otherwise, the differences can be summarized as:
o - A weak reference tells you whether the object is active or not. If
get() returns true, it's active. If not (and it never will after being
enqueued), it's inactive, though there's no way to tell whether it's
finalizable, finalized, or deleted.
o - A phantom reference, by being enqueued, tells you specifically that the
object has been finalized but not yet deleted.
I can *almost* see why I'd want to know that the object has been finalized.
I have no idea why I'd care that it hasn't been deleted yet.