The principle of strong, soft, weak, and virtual referencing of Java objects + caching of Java objects constructed with Referencequeue objects

Turn http://blog.csdn.net/lyfi01/article/details/6415726

1. Strong, soft, weak, and virtual references to Java objects in versions prior to JDK 1.2, if an object is not referenced by any variable, the program can no longer use the object. That is, only the object is in the accessible (reachable) state before the program can use it. This is like in daily life, after buying a certain item from the store, if it is useful, keep it, or throw it into the garbage bin and collect it from the cleaners.     Generally speaking, if the item has been thrown into the dustbin, it is impossible to pick it up again. But sometimes the situation is not so simple, you may encounter a similar chicken like the same items, food tasteless, discard. This kind of thing is useless now, keep it occupied space, but immediately throw it is not cost-effective, because it might come in handy in the future. For such dispensable items, a compromise of the treatment is: if the home space enough, first leave it at home, if the home space is not enough, even if the home of all the rubbish to remove, or can not accommodate those essential necessities of life, then throw away these dispensable items. 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. Object application Hierarchy 1⑴ strong reference (Strongreference) strong reference is the most common reference used. 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, the memory space is sufficient, the garbage collector does not reclaim 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 reference (WeakReference) weak reference differs from soft reference in that an object with only a weak reference has a more ephemeral life cycle. In the process of scanning the area of memory that the garbage collector thread governs, once an object with only a weak reference is found, it will be recycled regardless of the current memory spaceSave. 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 the form of a dummy, and several other references are different, the virtual reference does not determine the life cycle of the object. 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. Java object Accessibility In many cases, an object is not directly referenced from the root set, but an object is referenced by other objects, even by several objects, to form a tree with the root set as the top. 2 The tree structure in this tree-shaped reference chain, the direction of the arrow represents the direction of the reference, the object that is referred 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 by the accessibility of a single reference path: 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 employee letterAn example of an interest-tracking 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 If the use of soft reference softreference is characterized by an instance of it holding a soft reference to a Java object, 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 does a memory garbage collection, it does not start with a softreference reference to the objectThe object is retained at the end. 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 reclaiming these objects, we can pass: MyObject anotherref= (MyObject) Asoftref.get (), and regain a strong reference to the instance. After the collection, the call to get () method can only get null. 3.3 Using Referencequeue to clear the softreference that lost the soft reference object as a Java object, the SoftReference object has a generic Java object 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 you are creating a SoftReference object, use a Referencequeue object 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 is aThe non-strong objects It cares about are 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 common way is: softreference ref = NULL; while (ref = (EMPLOYEEREF) q.poll ()) = null) {//Clear ref} After understanding the work mechanism of referencequeue, we can start to construct a cache of Java objects. This article describes the concepts of strong, soft, weak, and virtual references to Java objects, their applications, and their representations in UML. 4.2 How to use Weakhashmap there is a special map type-weakhashmap in the Java collection where a weak reference to the key object is stored, and when a key object is reclaimed by the garbage collector, the reference to the corresponding value object is removed from the map. Weakhashmap can save storage space and can be used to cache data that is not required to exist. General usage of the map interface. In the following example, the main () method of the MapCache class creates a Weakhashmap object that holds a weak reference to a set of key objects, and the main () method also creates an array object that holds a strong reference to some of the key objects.     Import Java.util.WeakHashMap;         Class Element {private String ident;      Public Element (String ID) {ident = ID;      } public String toString () {return ident;      } public int hashcode () {return ident.hashcode (); } public boolean equals (Object obj) {return obj instanceof Element && ident.equals ((Element) obj      ). ident); } protected void Finalize () {System.out.println ("finalizing" +getclass (). Getsimplename () + "" +ident);      }} Class Key extends element{public Key (String ID) {super (ID);      }} class value extends element{public value (String ID) {super (ID);         }} public class Canonicalmapping {public static void main (string[] args) {int size=1000;         Key[] Keys=new key[size];         Weakhashmap map=new Weakhashmap ();             for (int i=0;i key K=new key (Integer.tostring (i));             Value V=new value (integer.tostring (i));             if (i%3==0) keys[i]=k;         Map.put (k, v);      } System.GC (); As can be seen from the print results, when the System.GC () method is executed, the garbage collector only reclaims key objects that only hold weak references. The ID can be a strong reference to a key object that is divisible by 3 and therefore will not be recycled. 4.3 using Weakhashmap to prevent leakage in the Socketmanager is easy, as long as the use of Weakhashmap instead of HashMap on the line. (This assumes that Socketmanager does not require thread safety). You can use this method when the life cycle of the map must be associated with the life cycle of the key. Repair Socketmanager with Weakhashmap. public class Socketmanager {private Map m = new Weakhashmap ();      public void SetUser (Socket s, User u) {m.put (S, u);      Public User GetUser (Socket s) {return m.get (s); }} 4.4 uses reference queues WEAKHASHMAP to host mapping keys with weak references, which allows applications to no longer use key objects when they can be garbage collected, and the Get () implementation can differentiate between dead mappings and live mappings based on whether weakreference.get () returns NULL. But this is only half the effort to prevent the memory consumption of the Map from increasing in the lifetime of the application, and some work needs to be done to remove the dead items from the map after the key object is collected. Otherwise, the MAP fills the item that corresponds to the dead key. While this is not visible to the application, it still causes the application to run out of memory. A reference queue is the primary method by which the garbage collector returns information about the object's life cycle to the application. A weak reference has a constructor that takes a reference queue as a parameter. If you create a weak reference with the associated reference queue, when the weak reference object becomes a GC candidate, the reference object is added to the reference queue after the reference is cleared (refer to the soft reference example above). Weakhashmap has a private method named Expungestaleentries (), which is called by most Map operations, removing all invalid references in the reference queue and deleting the associated mappings. 5. UML: Use association classes to indicate that a particular form of reference Association class can be used to indicate a particular form of reference, such as a weak (weak), soft (soft), or virtual (phantom) reference. 3.4 Caching of Java objects by means of soft-and object-regain methods the characteristics of the garbage collection mechanism of the JAVA2 platform and the above-mentioned method of garbage object regain, we use a small example of an employee information query system to illustrate how to build a cache to avoid the performance penalty of repeating building the same object.      We define an employee's profile as an employee class: public class Employee {private string id;//employee identification number private string name;//employee name Private string department;//the employee's department private string phone;//The Employee contact Phone private int salary;//The employee salary private String origin;//The source of the employee information//construction method public Employee (STR         ing ID) {this.id = ID;      Getdatafromlnfocenter (); }//Get employee information into the database private void Getdatafromlnfocenter () {//and database establish connection well query the employee for information, assign the query result//to name  , department,plone,salary and other variables//At the same time the origin is assigned to "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 private Employeecache cache;//a cache instance private Hashtable employeerefs;//with      Storage for Chche content private Referencequeue q;//garbage reference queue//inheritance softreference, so that each instance has an identifiable identity.      And the identity is the same as the key within the HashMap.            Private class Employeeref extends SoftReference {private String _key = ""; Public Employeeref (Employee em, refereNcequeue q) {super (EM, q);         _key = Em.getid ();         }}//build a cache instance private Employeecache () {employeerefs = new Hashtable ();      Q = new Referencequeue ();  }//Get cache instance public static Employeecache getinstance () {if (cache = = null) {cache = new         Employeecache ();      } return cache; }//Refer to an instance of an Employee object in a soft reference and save the reference to private void Cacheemployee (Employee em) {cleancache ();//Remove Trash         Reference Employeeref ref = new Employeeref (em, q);      Employeerefs.put (Em.getid (), ref);         }//Retrieve an instance of the corresponding employee object by 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, rebuild an instance,//andSave the soft reference to this new instance if (em = = null) {em = new Employee (ID); System.out.println ("Retrieve from Employeeinfocenter.             Id= "+ ID);         This.cacheemployee (EM);      } return em;         }//Clears those soft references that the employee object has been reclaimed by the Employeeref object private void Cleancache () {employeeref ref = NULL;         while (ref = (EMPLOYEEREF) q.poll ()) = null) {employeerefs.remove (Ref._key);         }}//Clears all content in the cache public void ClearCache () {Cleancache ();         Employeerefs.clear ();         System.GC ();      System.runfinalization (); }} 4. Using weak references to build a cache of non-sensitive data 4.1 global MAP caused memory leaks the most common reason for unconscious object retention is to associate metadata with a temporary object (transient object) using MAP. Assume that an object has a medium life cycle that is longer than the lifetime of the method call that is assigned it, but is shorter than the life cycle of the application, such as a socket connection for the client. Some meta data needs to be associated with this socket, such as the identity of the user who generated the connection. You do not know this information when you create the socket, and you cannot add data to the socket object because you cannot control the socket class or its subclasses. At this point, the typical approach is to store this information in a global map, as shown in the following Socketmanager class: Use a global map to associate metadata with an object. public class Socketmanager {private Map m = new HashMap();      public void SetUser (Socket s, User u) {m.put (S, u);      Public User GetUser (Socket s) {return m.get (s);      } public void Removeuser (Socket s) {m.remove (s); The problem with this approach is that the life cycle of the metadata needs to be tied to the life cycle of the socket, but unless you know exactly when the program no longer needs the socket, and remember to remove the corresponding mapping from the map, the socket and User objects will remain in the map forever, much more than in response to the request and The time that the socket was closed. This prevents the Socket and User objects from being garbage collected, even if the application no longer uses them. These objects are left out of control and can easily cause the program to run out of memory after a long period of time. In almost all cases, it is annoying and error-prone to find out when the Socket is no longer being used by the program, except in the simplest case, requiring manual memory management.

　　

The principle of strong, soft, weak, and virtual referencing of Java objects + caching of Java objects constructed with Referencequeue objects