Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 385
  • Last Modified:

What is the difference between Weakly Reachable and Softly Reachable Objects?

What is the difference between Weakly Reachable and Softly Reachable Objects?
This obscure memory manage  set of classes is fully understandable except for these oddly almost identically sounding reachabilites presumably represented by the Classes java.lang.ref.SoftReference and
java.lang.ref.WeakReference

However  maybe its just me but the following makes little sense to me in determining the differences:
Right from Oracle.com's own website
•      An object is softly reachable if it is not strongly reachable but can be reached by traversing a soft reference
(My comment added - like the class of SoftReference??

•      An object is weakly reachable if it is neither strongly nor softly reachable but can be reached by traversing a weak reference. When the weak references to a weakly-reachable object are cleared, the object becomes eligible for finalization.

See my dilema as the Softly reachable is defined by not being Weakly reachable and vise versa - A real catch 22 unless you really understand the nuance there.
Here is an example of use of the SoftReference class:
e.g http://www.programcreek.com/java-api-examples/index.php?api=java.lang.ref.SoftReference
SoftReference-eg.txt
0
Robert Silver
Asked:
Robert Silver
  • 3
  • 2
1 Solution
 
dpearsonCommented:
My understanding of this is that they are very nearly the same.  That the distinction is how the garbage collector behaves.  If you have only get a WeakReference to an object then it *will* be garbage collected on the next pass.  If you have a SoftReference to the object then it *may* be garbage collected on the next pass.

So you use a WeakReference when you want to get the memory back as soon as nobody else is using it.
You use a SoftReference when you're OK with it staying in memory but can survive if it leaves (a cache is a classic example).

Does that help clarify the difference?

Doug
0
 
Robert SilverSr. Software EngineerAuthor Commented:
So the real difference comes into play with Caches ? Yes?  basically I could enqueue(Add to the ReferenceQueue and stick my weak and soft references into that queue and the Weak reference will be collected as garbage even though a reference may be in in th ReferenceQueue? But a Soft reference if it has a reference in the ReferenceQueue and in addition a Cache then it will not be collected as garbage?
I may now be even more confused by your answer unless I can put together what truly defines a WeakReference Object and
what defines a SoftReference Object. They could not have been more confusing at Sun/Oracle if they tried.
How would the java.lang.ref classes look disassembled I wonder would that maybe confuse me further?
Perhaps Sun/Oracle gave us the different reference classes to avoid the confusion but I still do not see the capabilities or how they should behave deterministically speaking.
0
 
dpearsonCommented:
Yeah I think I may have confused you.

The decision about whether something is available to be garbage collected or not is the same for both WeakReferences and SoftReferences.  I'll try some pseudo code and see if that helps.

// Let's create one object and 3 references to it:
A strong = new A() ;
WeakReference<A> weak = new WeakReference<A>(strong) ;
SoftReference<A> soft = new SoftReference<A>(strong) ;

// Here, the object cannot be garbage collected because
// we have a strong reference to it.
System.gc() ;
assert (strong != null && weak.get() != null && soft.get() != null) ;

// Clear the strong reference
strong = null ;

// Now the object *can* be garbage collected
// because there are no strong references to it - just weak and soft.

// So let's trigger a gc
System.gc() ;

// The object should still be in memory because we have a soft reference to it
// and we have plenty of memory, so the garbage collector doesn't throw it away.
assert (soft.get() != null && weak.get() != null) ;

// So let's clear the soft reference and gc again
soft = null ;
System.gc() ;

// The object should now be gone from memory because all we have at this
// point is just a weak reference.  The soft reference is gone.
// And if you only have a weak reference, the gc should clear it immediately.
assert(weak.get() == null) ;

Open in new window


Just to be clear that code above may actually turn out to be wrong :)  I've not tried it, but it does capture my mental model of the differences between the two types of references.

So the decision of whether something *can* be garbage collected or not is the same for soft or weak, in that once you no longer have a strong reference to the object, then it *can* be garbage collected.

The difference is once it can be garbage collected, whether it will or will not.
For a weak reference, it *will* be garbage collected once it can be.
For a soft reference, it *may* be garbage collected once it can be.

Any clearer?

Doug
0
 
Robert SilverSr. Software EngineerAuthor Commented:
Absolutely!  You are suggesting different degrees of gc collectability(just made that up) so given that scenario you made it clear that the SoftReference object when reachable keeps the WeakReference Object because its the same object  but once the SoftReference has been nulled - System.gc() now has the ability to remove both SoftReference and WeakReference
and again WeakReference objects really have no staying powers - They are super temporary in nature alive (not null)
until the next System.gc() is called  - Yes???
0
 
dpearsonCommented:
Yes I think you've got it.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now