There are different kinds of references in Java like strong, soft, weak, phantom etc. When you create a normal object using the new keyword and then assign it to a regular type, you are creating a strong reference. Garbage collector will only collect an object if there are no strong references to that object. Less strong references include soft, weak and phantom, and they are defined in the java.lang.ref package.

The java.lang.ref package

The package java.lang.ref provides reference-object classes: Reference, PhantomReference, ReferenceQueue, SoftReference and WeakReference. Even if an object is referenced by a reference object (without any other reference), the object may still be reclaimed by the collector, and the exact details differ for different reference objects. Reference-object classes thus allow us to do some interaction with the garbage collector. Reference is the abstract base class for all reference objects. You can find more details @ http://docs.oracle.com/javase/7/docs/api/java/lang/ref/package-summary.html.

Less strong references are just like any other object: they consume memory, space etc. The advantage of a less strong reference ( e.g. soft, weak etc.) over an object pool or a thread-local variable is that less strong references will be eventually reclaimed by the garbage collector even if you forget to remove them explicitely. The disadvantage is that, less strong references have a slightly greater impact on the efficiency of the garbage collector, as they are themselves objects that consume memory, space etc., and it takes at least two GC cycles for the less strong reference objects to be reclaimed by the garbage collector, and in most cases, it might be more than two cycles; the exact details regarding garbage collection of less strong references differ from one reference type to other.  

Soft references

If a soft reference is the only reference left to the referent object, the garbage collector can reclaim the object in the next GC cycle based on factors such as, if it hasn’t been used very recently and also the heap size left. Soft references will thus retain a reference to frequently used objects for more time after all other references are gone, avoiding need to create frequently used objects again and again, providing object reuse. Soft references can be considered as one large, least recently used (LRU) object pool.

Soft references are mainly used to create a cache  for frequently used objects; as requests tend to come in for certain items more often than for others and caching them will be good for performance.  For good performance, we need to make sure that they are cleared on a timely basis. Soft references should be used only when the referent object has a good chance of being reused in the future. Soft references work well when the number of objects is not too large. Otherwise, a traditional object pool with a bounded size, implemented as an LRU cache, will give better performance.

SoftRefLRUPolicyMSPerMB flag

A soft reference is cleared when there are no more strong references, and is also dependent on the objects's last access time, the total heap size left and the a flag SoftRefLRUPolicyMSPerMB, whose default value of 1,000. If the difference between current time and last access time is more than the product of the heap size left (in MB) and this flag, the object is reclaimed by GC. When amount of available heap size decrease, soft references are claimed more frequently. So, to reclaim soft references more frequently, we can decrease the value of this flag.

If the JVM completely runs out of memory, all soft references are first cleared before it may throw an OutOfMemoryError. This might throw away the cashed results unexpectedly. If you notice such a situation, to avoid that situation to happen again, you can try to reduce this flag value, which will allow to reclaim soft references more frequently.

If there is a lot of free heap available, and the soft references are infrequently accessed, you can increase this flag so that reclaiming will not happen frequently. However, you should be very careful not to use too many soft references, since they can easily fill up the entire heap. 

Out of memory due to GC overhead limit

An out of memory error may also occur if GC overhead limit is exceeded. This error is thrown when four conditions are met:

1. Time spent in full GCs exceed 98% (can be changed using flag: GCTimeLimit)
2. Memory reclaimed by full GC is less than 2% (can be changed using flag: GCHeapFreeLimit)
3. Above two conditions hold true for 5 consecutive Full GC cycles.
4. -XX:+UseGCOverheadLimit flag is not disabled (it is enabled by default).

If the first two conditions hold true for 4 consecuting full GCs, all soft references are freed before 5th full GC so that there is more chance that more than 2% of heap is freed (condition 2). However, this might throw away the cashed results unexpectedly. If you notice such a situation, as discussed before, you can try to reduce value of the flag SoftRefLRUPolicyMSPerMB, so that soft references will be reclaimed more frequently and avoid filling up.

Weak references

Weak referenced objects (referent objects) are freed at every GC cycle if there are no strong references to that referent object. However the weak reference (other reference types) will be freed only after atleast one GC cycle. Weak references (and other reference types) are also objects. If the referent object of the weak reference object is freed while the weak reference object is in the young generation, the weak reference object will be freed at the next minor GC. If the referent object had remained long enough, then the weak reference object might have been promoted into the old generation; in this case, the weak reference object will not be freed until the next concurrent or full GC cycle.

Weak references are most commonly used when the referent will be used by several threads simultaneously; otherwise, the weak reference is too likely to be reclaimed by the garbage collector.

Weak references and Collection classes

Collection classes are frequently the source of memory leaks in Java as an application usually puts objects into a collection object and never removes them, even though they are no longer needed. However, there are two impacts on performance while using weak references in a collection. First is that, it can impact garbage collection. Second impact is that, the class must periodically perform an operation to clear all the unreferenced data in the collection i.e., the class is responsible for processing the reference queue of the references it stores.

The JDK provides two classes with weak reference: WeakHashMap and WeakIdentityMap. Custom collection classes based on soft (and other) references are available from many third-party sources. 

WeakHashMap

The WeakHashMap class uses weak references for its keys. When the weakly referenced key is no longer available, the WeakHashMap code must clear out the value in the map that used to be associated with that key. This involves processing of the reference queue for the weak key and the value associated with any key on the reference queue is removed from the map.

Freeing of unreferenced weak references are carried out every time the map is referenced. The weak reference and its associated value won’t actually be freed until the map is used again. So if the map is used infrequently, the memory associated with the map won’t be freed as quickly as desired. Also, the performance of operations on the map is unpredictable. The operation on a WeakHashMap immediately after a GC will have to process the reference queue; that operation no longer has a fixed, short time.