One, run-time memory
1.1 Program Counters
Function: Can be seen as the line number indicator of the sub-interface that the current thread executes. The bytecode interpreter works by changing the value of the counter to select the next byte-code instruction that needs to be executed, and the basic functions such as branching, looping, and exception handling need to rely on this counter to complete.
Note: If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed, and if it is the native method, this counter value is empty.
1.2 Virtual machine stack
Role: Describes the memory model that is executed by the Java method. When each method is created, a stack frame is created to store the local variable table, the Operation table, the dynamic link list, the method exit, and other information. Each method is called until the completion of the process, corresponding to a stack frame in the virtual machine stack from the go to the stack in the process.
Description: A local variable table holds the various basic data types, object reference types, and returnaddress types known to the compiler, and the memory space required to complete allocations during compilation.
Exception: 1) Stackoverflowerror exception, thrown when thread request is greater than the depth allowed by the virtual machine
2) OutOfMemoryError exception, if the virtual machine stack can be dynamically extended, when the extension cannot request enough memory to throw
1.3 Local Method Stack
Role: The local method stack is the native method service that is used for the virtual machine, and the virtual machine stack is the Java method service for the virtual machine
Note: Stackoverflowerror and OutOfMemoryError Exceptions will also be thrown.
1.4JAVA Heap
Function: An area of memory that is shared by all threads, used to hold object instances and arrays, created when the virtual machine is started.
Description: The Java heap is the primary area of garbage collector management, called the GC heap. Now the collector basically uses the Generational collection algorithm (divided into the new generation and the old age).
1.5 Method Area
Function: A piece of memory that is shared by all threads to store data such as class information, constants, static variables, and code compiled by the instant compiler that have been loaded by the virtual machine.
Description: 1) on the hotspot virtual machine, the method area is called the permanent generation, in essence, the two are not equivalent, hotspot is to use the permanent generation to implement the method area, for other virtual machines (BEA JRockit, IBM J9, etc.) there is no permanent generation concept.
2) do not need continuous memory and can choose to fix big lad extensible, can choose not to implement garbage collection. The memory recovery target for this area is primarily for the recovery of constant pools and the unloading of types
Exception: OutOfMemoryError exception that is thrown when the method area does not meet the memory allocation requirements.
1.6 (method area) run a constant-rate pool
Function: The run-time-constant pool is part of the method area. class file In addition to the type of version, fields, methods, interfaces and other information such as description. Another piece of information is a constant pool that holds the various literal and symbolic references generated during the compilation period, which are stored in the run-time pool of the method area after the class is loaded.
Description: 1) The Java Virtual Machine does not require any details to run the constant pool, and the different providers implement the virtual machine according to its own needs.
2) Generally, the symbols described in the stored class file are referenced and translated directly for drinking.
1.7 Direct Memory
Role: Not a part of the data go when the virtual runtime
2.1 Object Access
Object obj = new Object ();
The Object obj semantics are reflected in the local variable table of the Java stack, which appears as a reference type
The new object () semantics are reflected in the Java heap, forming a piece of structured memory that stores all instance data values of type object, and the length of the memory is not fixed, depending on the type and the object memory layout implemented by the virtual machine. In addition, the Java heap must contain address information that finds data for this object type (object type, parent class, implemented interfaces, methods, and so on), and these types of data are stored in the method area.
Because the reference type specifies only one reference to the object in the Java Virtual Machine specification, and does not define the way in which the reference should be located, and the specific location of the objects in the Java heap, different virtual machine implementations can access the object differently. There are two ways to access the mainstream: using handles and direct pointers.
Handle mode: The Java heap divides a piece of memory as a handle pool, and reference stores the handle address of the object, and the handle contains the individual address of the object instance data and the type data.
Pointer access: The layout of the Java heap object must consider how to place information about the access type data, the object address is stored directly in the reference.
Handle Mode Benefits: Reference stores a stable handle address that changes only the instance data pointer in the handle when the object is moved, and reference itself does not need to be modified.
Pointer Access benefits: Saves the implementation overhead of a pointer positioning, because object access is very frequent in Java, so this kind of overhead is significant. The SUN HotSpot virtual machine uses pointers for object access.
second, automatic memory management mechanism--java memory area and memory overflow exception
2.1 java Heap Overflow
Exception type: When Java heap memory overflows, the exception stack information "Java.lang.OutOfMemoryError" will follow the hint "Java heap space".
Resolution steps: 1) Analyze dump dump snapshots with memory image analysis tools such as Eclipse Memory Analyzer
2) Focus on whether the in-memory objects are necessary, that is, the memory leaks (memories Leak) or memory overflow (Overflow) are identified first.
3) If it is a memory leak, further by looking at the reference chain of the leaking object to the GC Roots, you can find out what path the leaking object is associated with the GC Roots and cause the garbage collector to not be automatically recycled.
4) If there is no leakage, that is, the objects in memory are still alive, it is time to check the virtual machine's heap parameters (-xmx and-XMS), and the machine physical memory to see if it can also be adjusted, from the code to check if there are some object cycle life cycle too long, holding the state of the situation is too long, Try to reduce the memory consumption during program run time.
2.2 Virtual machine stack and local method stack Overflow
Note: The hotspot virtual machine does not differentiate between the virtual machine stack and the local method stack, so the-xoss parameter (set local method stack size) exists but is not valid, and the stack capacity is only set by the-XSS parameter.
Exception type: 1) If the thread requests a stack depth greater than the maximum allowed depth for the virtual machine, the Stackoverflowerror exception is thrown.
2) throws a OutOfMemoryError exception if the virtual machine cannot request enough memory space in the expansion stack.
Analysis Description: Virtual machine stack + local method stack size (approx.) = (linux/windows) Total memory 2gb-xmx (maximum heap capacity)-MaxPermSize (maximum method area capacity)
In the case of not reducing the number of threads or replacing a 64-bit virtual machine, you can only exchange more threads by reducing the maximum heap and reducing the stack capacity.
2.3 Running a constant pool overflow
Analysis Description: String.intern () This native method, which is useful if the run-time-constant pool already contains a string equal to this string object, returns a String object that represents the strings in the pool, otherwise adds this object to the constant pool. and returns a reference to this string object. Because the run constant pool exists in the method area, you can limit the size of the method area through-xx:permsize and-xx:maxpermsize, thereby indirectly limiting the capacity of the constant pool.
Exception type: The message followed by OutOfMemoryError is "PermGen space" (indicating that the run-time-constant pool belongs to the method area)
2.4 Method Area Overflow
Overflow occurs when the runtime produces a large number of classes to fill the method area.
Exception generation: 1) When a large number of JSPs or dynamically generated JSP files (JSP needs to be compiled into a Java class for the first time).
2) OSGi-based applications (even the same class file, loaded by different loaders are considered different classes), etc.
2.5 Native Direct Memory overflow
Three, automatic memory management mechanism--garbage collector and memory allocation policy
3.1 Overview
Three things the GC needs to do:
1) What memory needs to be recycled?
2) when to recycle.
3) how to recycle.
3.2 object is dead.
3.2.1 Reference Counting algorithm
Algorithm: To add a reference counter to the object, whenever there is a place to reference it, the counter value is added 1: When the reference fails, the counter value is reduced by 1, any time the counter is 0 of the object is impossible to be used again.
Features: High efficiency and simple realization
Usage scenarios: such as Microsoft COM technology, the use of ACTIONSCRIPT3 's flashplayer, Python language, and in the game scripting World is widely used in squirrel in the use of reference counting algorithm for memory management. However, the Java language does not choose this method, mainly because it is difficult to solve the problem of mutual circular reference between objects.
3.2.2 Search algorithms
Algorithm: Through a series of objects named "GC Roots" as the starting point, starting from these nodes to search down, the path of the search is called the reference chain, when an object to the GC Roots no reference chain connected (that is, from the GC Roots to the object is unreachable), it proves that this object is not available.
In the Java language, objects that can be used as GC roots include the following:
1) The referenced object in the virtual machine stack (Jianzheng local variable table).
2) The object referenced by the class static property in the method area.
3) The object referenced by a constant in the method area
4) objects referenced by JNI (that is, generally speaking, native method) in the local method stack
Characteristics:
Usage scenarios: The current mainstream commercial programming language (Java and C #, even the old Lisp mentioned earlier) uses GC Roots tracing to determine whether an object is alive or not.
3.2.3 again on quoting
After JDK1.2, Java expands on the concept of references by dividing the references into (these four reference intensities gradually weaken in turn):
1) Strong reference: refers to the general existence of the program code, similar to Object obj = new Object (), such a reference, as long as the strong reference exists, the garbage collector will never reclaim the referenced object.
2) Soft references: Describes some objects that are also useful, but are not required. For objects associated with soft references, these objects are listed in the collection scope and recycled a second time before the system will have a memory overflow exception. If this collection still does not have enough memory, the memory overflow exception will be thrown. After JDK1.2, the SoftReference class is provided to implement the soft reference.
3) Weak reference: Used to describe a non-required object, but its strength is weaker than soft reference, and the object associated with the weak reference only survives until the next garbage collection occurs. When the garbage collector is working, the objects associated with a weak reference are reclaimed regardless of whether the current memory is sufficient.
4) Virtual reference: Also known as Phantom Reference or phantom reference, it is the weakest reference relationship. Whether an object has a virtual reference exists, does not affect its time-to-live, nor can it obtain an instance of an object through a virtual reference. The only purpose of setting a virtual reference association for an object is to expect to receive a system notification when the object is reclaimed by the collector.
3.2.4 Survive or die?
Objects that are unreachable in the root search algorithm are not "dead", and they are temporarily in the "probation" stage to actually declare an object to die, at least two times to mark the process:
1) If the object discovers that there is no reference chain connected to the GC roots after the root search, it will be marked for the first time and filtered for the condition that it is necessary for this object to execute the Finalize () method. When the object does not overwrite the Finalize () method, or the Finalize () method has been called by the virtual machine, the virtual machine treats both cases as "no need to execute".
2) If the object is judged to be necessary to execute the Finalize () method, then the object will be placed in a queue named F-queue, and then executed by a low-priority finalizer thread that is automatically created by the virtual machine at a later time. The so-called "execution" here means that the virtual opportunity triggers this method, but does not promise to wait for it to end (because, if an object executes slowly in the Finalize () method, or a dead loop occurs (more extreme cases), Will most likely cause other objects in the F-queue queue to be permanently waiting, or even cause the entire memory-recycling system to crash. The Finalize () method is the last chance for an object to escape the fate of death, and later the GC will make a second small-scale mark on the object in F-queue, if the object is to successfully save itself in Finalize ()---just to re-associate with any object on the reference chain. For example, you assign yourself (this) to a class variable or to a member variable of an object, and it is removed from the collection that is "about to be recycled" at the second mark, and if the object does not escape at this time, it is really not far from dead.
Note: The Finalize () method of any object will be called only once by the system, and if the object faces the next collection, its Finalize () method will not be executed again, so the second-stage code's self-help operation failed.
3.2.5 Recovery Method Area
The "Price/performance" of garbage collection in the method area is generally low, in the heap, especially in the Cenozoic, the general application of a garbage collection generally can reclaim 70%--95% space, and the permanent generation of garbage collection efficiency is much lower than this.
The garbage collection of the permanent generation mainly recycles two parts: obsolete constants and useless classes.
Determine if a constant is an "obsolete constant": Judging if the constants in the constant pool are referenced elsewhere, the system "please" out of the constant pool if it is not referenced. The symbolic references to other classes (interfaces), methods, and fields in a constant pool are similar.
Judging "Useless class": 1) all instances of the class have been reclaimed, that is, no instances of the class exist in the Java heap.
2) The ClassLoader that loaded the class have been recycled.
3) The corresponding Java.lang.class object of this class is not referenced anywhere, and the method of accessing the class can be accessed anywhere by reflection.
Virtual machines can reclaim useless classes that meet the above 3 criteria, just saying "yes", rather than having to use them as objects without necessarily recycling them. Whether the class is recycled, the hotspot virtual machine provides the-XNOCLASSGC parameters for control, and can also be used-verbose:class and-xx:+traceclassloading, + Traceclassunloading to view load and unload information for the class. -verbose:class and-xx:+traceclassloading can be used in the product version of the virtual machine, but the-xx:+traceclassloading parameter requires Fastdebug version of the virtual machine support.
3.3 garbage Collection algorithm
3.3.1 Tag-Purge algorithm
The algorithm is divided into "mark" and "clear" two stages: first mark out all the objects that need to be recycled, after the mark is complete, all the tagged objects are collected uniformly.
Disadvantage: One is the efficiency problem, the labeling and removal process is not efficient, and the other is the space problem, the mark after the purge will produce a lot of discontinuous memory fragmentation, too much space fragmentation may cause, When the program needs to allocate large objects in the future, it cannot find enough contiguous memory and has to trigger another garbage collection action in advance.
3.3.2 Copy algorithm
To solve the efficiency problem, a collection algorithm called "Replication" appears, which divides the available memory into two blocks of equal size, using only one chunk at a time, and when a piece of memory is exhausted, copies the surviving object to the other, then cleans up the used memory space once. In this way, each time it is a piece of memory recycling, memory allocation is not considered the complexity of memory fragmentation, as long as the mobile heap top pointer, in order to allocate memory, easy to implement, efficient operation. Just the cost of this algorithm is that the memory shrinks to half the original.
The default Eden and survivor size ratio of the hotspot virtual machine is 8:1, and each new generation of available memory space is 90% (10%+80%) of the entire Cenozoic capacity, and only 10% of the memory is "wasted". Of course, 98% of the objects can be recycled only in the general scenario of the data, there is no guarantee that each recovery will only be less than 10% of the objects survive, when the survivor space is not enough, you need to rely on other memory (refers to the old generation) to allocate security. If it is not sufficient, it will enter the old generation directly through the allocation of security mechanisms.
3.3.2 Labeling-Sorting algorithm
The replication collection algorithm performs more replication operations when the object has a higher survival rate and becomes less efficient. More crucially, if you do not want to waste 50% of space, you need to have additional space to allocate security, in order to deal with all the objects in the memory used in 100% survival extreme situation, so in the old age generally can not directly select this algorithm.
According to the characteristics of the old age, the "mark-and-sweep" algorithm is proposed, like the "Mark-sweep" algorithm, but the next step is not to organize the recyclable objects directly, but to let all surviving objects move toward one end, and then directly clean out the memory outside the end boundary.
3.3.3 Generational Collection algorithm
Divides the memory into several blocks depending on the life cycle of the object. One is to divide the Java heap into the new generation and the old age, so that the most appropriate collection algorithm can be used according to the characteristics of each age. In the new generation, each garbage collection found that a large number of objects died, only a small number of survival, then the use of replication algorithm, only a small number of surviving objects to pay the cost of replication can be completed collection. In the old age, because the object has a high survival rate and no extra space to guarantee it, it must be recycled using the "mark-clean" or "mark-sweep" algorithm.
3.4 Garbage collector
The collection algorithm is the method of memory recycle, and the garbage collector is the concrete implementation of memory recycle. Different vendors, different versions of the virtual machines provided by the garbage collector can be very different, and provide parameters for users according to their own application characteristics and requirements of the combination of the collectors used in various eras. Each collector can be used in conjunction with each other.
HotSpot JVM1.6 garbage collector
Note: There is a connection between the two garbage collectors that can be used together.
3.4.1 Serial collector----Cenozoic collector The serial collector is the most basic and oldest collector ever, and once (JDK1.3.1 ago) is the only option for virtual machine generation collection. is a single-threaded collector, not only that it uses only one CPU or one collection thread to complete the garbage collection work, but more importantly, when it comes to garbage collection, all other worker threads must be paused (sun will call this thing "Stop the World") until it collects the end. This work is actually automatically initiated by the virtual machine in the background and auto-completion, the user is not visible in the case of the user's normal working thread all stop, which is unacceptable for many applications.
3.4.2 parnew Collector---cenozoic collector
The Parnew collector is actually a multithreaded version of the Seral collector. In addition to using multithreading for garbage collection, the rest of the behavior includes all the control parameters available to the serial collector, the collection algorithm, the Stop the world, the object assignment rule, the recycle policy, and so on, all the same as the serial collector. Parnew the number of collection threads that are turned on by default is the same as the number of CPUs, and in a very large CPU environment, you can use the-xx:parallelgcthreads parameter to limit the number of threads that are garbage collected.
The Parnew collector is the preferred Cenozoic collector for many virtual machines running in server mode, one of which is performance-independent but important because, except for the serial collector, only it can work with the CMS collector at this time.
The CMS collector, launched during the JDK1.5 period, is the first real-world concurrency collector, and for the first time enables the garbage collection thread to work concurrently with the user thread (basically).
As the collector of the old age, unable to work with the new generation collector parallel scavnge that already existed in JDK1.4, so when using CMS in JDK1.5 to collect the old age, the Cenozoic can only select one of the Parnew or serial collectors.
Parallel (Parallel): Refers to multiple garbage collection threads working in parallel, but at this point the user thread is still in a wait state.
Concurrency (Concurrent): User threads are executed concurrently with the garbage collection thread (but not necessarily in parallel, may be alternately executed), the user program continues to run, and the garbage collector runs on the other CPU.
3.4.3 Parallel Scavenge Collector---new generation collector
The Parallel scavenge collector is also a new generation collector, a collector using a copy algorithm, and a parallel multi-threaded collector that looks the same as parnew. The goal of the parallel scavenge collector is to achieve a controllable throughput. The so-called throughput is the ratio of the CPU running user code to the total CPU elapsed time, that is, throughput = Run user code time/(run user code time + garbage collection time), the virtual machine runs for a total of 100 minutes, where garbage collection takes 1 minutes, the throughput is 99%.
The shorter the pause time, the more suitable for the need to interact with the user program, good response speed can improve the user experience, and high throughput can be the most efficient use of CPU time, as soon as possible to complete the operation of the program tasks, mainly suitable for in the background operation and do not need too many interactive tasks.
The Parallel scavenge collector provides two parameters for precise control of throughput, respectively, the maximum garbage collection pause time of-xx:maxgcpausemillis (greater than 0 milliseconds) parameter and the direct set throughput size of the-XX: The Gctimeratio parameter (an integer greater than 0 less than 100, which is the ratio of garbage collection time to total time, corresponds to the reciprocal of the throughput. If this value is set to 19, the maximum GC time allowed is 5% of the total time (that is, 1/(1+19)) and the default value is 99, which runs a maximum of 1% garbage collection Time).
Using the Parallel scavenge collector with adaptive adjustment strategy, the Memory Management tuning task to the virtual machine to complete is a good choice, just need to set the basic memory parameters such as-xmx set the maximum heap, Then use the Maxgcpausemillis parameter or the Gctimeratio parameter to set an optimization target for the virtual machine, and the adjustment of the detailed parameters is done by the virtual machine.
3.4.4 Serial Old collector----older generation collector
Serial old is an older version of the Serial collector, which is also a single-threaded collector using the "mark-and-organize" algorithm, which is also used by virtual machines in client mode. In the case of server mode, it has two major uses: one is used in conjunction with the parallel scavenge collector in the previous version of JDK1.5, and the other is the backup plan for the CMS collector, where the concurrent collection occurs concurrent Mode Use when failure.
3.4.5 Parallel Old collector---older generation collector
Parallel old is an older version of the Parallel scavenge collector, using multithreading and the "mark-and-organize" algorithm. This collector is only available in JDK1.6. The parallel scavenge plus parallel old collector is a priority in situations where throughput and CPU resource sensitivity are a concern.
3.4.6 CMS collector---old generation collector
The CMS (Concurrent Mark Sweep) collector is a collector that targets the shortest payback time and is implemented based on the "tag-purge" algorithm.
Collection process: 1) initial tag: Flag The object that the GC roots can directly relate to, fast
2) Concurrent tagging: The process of GC Roots tracing
3) Re-tagging: In order to fix the tag record of the part of the object that the tag has changed during the concurrent tagging process, the period of time is generally slightly longer than the initial marking phase, but is much shorter than the concurrent tag.
4) Concurrent Cleanup:
Where the initial tag, re-tagging this synchronicity step still requires "Stop the world", the initial tag is just to mark the GC Roots directly associated with the object, fast, the concurrent tagging phase is the process of GC Roots tracing, The re-tagging phase is to fix the tag record of the part of the object that caused the markup to change as the user program continues to work during the concurrency tag, which is typically slightly longer than the initial mark-up period, but is much shorter than the time of the concurrent tag.
The most time-consuming is the concurrency token and the concurrent cleanup process, and the collector thread can work with the user thread, so in general, the memory recycling process for the CMS collector is performed concurrently with the user thread.
Benefits of CMS: Concurrent collection, low pause.
CMS Disadvantages:
1) is very sensitive to CPU resources, which, while not causing the user thread to pause during the concurrency phase, will cause the application to slow down due to a portion of the thread, and the overall throughput will be reduced. The recycle thread that the CMS starts by default is (number of CPUs +3)/4 , that is, when the CPU is more than 4, the garbage collection thread consumes no more than 25% of the CPU resources when it is reclaimed concurrently. However, when the CPU is less than 4 (for example, 2), then the impact of the CMS on the user program can become very large, if the CPU load is relatively large, but also to separate half the computing power to execute the collector thread, it may cause the user program execution speed decreased by 50%. To solve this situation, the virtual machine provides an "incremental concurrency collector", the I-cms collector, which is a variant of the CMS collector, which allows GC threads and user threads to run alternately during concurrent tagging and concurrent cleanup, minimizing the time of the GC thread's exclusive resources, so that the entire garbage collection process is longer, However, the impact on the user program will appear less, the speed drop is not so obvious, but the current version of I-CMS has been declared as "deprecated".
2) The cms collector cannot handle floating garbage, and a "Concurrent Mode Failur" failure may occur resulting in another full GC. Because the CMS concurrent cleanup phase of the user thread is still running, along with the program's operation naturally there will be new garbage constantly generated, this part of the garbage appears after the tagging process, the CMS can not be processed in this collection, and had to leave the next GC to clean it up, this part of the garbage is called "floating garbage." Also because the user thread in the garbage collection phase still needs to run, that is, it also needs to reserve enough memory space for the user thread to use, so the CMS collector cannot wait for the old years to be almost completely filled up like the other collectors, and it needs to reserve a portion of the space for the program to run when it is collected concurrently. By default, the CMS collector will be activated after using 68% of the space in the old age, which is a conservative setting, and if the old age is not growing too fast in the app, you can increase the trigger percentage by setting the value of-xx:cmsinitiatingoccupancyfraction. To reduce the number of memory recoveries for better performance. If the memory reserved during the CMS operation does not meet the needs of the program, a "Concurrent Mode Failure" failure occurs, when the virtual machine will start a fallback plan: temporarily start the serial old collector to re-age garbage collection, so the pause time is very long. So the parameter-xx:cmsinitiatingoccupancyfraction set too high will easily lead to a large number of "Concurrent Mode Failure" failure, performance is reduced.
3) CMS is a collector based on the "tag-clear" algorithm, which means that there is a lot of space fragmentation at the end of the collection. When there is too much space debris, large objects will be assigned a lot of trouble, often the old age still has a lot of space remaining, but can not find enough contiguous space to allocate the current object, have to trigger a full GC in advance. To solve this problem, the CMS collector provides a-xx:+usecmscompactatfullcollection switch parameter for additional free defragmentation after "enjoy" the full GC service, and the process of memory grooming is not concurrent. The space debris problem is gone, but the pause time must not be longer. The virtual machine designers also provide another parameter,-xx:cmsfullgcsbeforecompaction, which is used to set the number of uncompressed full GC, followed by a compressed one at a time.
3.4.7 G1 Collector---generation, aging
The G1 collector is the forefront of current collector technology development, with two notable improvements compared to CMS: The G1 collector is a collector based on the "mark-and-organize" algorithm, meaning it does not produce space debris. The second is a very precise control of the pause, which allows the user to explicitly specify in a time fragment of a length of M milliseconds, the time spent on garbage collection should not exceed n milliseconds.
The G1 collector can achieve low-pause memory recovery without sacrificing throughput, because it can aggressively avoid garbage collection in secure areas, where the previous collector collects the entire new generation or the old age, and G1 the entire Java heap (including the Cenozoic, The old age) is divided into a number of fixed-size independent areas, and tracking the level of garbage accumulation in these areas, in the background to maintain a priority list, each time according to the collection time of the operation, priority to reclaim the most garbage areas, zoning and priority area recovery, The G1 collector is guaranteed the highest collection efficiency for a limited period of time.
3.4.8 Garbage Collector Parameters Summary
3.5 Memory allocation and recovery policy
Allocating memory is allocated on the heap, and the object is allocated primarily on the new generation of Eden, and if the local thread allocation buffer is started, it will be allocated on Tlab by thread precedence.
3.5.1 Object Precedence in Eden Assignment
In most cases, objects are allocated in the new generation of Eden, and when the Eden Zone does not have enough space to allocate, the virtual machine will initiate a minor GC.
-xx:survivorratio=8 determines that the space ratio between Eden and a survivor area in the Cenozoic is 8:1.
Minor GC (New generation GC): Refers to the garbage collection action occurring in the Cenozoic, because most Java objects have the characteristics of being born and going out, so the Minor GC is very frequent, and the general recovery speed is relatively fast.
Major Gc/full GC (old age GC): Refers to GC, which occurs in the old age, Major GC, often accompanied at least once minor GC (but not absolute, in the Parallelscaveng Collector's collection strategy is directly Major GC's policy selection process). Major GC is typically 10 times times slower than the minor GC.
3.5.2 large objects directly into the old age
A large object is a Java object that requires a lot of contiguous memory space, and the most typical large object is the long string and array. Large objects are bad news for the memory allocation of virtual machines, and often large objects tend to cause memory to have plenty of space to trigger garbage collection ahead of time to get enough contiguous space to "place" them.
The-xx:pretenuresizethreshold parameter, so that objects larger than this setting value are allocated directly in the old age. This is done to avoid a large amount of memory duplication between the Eden area and the two survivor zones.
Description: Pretenuresizethreshold parameter detachment serial and parnew two collector valid, Parallel scavenge collector does not recognize this parameter, Parallel scavenge collector generally do not need to set. If you encounter an occasion where this parameter must be used, you can consider Parnew plus the collection of CMS combinations.
3.5.3 long-term survival will enter the old age
Virtual machines Use the idea of generational collection to manage memory, and virtual machines give each object the top of an object age counter. If the object is still alive after Eden was born and after the first minor GC, and can be accommodated by survivor, it is moved to survivor space and the object age is set to 1. Object in the Survivor area each time minor GC, age increases by 1 years, when its age to a certain extent (by default, 15 years old), will be promoted to the old age. The age threshold of an object's promotion to the old is-xx:maxtenuringthreshold to be set.
3.5.4 Dynamic Object Age judgement
Virtual machines do not always require that an object's age must reach-xx:maxtenuringthreshold to be promoted to the old age, if the sum of all objects of the same age in Survivor space is greater than half the size of survivor space, Objects older than or equal to that age can go straight into the old age without waiting for the ages required in the xx:maxtenuringthreshold.
3.5.5 Space Allocation Guarantee
When the minor GC occurs, the average size of the virtual opportunity detection before each promotion to the old age is greater than the remaining space size of the old age, and if it is greater, then the full GC is changed directly, and if it is less then the Handlepromotionfailure setting allows the guarantee to fail If not, the minor GC will only be performed, and if not allowed, a full GC should be performed instead.
fourth. Virtual machine performance monitoring and fault handling tools
Reason for a long pause in threads: Wait for external resources (database connections, network resources, device resources, etc.), lock waits (live locks and deadlocks), dead loops.
3.3.1 Tag-purge algorithm
---------------------------not to be continued