....
2.2.1 Where to save it
When the program is running, it is best to know where the data is stored. Of particular note is the allocation of memory. There are six places where data can be saved:
(1) Register. This is the fastest save area because it's in a different place than all other saves: inside the processor. However, the number of registers is very limited, so registers are allocated by the compiler as needed. We don't have direct control over this, and it's impossible to find any trace of the register's existence in our own program.
(2) Stack. Residing in a regular RAM (random access memory) area, but with direct support for processing through its "stack pointer". Moving the stack pointer down creates new memory; moving it up frees that memory. This is a particularly fast and efficient way to save data, second only to registers. When creating a program, the Java compiler must know exactly the "length" and "how long" of all data held on the stack. This is because it has to generate the corresponding code to move the pointer up and down. This limitation undoubtedly affects the flexibility of the program, so although some Java data is kept on the stack - especially object handles, Java objects are not placed there.
(3) Heaps. A general-purpose memory pool (also in the RAM area) in which Java objects are kept. Unlike the stack, the most appealing aspect of the "memory heap" or "heap" is that the compiler does not have to know how much storage space to allocate from the heap, nor how long the stored data will stay in the heap. Therefore, you get more flexibility when saving data with the heap. To create an object, just use the new command to compile the relevant code. When these codes are executed, the data is automatically saved in the heap. Of course, this flexibility comes at a price: it takes longer to allocate storage in the heap!
(4) Static storage. "Static" here means "at a fixed location" (although also in RAM). During program execution, statically stored data will be waiting to be called at any time. The static keyword can be used to indicate that a particular element of an object is static. But Java objects themselves are never placed into static storage.
(5) Constant storage. Constant values are usually placed directly inside program code. It's safe to do so because they never change. Some constants require strict protection, so consider placing them in read-only memory (ROM).
(6) Non-RAM storage. If the data is completely independent of a program, it can exist when the program is not running and is outside the control of the program. Two of the prime examples are "Streaming Objects" and "Fixed Objects". For streaming objects, the object becomes a stream of bytes, usually sent to another machine. Whereas for fixed objects, the object is kept on disk. They can maintain their state even if the program is terminated. A particularly useful trick for these types of data stores is that they can exist in other media. They can even be restored to normal, RAM-based objects if needed. Java 1.1 provides support for Lightweight persistence. Future versions may even offer a more complete solution.
4.4.2 Builder initialization
Here it is necessary to summarize the object creation process. Consider a class called Dog:
(1) When an object of type Dog is created for the first time, or when the static method/static field of the Dog class is accessed for the first time, the Java interpreter must find Dog.class (search in the pre-set class path).
(2) After Dog.class is found (it will create a Class object, which will be learned later), all its static initialization modules will run. Therefore, static initialization happens only once - when the Class object is first loaded.
(3) When creating a new Dog(), the construction process of the Dog object will first allocate enough storage space for a Dog object in the memory heap (Heap).
(4) This storage space is cleared to zero, setting all primitive types in Dog to their default values (zero for numbers, and their boolean and char equivalents).
(5) All initializations that occur when field definitions are made are performed.
(6) Execute the builder. As will be discussed in Chapter 6, this can actually require quite a bit of work, especially when inheritance is involved.