Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>From <a href="https://web.archive.org/web/20061130103858/http://weblogs.java.net/blog/enicholas/archive/2006/05/understanding_w.html" rel="noreferrer">Understanding Weak References</a>, by Ethan Nicholas:</p> <blockquote> <p><strong>Weak references</strong></p> <p>A <em>weak reference</em>, simply put, is a reference that isn't strong enough to force an object to remain in memory. Weak references allow you to leverage the garbage collector's ability to determine reachability for you, so you don't have to do it yourself. You create a weak reference like this:</p> <pre><code>WeakReference weakWidget = new WeakReference(widget); </code></pre> <p>and then elsewhere in the code you can use <code>weakWidget.get()</code> to get the actual <code>Widget</code> object. Of course the weak reference isn't strong enough to prevent garbage collection, so you may find (if there are no strong references to the widget) that <code>weakWidget.get()</code> suddenly starts returning <code>null</code>.</p> <p>...</p> <p><strong>Soft references</strong></p> <p>A <em>soft reference</em> is exactly like a weak reference, except that it is less eager to throw away the object to which it refers. An object which is only weakly reachable (the strongest references to it are <code>WeakReferences</code>) will be discarded at the next garbage collection cycle, but an object which is softly reachable will generally stick around for a while.</p> <p><code>SoftReferences</code> aren't <em>required</em> to behave any differently than <code>WeakReferences</code>, but in practice softly reachable objects are generally retained as long as memory is in plentiful supply. This makes them an excellent foundation for a cache, such as the image cache described above, since you can let the garbage collector worry about both how reachable the objects are (a strongly reachable object will <em>never</em> be removed from the cache) and how badly it needs the memory they are consuming.</p> </blockquote> <p>And <a href="http://weblogs.java.net/blog/peterkessler/" rel="noreferrer">Peter Kessler</a> added in a comment:</p> <blockquote> <p>The Sun JRE does treat SoftReferences differently from WeakReferences. We attempt to hold on to object referenced by a SoftReference if there isn't pressure on the available memory. One detail: the policy for the "-client" and "-server" JRE's are different: the -client JRE tries to keep your footprint small by preferring to clear SoftReferences rather than expand the heap, whereas the -server JRE tries to keep your performance high by preferring to expand the heap (if possible) rather than clear SoftReferences. One size does not fit all.</p> </blockquote>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload