Soft reference SoftReference

This article describes the concepts of strong, soft, weak, and virtual references to objects, their applications, and their representations in UML.

1. Strong, soft, weak, and virtual references to objects
In previous versions of JDK 1.2, if an object was not referenced by any variable, the program could no longer use the object. That is, only the object is in the accessible (reachable) state before the program can use it. Starting with JDK version 1.2, the reference to the object is divided into 4 levels, giving the program more flexibility in controlling the object's life cycle. These 4 levels are high to low in order: Strong references, soft references, weak references, and virtual references. Figure 1 applies the class hierarchy to the object.

Figure 1

⑴ Strong references (strongreference)
Strong references are the most commonly used references. If an object has a strong reference, the garbage collector will never recycle it. When there is not enough memory space, the Java virtual Machine prefers to throw a outofmemoryerror error, which causes the program to terminate abnormally, and does not rely on random recycling of strongly referenced objects to resolve out-of-memory issues.

⑵ Soft Reference (SoftReference)

If an object has only soft references, enough memory space is available, the garbage collector does not recycle it, and if the memory space is insufficient, the memory of those objects is reclaimed. The object can be used by the program as long as it is not reclaimed by the garbage collector. Soft references can be used to implement memory-sensitive caches (see below for an example).

A soft reference can be used in conjunction with a reference queue (Referencequeue), and if the object referenced by the soft reference is reclaimed by the garbage collector, the Java Virtual machine will add the soft reference to the reference queue associated with it.

⑶ Weak references (weakreference)

The difference between a weak reference and a soft reference is that an object with only a weak reference has a shorter life cycle. As the garbage collector thread scans the area of memory it governs, once an object with only a weak reference is found, its memory is reclaimed, regardless of whether the current memory space is sufficient or not. However, because the garbage collector is a low-priority thread, it is not necessarily quick to discover objects that have only weak references.

A weak reference can be used in conjunction with a reference queue (Referencequeue), and if the object referenced by the weak reference is garbage collected, the Java virtual machine adds the weak reference to the reference queue associated with it.

⑷ Virtual Reference (phantomreference)

"Virtual Reference", as the name implies, is a dummy, unlike several other references, a virtual reference does not determine the object's life cycle. If an object holds only virtual references, it can be reclaimed by the garbage collector at any time, just as there are no references.

Virtual references are primarily used to track activities that objects are reclaimed by the garbage collector. One difference between a virtual reference and a soft reference and a weak reference is that the virtual reference must be used in conjunction with the reference queue (Referencequeue). When the garbage collector prepares to reclaim an object, if it finds that it has a virtual reference, it will add the virtual reference to the reference queue associated with it before reclaiming the object's memory.

Referencequeue queue = new Referencequeue ();
Phantomreference PR = new Phantomreference (object, queue);

The program can see if the referenced object is going to be garbage collected by judging whether the reference queue has been added to the virtual reference. If the program discovers that a virtual reference has been added to the reference queue, it can take the necessary action before the memory of the referenced object is reclaimed.

2. The judgment of the accessibility of objects

In many cases, an object is not directly referenced from the root set, but an object is referenced by other objects and even referenced by several objects, forming a tree with the root set as the top. As shown in Figure 2

In this tree-shaped reference chain, the direction of the arrow represents the direction of the reference, and the object that is pointed to is the referenced object. As can be seen from the graph, from the root set to an object can be a number of paths. For example, the path to object 5 has ①-⑤,③-⑦ two paths. This leads to the question of how the accessibility of an object is judged:

Single Reference Path accessibility judgment: In this path, the weakest reference determines the accessibility of the object.
Multiple reference Path accessibility judgments: In several paths, the strongest of the references determines the accessibility of the object.

For example, we assume that the reference ① and ③ in Figure 2 are strong references, ⑤ is a soft reference, ⑦ is a weak reference, and for object 5 according to these two principles, the path ①-⑤ takes the weakest reference ⑤, so the path reference to object 5 is a soft reference. Similarly, ③-⑦ is a weak reference. The strongest reference is taken between the two paths, and object 5 is a soft and accessible object.

3. Building a cache of sensitive data using soft references

3.1 Why you need to use soft references

First, we look at an example of an employee information query system. We will use an employee information query system implemented in the Java language to query employee profile information stored in a disk file or database. As a user, we may have to go back and look at employee profile information that was viewed a few minutes or even seconds ago (again, we often use the back button when we browse the Web page). At this point we usually have two ways of implementing the program: one is to keep the employee information viewed in the past in memory, the life cycle of each Java object that stores the employee profile information throughout the application, and the other is when the user starts to view the profile information of the other employee, Ends a reference to the Java object that stores the currently viewed employee profile information, allowing the garbage collection thread to reclaim the memory space it occupies, and reconstruct the employee's information when the user needs to browse the employee's profile information again. Obviously, the first implementation will result in a lot of memory waste, and the second implementation is flawed even if the garbage collection thread has not been garbage collected, the object containing the employee profile information is still intact in memory, and the application is rebuilding an object. We know that access to disk files, access to network resources, query databases and other operations are important factors affecting the performance of application execution, if you can regain those who have not yet been recycled Java object references, will reduce unnecessary access, greatly improve the speed of the program.

3.2 How to use soft references

The SoftReference feature is that an instance of it holds a soft reference to a Java object, and the existence of the soft reference does not prevent the garbage collection thread from reclaiming the Java object. That is, once SoftReference has saved a soft reference to a Java object, the Get () method provided by the SoftReference class returns a strong reference to the Java object before the garbage thread recycles the Java object. Also, once a garbage thread reclaims the Java object, the Get () method returns NULL.

Look at the following code:

MyObject aRef = new? MyObject ();
SoftReference asoftref=new SoftReference (AREF);

At this point, for this MyObject object, there are two reference paths, one is a soft reference from the SoftReference object, and one is a strong reference from the variable areference, so this MyObject object is a strong object.

We can then end Areference's strong reference to this MyObject instance:

ARef = null;

Since then, the MyObject object has become a soft and accessible object. If the garbage collection thread is in memory garbage collection, it does not always retain the object because it has a softreference reference to the object. The Java Virtual machine's garbage collection thread treats soft-and object-and other generic Java objects differently: The cleanup of soft and object is determined by the garbage collection thread according to its memory requirements based on its particular algorithm. That is, the garbage collection thread reclaims the soft objects before the virtual machine throws OutOfMemoryError, and the virtual machine takes priority to reclaim the soft objects that are unused for long periods of time, and the "new" soft-anti-objects that have just been built or used are retained by the VM as much as possible. Before we recycle these objects, we can pass:

MyObject anotherref= (MyObject) asoftref.get ();

Regain a strong reference to the instance. After the collection, the call to get () method can only get null.

3.3 Use Referencequeue to clear the softreference that lost the soft reference object

As a Java object, the SoftReference object has the generality of Java objects in addition to the particularity of saving soft references. So, when a soft and an object is recycled, although the get () method of the SoftReference object returns NULL, the SoftReference object no longer has the value of being present and requires an appropriate cleanup mechanism. Avoid memory leaks caused by a large number of SoftReference objects. The Referencequeue is also available in the Java.lang.ref package. If a SoftReference object is created, a Referencequeue object is used as the constructor for the softreference, such as:

Referencequeue queue = new? Referencequeue ();
Softreference?ref=new? SoftReference (amyobject, queue);

Then when the SoftReference soft-referenced amyohject is reclaimed by the garbage collector, ref's strongly referenced SoftReference object is included in the Referencequeue. That is, the object saved in Referencequeue is the reference object, and it is the reference object that has lost the object it is soft referenced. Also from the name of Referencequeue, it is a queue, when we call its poll () method, if this queue is not empty queue, then will return the queue in front of the reference object.

At any time, we can call Referencequeue's poll () method to check if there are non-strong objects that it cares about being recycled. If the queue is empty, a null is returned, otherwise the method returns a reference object in front of the queue. Using this method, we can check which softreference the soft reference object has been recycled. So we can get rid of the SoftReference objects that have lost the soft reference object. The usual ways are:

SoftReference ref = NULL;

while (ref = (EMPLOYEEREF) q.poll ()) = null) {
Clear ref
}

After understanding Referencequeue's working mechanism, we can begin to construct a cache of Java objects.

3.4 Caching of Java objects through soft-and object-regain methods

Using the features of the JAVA2 platform garbage collection mechanism and the above method of garbage object regain, we illustrate how to construct a cache to avoid the performance loss caused by duplicate building of the same object through a small example of an employee information query system. We define an employee's profile information as an employee class:

public class Employee {
* String id;//Employee's identification number
* String name;//Employee Name
* String department;//the employee's department
* String phone;//the employee contact number
* int salary;//the employee's salary
* String origin;//The source of the employee's information

Construction method

Public Employee (String ID) {
This.id = ID;
Getdatafromlnfocenter ();
}

Get employee information in the database

* void Getdatafromlnfocenter () {
Establish a connection well with the database query the employee's information and assign a value to the query result
Give name,department,plone,salary and other variables
At the same time, origin is assigned the "from DataBase"
}

......

The employee class is constructed in a way that we can foresee if you need to query an employee's information every time. It takes a lot of time to rebuild an instance if it's just been queried in a few seconds. The following is a definition of the cache for the Employee object:

Import Java.lang.ref.ReferenceQueue;
Import java.lang.ref.SoftReference;
Import java.util.Hashtable;

public class Employeecache {
static * Employeecache cache;//a cache instance
* hashtable< string,employeeref> employeerefs;//for storage of Chche content
* referencequeue< employee> q;//Garbage Reference queue

Inherit the softreference so that each instance has an identifiable identity.
* Class Employeeref extends softreference< employee> {
* String _key = "";
Public Employeeref (Employee em, referencequeue< employee> q) {
Super (EM, q);
_key = Em.getid ();
}
}

Building a cache instance
* Employeecache () {
Employeerefs = new Hashtable ();
Q = new Referencequeue ();

}

Get the Cache instance

public static Employeecache getinstance () {
if (cache = = null) {
cache = new Employeecache ();
}
return cache;

}

References an instance of an employee object in a soft-reference manner and saves the reference
* void Cacheemployee (Employee em) {
Cleancache ();//Clear garbage references
Employeeref ref = new Employeeref (em, q);
Employeerefs.put (Em.getid (), ref);
}

Retrieves an instance of the corresponding employee object, based on the specified ID number
Public Employee GetEmployee (String ID) {
Employee em = null;
Whether there is a soft reference to the employee instance in the cache, if any, obtained from a soft reference.
if (Employeerefs.containskey (ID)) {
Employeeref ref = (Employeeref) employeerefs.get (ID);
EM = (Employee) ref.get ();
}

If there is no soft reference, or if the instance obtained from the soft reference is NULL, an instance is rebuilt,
and save a soft reference to the new instance

if (em = = null) {
EM = new Employee (ID);
System.out.println ("Retrieve from Employeeinfocenter. Id= "+ ID);
This.cacheemployee (EM);
}
return em;
}

* void Cleancache () {
Employeeref ref = NULL;
while (ref = (EMPLOYEEREF) q.poll ()) = null) {
Employeerefs.remove (Ref._key);
}
}

Clear all content in cache

public void ClearCache () {
Cleancache ();
Employeerefs.clear ();
System.GC ();
System.runfinalization ();
}

}

Note: The original referencequeue has a * effect, when the Softreference.get () method is found to return a null value, it will register the SoftReference in their own queue, When we call Referencequeue's poll () method, the SoftReference is returned and deleted.