Understanding Phantom's help regarding weak assignment regarding reference queue
The link https://weblogs.java.net/blog/enicholas/archive/2006/05/understanding_w.html , PhantomReferences queued only if the item is physically removed from the memory and WeakReferences placed in a queue until the completion of the finalization or the garbage collection ...
The difference lies precisely in when the infection occurs. WeakReferences are queued as soon as the object they point to becomes weakly accessible. This is before finalization or garbage collection actually took place; in theory, the object could even be "resurrected" by the unorthodox finalize () method, but the WeakReference will remain dead. Only PhantomReferences when the object is physically removed from memory, and the get () method always returns null on purpose so that you cannot "resurrect" a nearly dead object.
whereas http://www.ibm.com/developerworks/library/j-refs/ , the PhantomReference is added to the ReferenceQueue before the heap object is freed, and WeakReferences are added to its ReferenceQueue after finalization or garbage collection.
Unlike soft and weak references, the PhantomReference is added to its ReferenceQueue before the heap object is deallocated. (Remember, all PhantomReference Objects must be created with an associated ReferenceQueue.) This allows action to be taken before the heap of the object is fixed.
When the finalize () method of a heap object is executed and memory is freed, the WeakReference object is added to its ReferenceQueue, if it exists.
I am embarrassed. Which one is correct?
Basically, I want to know the difference between weak and phantom reference regarding the reference queue?
source to share
In the ReferenceQueue:
Both the WeakReference and PhantomReference will be enqueued after their referent (reference object) is not strongly reachable if they have a non-null reference queue registered when they are created.
Before it is passed to enqueuing, the WeakReference clears (nullifies) the referent field to make the referent completely inaccessible. When the WeakReference is cleared, the application can no longer receive () the referent. This means that when a WeakReference is later queued, get () returns null. The WeakReference may have an unregistered reference queue when it was created. An application can determine if its referent, get (), is unavailable. Sometimes a reference queue is handy for managing WeakReferences when an application doesn't want to explicitly manage them.
PhantomReference does not clear the referent field before it is passed for enqueuing. When it is in the queue, the referent still refers to the PhantomReference. The referent is only cleared by the application explicitly after it discards the reference queue. If the application does not clear it, the referent will remain there until both of it and its PhantomReference are restored together. In any case, get () on PhantomReference always returns null, even if it is not cleared. Thus, the application cannot determine if its referent, get (), is unavailable. The application can only detect this by checking to see if the PhantomReference has been queued. For this reason, a PhantomReference must be created with a registered reference queue; Otherwise, it is useless.
On completion:
When the WeakReference is cleared, the referent becomes unavailable. If the referent has a finalizer other than the non-standard, it is subject to completion, so it must be resurrected. If the referent does not have a finalizer other than the standard one, it can be fixed by the GC. In other words, WeakReferences are processed before completion.
If the PhantomReference is only available through the PhantomReference, it is not yet available to the phantom. It is only ghostly available if it stays that way (only reachable via PhantomReference) upon completion. In other words, PhantomReferences are processed after completion. Only those referents who do not resurrect as a result of finalization are fantastically accessible, so they will definitely die. But since then PhantomReference will be queued, these referents are not dead yet. They only become available when PhantomReferences are removed later by the application, or PhantomReferences become unavailable (then PhantomReference and its referent become regenerated together.)
source to share