Variables in Java Foundation can be primitive data types and reference data types. The process of variables in jvm after class loading is discussed here.
Variables are divided into instance variables, static variables, local variables. Personally, I need to pay attention to two points for variables: 1, scope 2, life cycle.
Instance variables - are initialized when the class is instantiated, and the life cycle is consistent with the instance of the class, that is, when the object disappears, the instance variable also disappears; the scope extends to the object itself, that is, where the object is, where is the instance variable. So it seems that, in terms of memory distribution in jvm, it is in heap memory.
Static variables - are initialized during the class loading process, and the life cycle is consistent with the program, that is, when the program is closed, the static variable will disappear; the scope extends to the program scope. In this way, in the memory distribution in the jvm, it is in the method area.
Local variables - are initialized when the method is called, and the life cycle is consistent with the method, that is, if the method fails, the local variables will also disappear; the scope extends to the scope of the method. In this way, in the memory distribution in the jvm, it is in the stack and has exclusive attributes.
At this time, we talk about the difference between a variable being a basic data type and a reference data type:
when it is a basic data type, the JVM will directly allocate space, and this space can be reused. According to the scope of the variable, the JVM will store it in the corresponding memory. Find the literal value, if you find it and return it directly, the basic data type has a reference relationship with this memory space.
When it is a reference type, the jvm will allocate space according to the command. Here is dynamic allocation. The size of the space and whether it can meet the allocation requirements will only be announced in the running phase. At this time, the objects of the reference type are stored in the heap memory, and only the reference relationship is retained in the scope of the variable. The wrapper classes for basic data types are discussed here. Except for floating-point types, others implement constant pool technology. Therefore, when the wrapper class is encountered, when the size is less than 127, the allocated space is in the constant pool of the method area.
Next, let's talk about gc. Constantly allocating space also needs to reclaim space, otherwise there will be a memory leak problem or insufficient memory.
Memory leak problem: Note: 1, whether the space in memory is referenced, 2, whether this space is useful. If a piece of space is useless, but still referenced, the jvm will think that the space cannot be reclaimed. This is a memory leak.
Similarly, if new space is constantly allocated in the memory, the old space cannot be reclaimed, and there will be insufficient memory.
Based on the above analysis, let's talk about the algorithm of gc to calculate and recycle objects:
1. Reference counting algorithm, count the number of references, when the number of references is 0, such an object can be recycled.
2. The reachability analysis algorithm analyzes the reachable path of the current object to a defined root point. If it does not exist, such an object can be recycled.
For references, we need to talk about the division of java, which is
divided into 4 types, 1, strong references, that is, references with clear declarations, will never be recycled by gc, 2, soft references, useful but not necessary objects, will be in the The jvm has insufficient memory space to perform secondary gc, 3, weak reference, the life cycle is before the next gc, 4, virtual reference, cannot be referenced to obtain an instance, and will not affect the life cycle.
GC recycling is mainly for heap memory, the constant pool in the method area.
You can view the current jvm related information directly through the jdk native command.