Concept analysis of heap, Stack, Chang in Java

When the program runs, it's best to know where the data is stored. A special note is the allocation of memory. There are six places where you can save data:

(1) Register

This is the fastest save area because it is located in a different place than all other ways of saving: inside the processor. However, the number of registers is very limited, so the registers are allocated by the compiler as needed. We have no direct control over this, nor can we find any trace of the register in our own program.

(2) Stacks (stack)

A reference to a basic type of variable data and an object, but the object itself is not stored in the stack, but is stored in the heap (the new object) or in a constant pool (the string constant object is stored in a constant pool. ) resides in the general RAM (random access memory) area, but it can be directly supported by its "stack pointer" for processing. If the stack pointer moves down, the new memory is created, and if you move up, the memory is freed. This is a particularly fast, particularly effective way to save data, second only to registers. When you create a program, the Java compiler must know exactly the "length" and "time of existence" of all data saved in the stack. This is because it must generate the appropriate code to move the pointer up and down. This restriction undoubtedly affects the flexibility of the program, so although some Java data is stored in the stack-especially the object handle-the Java object is not placed in it.

(3) Heaps (heap)

Stores all new objects, a general-purpose memory pool (also in the Ram area), where Java objects are stored. Unlike stacks, the most appealing aspect of the heap is that the compiler does not have to know how much storage to allocate from the heap, or how long the stored data will stay in the heap. As a result, there is greater flexibility in storing data with heaps. When you require an object to be created, you only need to compile the relevant code with the new command. When the code is executed, the data is saved automatically in the heap. Of course, there is a certain price to be paid to achieve this flexibility: it takes longer to allocate storage space in the heap!

(4) Static storage

Holds static members (statically defined), where "static" means "in fixed position" (albeit also in RAM). During the run of the program, the data that is stored statically is always waiting to be called. The static keyword can be used to indicate that a particular element of an object is static. However, the Java object itself will never be placed in static storage space.

(5) Constant storage

Holds string constants and basic type constants (public static final). The constant value is usually placed directly inside the program code. It is safe to do so, because they will never change. Some constants need to be strictly protected, so consider placing them in read-only memory (ROM).

(6) Non-RAM storage

If the data is completely independent of a program, the program can still exist when it is not running and outside the control of the program. The two most important examples are "streaming objects" and "fixed objects". For streaming objects, the object becomes a byte stream, which is usually sent to another machine. For fixed objects, objects are saved on disk. Even if the program is aborted, they can still keep their state intact. A particularly useful technique for these types of data stores is that they can exist in other media. Once needed, they can even be restored to normal, ram-based objects. Java 1.1 provides support for the lightweight persistence. Future versions may even provide a more complete solution

Here we are primarily concerned with stacks, heaps, and constant pools, which can be shared for objects in stacks and constant pools, and not for objects in the heap. The data size and life cycle in the stack can be determined, and the data disappears when no references point to the data. The garbage collector is responsible for the collection of objects in the heap, so the size and life cycle do not need to be determined and have great flexibility.
For strings: References to their objects are stored in the stack, and if the compilation period has been created (defined directly in double quotes), it is stored in a constant pool, which is stored in the heap if the run-time (new) is determined. For a string equal to equals, there is always only one copy in the constant pool, with multiple copies in the heap.
such as the following code:

java code string  s1 =   Span class= "hljs-string" > "China" ;   string  s2 =  "China" ;   string  s3 =  "China" ; string  ss1 = new     String  ( "China" ); string  ss2 = new     String  ( "China" ); string  ss3 = new    String  ( "China" ); 

String S=new string ("China");
S is a reference to an object, stored in a stack, which is a reference to the variable data and objects that hold the base type
New String ("China"); Is the object itself (that is, the object), stored in the heap (new object)
China is stored in a constant pool, where the string constant object is stored in a constant pool. ）

Here is an explanation of the yellow 3 arrows, for a string created by new (assuming "China"), will first go to the constant pool to find if there is already a "China" object, if not a constant pool to create this string object, and then create a constant pool in the heap in this "China" The Copy object of the object. This is the way of the interview: string s = new string ("xyz"), how many objects are produced? One or two, if there is no "xyz" in the constant pool, it is two.
For variables and constants of the underlying type: variables and references are stored in the stack, and constants are stored in the constant pool.
such as the following code:

Java代码int9;   int9;   int9;    publicstaticfinalint9;   publicstaticfinalint9;   publicstaticfinalint9;  

For member variables and local variables: member variables are external to the method, variables defined internally by the class, and local variables are variables defined inside a method or statement block. Local variables must be initialized.
The formal parameter is a local variable, and the data for the local variable exists in the stack memory. Local variables in the stack memory disappear as the method disappears.
Member variables are stored in objects in the heap and are collected by the garbage collector.
such as the following code:

Java code class BirthDate {Private intDayPrivate intMonthPrivate intYear Public BirthDate(intDintMintY) {day = D;            month = m;       Year = y; }//Omit the Get,set method ...} Public classtest{ Public Static void Main(String args[]) {intDate =9; Test test =NewTest ();            Test.change (date); BirthDate d1=NewBirthDate (7,7,1970); } Public void Change1(inti) {i =1234; }  }

For this code, date is a local variable, i,d,m,y is a local variable, and Day,month,year is a member variable. The following analysis of the code execution time changes:
1. The main method begins execution: int date = 9;
Date local variables, underlying types, references, and values are present in the stack.
2. Test test = new test ();
Test is an object reference, exists in the stack, and the object (new Test ()) exists in the heap.
3. Test.change (date);
I is a local variable, and the reference and value exist in the stack. When the method change execution is complete, I will disappear from the stack.
4. BirthDate d1= new BirthDate (7,7,1970);
D1 is an object reference, exists in the stack, the object (new BirthDate ()) exists in the heap, where D,m,y is stored in the stack for local variables, and their type is the underlying type, so their data is also stored in the stack. Day,month,year are member variables that are stored in the heap (new BirthDate ()). When the birthdate construction method finishes executing, the d,m,y disappears from the stack.
After the 5.main method executes, the date variable, TEST,D1 reference will disappear from the stack, new test (), new BirthDate () will wait for garbage collection.

Original address:
Http://www.cnblogs.com/madonion/articles/2253369.html

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Concept analysis of heap, Stack, Chang in Java