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.

"Mike Schilling" <mscottschilling@hotmail.com> wrote or quoted in
Message-ID: <Bxoah.15796$Sw1.9105@newssvr13.news.prodigy.com>:

As far as I know,  PhantomReference can be used for cleanup.

For example ..

<code_0>

//
// Suppose that Resource R must be cleaned up after used.
//

class Resource_Bank {

   Resource loan() {
       ...
       return R;  
   }

   void refund(Resource R) {
       // Clean up R
   }
}

class Customer {

   void X...(..) {
       R = resource_Bank.loan();
       ...
   }
   
   void Y..(..) {
       ...
       resource_Bank.refund( R );
   }
}
</code_0>

For some reason, if Customer lose the reference of R before
she refunds R, Resource leak will occur.  

To prevent this situation, the following code is possible:

<code_1>

class Resource_Wrap {
   Resource R = ....;    
   ...
   protected void finalize() ... {
       // Clean up R          
   }
}
</code_1>

But ...
If the cleanup process of R take long time, GC may exert
a harmful influence upon the performance of App.

Therefore, the following code will be better:

<code_2>

//
// Data structure, thread-safe etc were ignored to simplify
// this "code_2".
//

class Resource_Wrap {
   Resource R = ....;    
   ...
   Resource getR() {
       return R;
   }
}

class Phantom extends PhantomReference<Resource_Wrap> {
   
   Resource R;    

   public Phantom(Resource_Wrap RW, ReferenceQueue<...> rq) {

       super(RW, rq);
       R = RW.getR();
   }

   Resource getR() {
       return R;
   }
}

class Resource_Bank {

   // Resource R0, R1, ... , Rn

   ReferenceQueue<Resource_Wrap> rq = ...;
   final int MAX_NUMBER = ...;
   Resource_Wrap[] rw = ...;
   Phantom[] pm = ...;

   void initialize() {

       for (int i = 0; i < MAX_NUMBER; ..) {
            rw[i] = new Resource_Wrap( ... );  // Ri
            pm[i] = new Phantom( rw[i], rq );
       }
   }

   Resource_Wrap loan() {
       
      for ( ... ) {
          if ( .. )  {
               Resource_Wrap RW = rw[i];            
               rw[i] = null;  // if Customer lose RW,
                                // she will become phontom.
               return RW;  
          }
      }
      ....
   }

   void refund(Resource_Wrap RW) {
       // Clean up R
   }

   void cleanupDaemon() {

       Thread tr = new Thread() {
            public void run() {            
                while (true) {                
                    Phantom RW = (Phantom) rq.remove();
                    Resource R = RW.getR();
                    ... // Clean up R
                    ... // Clean up RW
                 }
            }
       };
       .....
   }
}
</code_2>

In addition to the above case,
I think that there will be other cases.

I'd say that practically every application where you either don't want to,
don't need to, or don't want /to/ need to, make the object itself know about,
or carry knowledge needed for, the cleanup.

I.e. when you want to track object's lifetimes for their effect on some /other/
object, but have (otherwise) no interest in the objects themselves.

For instance, say you allocate objects on behalf of some group of customers.
You want (for whatever arcane reason) to track how many objects are still
(roughly) alive for each customer.  This is an accounting-like tracking, and
the objects themselves have no interest in either the tracking or in which
customer they are active on behalf of.  So you use a phantom reference for each
object, which also contains (by subclassing) a reference to the customer.  Thus
you can do the accounting for each customer without messing around with the
objects themselves, and do it (I presume, but don't know for sure) more
efficiently and with less chance of awkward interactions with finalisation than
if you'd used the same architecture but with weak refs.

   -- chris