Java memory leaks common situation

A memory leak means that an object or variable that is no longer being used by a program is occupied in memory. Java has a garbage collection mechanism that ensures that an object is no longer referenced, that is, when an object becomes orphaned, and the object is automatically purged from memory by the garbage collector. Because Java uses a graph-like approach to garbage collection management, you can eliminate the problem of reference loops, such as having two objects that reference each other, so that GC can recycle them as long as they are not up to the root process.

The following are a list of common memory leak problems that are caused by:

A long lifecycle object holding a reference to a short lifecycle object is likely to have a memory leak. Although a short lifecycle object is no longer needed, because the long lifecycle object holds its reference and cannot be reclaimed, this is the scenario where memory leaks occur in Java, which is, in layman's sense, the creation of an object by a programmer And never use this object again, this object has always been referenced, that is, this object is useless but cannot be reclaimed by the garbage collector, this is the case of memory leaks in Java, for example, caching system, we loaded an object into the cache (for example, in a global map object), It is then never used, and the object has been cached for reference, but it is no longer used.

If the method of an instance object of an external class returns an instance object of an inner class, the inner class object is long referenced, even if the Outer class instance object is no longer in use, but because the inner class holds an instance object of the outer class (The Inner class object has a reference to the Outer class object), can be used to easily access members and methods of external classes, and this external class object will not be garbage collected, which can also result in memory leaks.

An array-based stack memory leak problem. The main feature is to empty the stack of an element, instead of taking it out of the array, you're reducing the total number of stores, and I can write better than that, and when I get rid of an element, let it disappear from the array and set the value of the location of that element to null.

public class Stack {
    private object[] elements=new object[10];
    private int size = 0;
    public void push (Object e) {
   	 ensurecapacity ();
   	 elements[size++] = e;
    }
    Public Object pop () {
    if (size = = 0)
	throw new Emptystackexception ();
    		return elements[--size];
    }
    private void Ensurecapacity () {
    if (elements.length = = size) {
        object[]oldelements = elements;
          elements = newobject[2 * elements.length+1];
         System.arraycopy (oldelements,0, elements, 0, size);}}

The above principle should be very simple, if the stack adds 10 elements and then all of them bounce out, although the stack is empty, there is nothing we want, but this is an object that cannot be recycled because the reference to the stack element in the array still exists, that is, the array object holds the reference to the elements in the stack, But these objects are actually useless, but cannot be recycled. This meets the memory leak of the two conditions: useless, can not be recycled.

The following is an improvement to the stack, eliminating the problem of memory leaks.

Class Mnode<t> {private T value = null;
   Private mnode<t> Next;
      Public Mnode (T value) {this.value = value;
   next = null;
   Public T GetValue () {return value;
   public void SetValue (T value) {this.value = value;
   Public mnode<t> GetNext () {return next;
   public void Setnext (mnode<t> i) {this.next = i;
   } public class Mybetterlinkedstack<t> {private mnode<t>;
   private int size;
      Public Mybetterlinkedstack () {this.first = null;
   this.size = 0; @SuppressWarnings ("unchecked") public <T> Boolean push (T t) {if (t==null) throw new Runti
      Meexception ("cannot pass in null value");
      Mnode NewNode = new mnode<t> (T);
      Newnode.setnext (a);
      i = NewNode;
      size++;
   return true;
      @SuppressWarnings ("unchecked") Public <T> T POPs () {if (size==0) return null; Mnode R = i;
      i = First.getnext ();
      size--;
      T result = (t) r.getvalue ();
      R = null;
     
   return result;
   public int GetSize () {return this.size;
   public Boolean IsEmpty () {return size = = 0;
 
      }/** * @param args */public static void main (string[] args) {//TODO Auto-generatedmethod stub
      Mybetterlinkedstack Mbls = new Mybetterlinkedstack ();
      Mbls.push ("haha");
      Mbls.push ("hehe");
      System.out.println (Mbls.getsize ());
      System.out.println (Mbls.pop ());
   System.out.println (Mbls.pop ()); }
}

Another case of memory leaks: When an object is stored in a hashset (HashSet is based on a HashMap) collection, you cannot modify the fields in the object that participate in the computed hash, otherwise The modified hash value of the object is different from the hash value originally stored in the HashSet collection, in which case the result of the object cannot be found even if the Contains method uses the current reference of the object as an argument to retrieve the object in the HashSet collection. This can also cause memory leaks by not deleting the current object individually from the HashSet collection.