Java cleanup: Closure and garbage collection

Programmers know the importance of "initialization," but often forget the importance of purging. After all, who needs to clear an int? But for a library, it is not always safe to simply "release" an object when you are done with it. Of course, the Java free garbage collector reclaims the memory occupied by objects that are no longer in use. Now consider a very special and rare situation. Suppose our objects are assigned a "special" memory area and no new is used. The garbage collector only knows how to release the memory allocated by new, so it does not know how to release the "special" Memory of the object. To solve this problem, Java provides a method named Finalize () that can be defined for our class. Ideally, it should work like this: Once the garbage collector is ready to release the storage space occupied by the object, it first calls Finalize (), and the object's memory is actually reclaimed only in the next garbage collection process. So if you use Finalize (), you can do some important cleanup or clean-up work during garbage collection.
But it is also a potential programming pitfall, because some programmers (especially in the context of C + + development) may initially mistakenly assume that this function is definitely called when the "destructor" is used in C + + to destroy (erase) an object. But here it is necessary to distinguish between C + + and Java, because the objects of C + + are bound to be purged (and the elements of programming errors are removed), and Java objects are not necessarily "collected" as garbage. Or in other words:

Garbage collection does not mean "damage"!

If you can keep this in mind, the likelihood of stepping into a trap will be greatly reduced. It means that before we no longer need an object, some actions must be taken, and these actions must be taken by ourselves. Java does not provide a "break" or similar concept, so you must create an original method to use it for this cleanup. For example, suppose that in an object creation process, it paints itself on the screen. If you do not explicitly delete its image from the screen, it may never be erased. If a deletion mechanism is placed in finalize (), the object is taken as garbage, and the image first removes itself from the screen. But if it is not taken away, the image will be preserved. So the second point to keep in mind is:

Our object may not be taken away as rubbish!

It is sometimes possible to discover that an object's storage space will never be released, because its program is always close to the point of light space. If the program finishes and the garbage collector does not release the storage space for any objects we create, the resources are returned to the operating system as the program exits. This is a good thing, because garbage collection itself consumes some overhead. If you never use it, you never have to spend this part of the cost.