What is the JVM? To explain this first:
JVM is a Java Virtual Machine, which is the core part of the entire Java platform implementation. All Java programs will be first compiled into. Class class files, which can be executed on the Virtual Machine, that is, class does not directly correspond to the operating system of the Machine. Instead, the virtual machine interacts with the operating system indirectly, and the virtual machine interprets the program to the local system.
The JVM is the foundation of the Java platform and, like a real machine, has its own set of instructions and operates on different areas of memory at run time. By abstracting the operating system and CPU structure, the JVM provides a platform-independent way of executing code that is independent of a particular implementation, host hardware, or host operating system. The main job of the JVM is to interpret its own instruction set (that is, bytecode) into the CPU’s instruction set or corresponding system call, protecting the user from malicious programs. The JVM doesn’t care about the upper-level Java source files; it only cares about the class files (.class files) generated by the source files.
The JVM stack
The JVM stack is thread private. Each thread is created with the JVM stack, which holds variables of the local primitive types in the current thread. Boolean, char, byte, short, int, long, float, double), partial return results, and Stack frames. Objects of non-basic types only hold one address on the JVM Stack that points to the heap.
Under Windows, a stack is a low-address data structure, a contiguous area of memory. On WINDOWS, the stack size is fixed (a constant determined at compile time). Overflow will be prompted if the stack size exceeds the amount of space left on the stack. Therefore, less space can be obtained from the stack. As long as the remaining stack space is larger than the requested space, the system will provide memory for the program; otherwise, an exception will be reported indicating stack overflow.
Heap (Heap)
It is the area where the JVM stores object instances as well as array values, and it can be considered that memory for all objects created by New in Java is allocated there, while memory for objects in Heap is waiting for GC to collect.
(1) The heap is shared by all threads in the JVM, so the allocation of object memory on it needs to be locked, which also leads to the relatively high overhead of new objects
(2) In order to improve the efficiency of object memory Allocation, Sun Hotspot JVM will allocate an independent space TLAB (Thread Local Allocation Buffer) for the created threads. The size of TLAB is calculated by THE JVM according to the running situation. There is no lock required to allocate objects on TLAB, so the JVM tries to allocate memory on TLAB when allocating objects on thread. In this case, the PERFORMANCE of allocating object memory in JVM is almost as efficient as that of C, but if the object is too large, it still uses heap space allocation directly
(3) TLAB only applies to Eden Space of the new generation, so when Java programs are written, it is usually more efficient to allocate multiple small objects than large objects.
(4) All newly created objects will be stored in the new Generation of Yong Generation. If data from the Young Generation survives one or more GCS, it will be transferred to the OldGeneration. New objects are always created in Eden Space.
JVM garbage Collection
Basic principle of Garbage Collection (GC) : Memory object is no longer used in recycling, for recycling in the GC method known as collector, because the GC need to consume some resource and time, Java in through analysis of the characteristics of the object’s lifecycle, according to the new and old generation way to collect object, by as much as possible to shorten the GC pause for application
(1) The collection of objects of the new generation is called minor GC;
(2) Collection of old generation objects is called Full GC;
(3) The program actively calls system.gc () to force the gc to be Full GC.
Different types of object references are collected in different ways by GC. References to JVM objects fall into four types:
(1) Strong references: By default, objects are strongly referenced (instances of this object are not referenced by other objects, and will only be recycled during GC).
(2) Soft references: Soft references are an application provided in Java that is suitable for caching scenarios (GC only when memory is low).
(3) Weak references: must be collected by the GC
(4) Virtual references: Since virtual references are only used to tell if an object is GC
The difference between a memory leak and an overflow
-
A memory leak is when allocated memory cannot be reclaimed.
-
An overflow of memory occurs when a program requires more memory than the system can allocate. For example, storing 10000 data in a byte variable is an overflow.
-
Memory overflow is not enough memory provided; A memory leak is an inability to provide memory resources.
When a memory leak occurs:
1) Static set class:
Be careful when using collection classes such as Set, Vector, HashMap, etc. Memory leaks can occur. When these collections are defined as static, since they have a lifetime as long as the application, memory leaks can occur.
2) Listener:
In Java, we often use listeners, such as addOnClickListener() for a control, but often forget to remove listeners when releasing objects, which can cause memory leaks. A good idea is to remember to release all listeners when releasing objects, so that you can avoid memory leaks caused by listeners.
3) Various connections:
Connections in Java, including database connections, network connections, and IO connections, are not automatically closed without explicitly calling their close() method and cannot be reclaimed by GC resulting in memory leaks. In general, this type of memory leak can be avoided by creating connections in the try block and releasing connections in finally.
4) References to external modules:
Care should also be taken to prevent memory leaks when calling external modules. For example, module A calls A method of external module B, such as public void Register (Object O). This method might cause module A to hold A reference to the object passed in. In this case, check whether module B provides A method to remove the reference, such as unregister(). This is easy to ignore, and memory leaks are harder to detect, and should be addressed during code writing.
5) Singleton mode:
Memory leaks are also possible when using the singleton pattern. Because a singleton persists for the lifetime of the JVM after initialization, if it holds a reference to an external object (with a shorter lifetime), that external object cannot be reclaimed, resulting in a memory leak. If the external object also holds references to other objects, the memory leak is even worse, so you need to pay special attention to such cases. In this case, you need to consider whether there is a problem with the design of the singleton pattern and how to ensure that memory leaks do not occur.