Java in-memory leak

I. Memory leaks due to expired references
Note: When the object is not used, the object is set to NULL, and this time the virtual machine does not necessarily release the memory, as to when the release is determined by the garbage collection algorithm.
When an object is not in use, it does not reclaim the possibility of a memory leak. There is a recommendation in effective Java to eliminate outdated object references.
Example: Memory optimization problem for stacks in JDK
1. Eliminate the reason for outdated object references (the reason for memory leaks): As the stack increases and then shrinks, objects coming out of the stack will not be recycled, even if the program does not reference those objects.
Because the outdated references to these objects are maintained inside the stack (references that expire are never dismissed).
2, Memory leak process: With the garbage collector's activity, or the memory consumption is increasing, the performance of the program will be slowly displayed. In extreme cases, the program is prone to oom errors.
The following program simulates the implementation of a stack in the JDK:

public class Mystack {private object[] elements;//stack is used to load elements of private int size = 0;//stack size private static final int defalt_init ial_capacity = 16;public Mystack () {elements = new object[defalt_initial_capacity];} /* * into stack */public void push (Object e) {ensurecapacity ();} /** * out Stack */public Object pop () {if (size==0) throw new Emptystackexception (); return elements[--size];} /** * Dynamically expands the stack space to ensure that there is enough space in the stack */private void ensurecapacity () {if (elements.length==size) {elements = arrays.copyof (elements , 2*size+1);}}}

Second, hashcode and memory leaks:

public class Memoryleakdemo {public static void main (string[] args) {point p1 = new Point; Point P2 = new Point (3,4); Point p3 = new Point (3,6); collection<point> C = new hashset<point> (); C.add (p1); C.add (p2); C.add (p3); C.add (p1);    System.out.println ("Number of original objects:" +c.size ());    P1.setx (5);    C.remove (p1); System.out.println ("Number of processed objects:" +c.size ());//There are three objects, two after deletion, and three after opening the comments above. }}class Point {private int x;private int y;public point (int x, int y) {super (); this.x = X;this.y = y;} public int GetX () {return x;} public void SetX (int x) {this.x = x;} public int GetY () {return y;} public void sety (int y) {this.y = y;} @Overridepublic int hashcode () {final int prime = 31;int result = 1;result = Prime * result + X;result = Prime * result + Y;return result;} @Overridepublic boolean equals (Object obj) {if (this = = obj) return true;if (obj = = null) return False;if (GetClass ()! = obj . GetClass ()) return false; Point other = (point) obj;if (x! = other.x) return false;if (Y! = Other.y) return False; return true;}} 

Originally there are 3 objects, after deletion there are 2, open the above comments, become 3. Why can't the object be deleted? Because after modifying the hashcode, the object's storage area changes (hash lookup basic idea: By computing the object's hash code, and then the hash code group, the object is stored in different regions, when the object needs only through the hash code to determine the object belongs to which storage area, thereby speeding up the search efficiency) , the object is not deleted after the Remove method is executed, so there are still so many elements. Memory leaks occur because the unused objects do not release the memory. Then, as the number of additions and deletions of the elements increased, the consumption of memory is increasing, resulting in an unexpected program end.

Java in-memory leak