When you have finished using an object, you don't have to tell Java that it's no longer needed. Java works this out automatically.
In C, you do this by calling a function called free. In Visual Basic, you're meant to set the object equal to null to expressly clear the reference of the object. If you don't do this, then the memory that is being used to store the object will never be released. Even when your program finishes running the memory will still be in use. The only way to free it up is going to be to restart your computer. If the computer is a web server, well, we really don't want to have to restart it.
This type of fault is called a memory leak. Because your program is actually compromising [不宜泄露的], the integrity of the computer it is running on. If you're running programs with a memory leak, then over time more and more of your computer's memory will get used up. And over time your computer will start to slow down. Eventually it will crash.
Java decided to solve this problem by being a so-called managed language.
Memory leaks should be avoided because firstly,Java runs on a virtual machine. The point here is that when you call the new keyword in Java to create a new object, you aren't actually taking memory from the operating system. The memory is acquired by the virtual machine. Now the virtual machine is actually just another computer program written in C. The C program will control the request for memory for objects from the operating system and it controls the freeing of memory when objects are no longer needed.
We can think of the virtual machine as deciding when to put in the call to the free function that C needs to release memory. And it's pretty safe to assume that the designers of the virtual machine have correctly ensured there are no leaks in this implementation. If there were some leaks, well they're be plenty of bug reports about it and I'm sure we'd know. So if we assume that the virtual machine is correctly implemented, an operating system level memory leak in Java should be impossible.
The second way that Java avoids memory leaks is with the strategy of garbage collection.
The idea of garbage collection is that programmers ask for objects to be allocated on the heap but do not need to free them when they're finished with. Instead, an automatic process analyzes the heap and aims to work out which objects are no longer needed. And any unneeded objects can be deleted. Java works out which objects are no longer needed using a simple rule. Any object on the heap which cannot be reached through a reference from the stack is eligible for garbage collection.
situation 1: unreached object
situation2: connection lost
situation3: none of object get reachable
Such 3 situations are all eligible for garbage collection. The important point here is that Java works out which objects are eligible for garbage collection and this is not something that is our responsibility as a programmer to control.