Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What is the structure of JVM memory?

2025-01-17 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what is the structure of JVM memory". In daily operation, I believe many people have doubts about the structure of JVM memory. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what is the structure of JVM memory?" Next, please follow the editor to study!

Preface

All Java developers may encounter this kind of confusion? How much space should I set for heap memory? Which area of run-time data is involved in the exception of OutOfMemoryError? How to solve it?

In fact, if you often solve server performance problems, then these problems will become very common, understanding JVM memory is also for the server performance problems can quickly understand the memory area of the problem, in order to quickly solve the production failure.

First look at a picture, this picture can clearly illustrate the layout of JVM memory structure.

There are three main blocks of JVM memory structure: heap memory, method area and stack. Heap memory is the largest piece of JVM made up of the young and the old, while the younger generation is divided into three parts, Eden space, From Survivor space and To Survivor space. By default, the younger generation is allocated according to the 8:1:1 ratio.

The method area stores class information, constants, static variables and other data, which is shared by threads. In order to distinguish it from the Java heap, the method area also has an alias Non-Heap (non-heap). The stack is divided into java virtual machine stack and local method stack, which is mainly used for method execution.

Through a picture to understand how to control the memory size of each area through parameters.

Control parameters

-Xms sets the minimum space size of the heap.

-Xmx sets the maximum space size of the heap.

-XX:NewSize sets the minimum space size of the new generation.

-XX:MaxNewSize sets the maximum space size of the new generation.

-XX:PermSize sets the minimum space size of the permanent generation.

-XX:MaxPermSize sets the maximum space size of the permanent generation.

-Xss sets the stack size for each thread.

The parameters of the old age are not directly set, but the heap space size and the Cenozoic space size can be set to control indirectly.

Old space size = heap space size-younger generation space size

Looking at the relationship between JVM and system calls again from a higher dimension

Method areas and pairs are areas of memory shared by all threads; java stacks, native method stacks, and programmer counters are areas of memory that are private to threads.

Let's describe the role of each region in detail below.

Java heap (Heap)

For most applications, the Java heap (Java Heap) is the largest block of memory managed by the Java virtual machine. The Java heap is an area of memory shared by all threads and is created when the virtual machine starts. The sole purpose of this memory area is to store object instances, where almost all object instances allocate memory.

The Java heap is the main area managed by the garbage collector, so it is often called the "GC heap". From the perspective of memory recovery, because the current collectors basically use generation-by-generation collection algorithms, the Java heap can also be subdivided into: new generation and old age; more detailed are Eden space, From Survivor space, To Survivor space and so on.

According to the Java virtual machine specification, the Java heap can be in physically discontiguous memory space, as long as it is logically continuous, just like our disk space. When implemented, it can be either fixed size or extensible, but the current mainstream virtual machines are implemented according to extensibility (controlled by-Xmx and-Xms).

If there is no memory in the heap to complete the instance allocation, and the heap can no longer be expanded, an OutOfMemoryError exception will be thrown.

Method area (Method Area)

Like the Java heap, the method area (Method Area) is a memory area shared by each thread, which is used to store class information, constants, static variables, compiled code and other data that have been loaded by the virtual machine. Although the Java virtual machine specification describes the method area as a logical part of the heap, it has an alias called Non-Heap (non-heap), which is supposed to distinguish it from the Java heap.

For developers who are used to developing and deploying programs on the HotSpot virtual machine, many people like to call the method area "Permanent Generation". In essence, the two are not equivalent, simply because the design team of the HotSpot virtual machine chooses to extend the GC generational collection to the method area, or to use permanent generation to implement the method area.

The Java virtual machine specification has very loose restrictions on this area, and you can choose not to implement garbage collection in addition to not requiring contiguous memory and having the option of fixed size or expandability like the Java heap. Relatively speaking, garbage collection behavior is relatively rare in this area, but it is not that the data enters the method area as "permanent" as the name of the permanent generation. The goal of memory recovery in this area is mainly aimed at constant pool recovery and type unloading. Generally speaking, the recovery "results" of this area are not satisfactory, especially type unloading, and the conditions are very harsh. But the recovery of this part of the area is really necessary.

According to the Java virtual machine specification, an OutOfMemoryError exception will be thrown when the method zone cannot meet the memory allocation requirements.

The method area is sometimes referred to as PermGen.

All objects are stored in heap memory for the entire run cycle after instantiation. Heap memory is divided into different parts: Eden, Survivor Sapce, and Old Generation Space.

The execution of methods is accompanied by threads. Local variables and references of the original type are stored in the online stack. Reference-associated objects, such as String, exist in the heap. To better understand the above paragraph, we can look at an example:

Import java.text.SimpleDateFormat;import java.util.Date;import org.apache.log4j.Logger; public class HelloWorld {private static Logger LOGGER = Logger.getLogger (HelloWorld.class.getName ()); public void sayHello (String message) {SimpleDateFormat formatter = new SimpleDateFormat ("dd.MM.YYYY"); String today = formatter.format (new Date ()); LOGGER.info (today + ":" + message);}}

The data of this program is stored in memory as follows:

Through the JConsole tool, you can view some information about running Java programs (such as Eclipse): allocation of heap memory, number of threads, and number of loaded classes

Program counter (Program Counter Register)

A program counter (Program Counter Register) is a small piece of memory that can be seen as a line number indicator of the bytecode executed by the current thread. In the conceptual model of virtual machines (only the conceptual model, various virtual machines may be implemented in some more efficient ways), the bytecode interpreter works by changing the value of this counter to select the next bytecode instruction to be executed, and basic functions such as branching, looping, jump, exception handling, thread recovery and so on all rely on this counter.

Because the multithreading of the Java virtual machine is realized by the thread switching in turn and allocating the processor execution time, at any given moment, a processor (a core for a multi-core processor) will only execute instructions in one thread. Therefore, in order to restore to the correct execution position after thread switching, each thread needs to have an independent program counter, and the counters between each thread do not affect each other and store independently. We call this kind of memory area "thread private" memory.

If the thread is executing a Java method, the counter records the address of the executing virtual machine bytecode instruction; if the Natvie method is being executed, the counter value is Undefined.

This memory region is the only one that does not specify any OutOfMemoryError conditions in the Java virtual machine specification.

JVM stack (JVM Stacks)

Like program counters, the Java virtual machine stack (Java Virtual Machine Stacks) is thread-private and has the same life cycle as threads. Virtual machine stack describes the memory model of Java method execution: when each method is executed, a stack frame (Stack Frame) is created at the same time to store local variables, operation stack, dynamic link, method exit and other information. Each method is called until the completion of execution, corresponding to a stack frame in the virtual machine stack from the stack to the stack process.

The local variable table stores various basic data types known at compile time (boolean, byte, char, short, int, float, long, double) and object reference (reference type, which is different from the object itself. Depending on the virtual machine implementation, it may be a reference pointer to the starting address of the object. It may also point to a handle or other location associated with the object and the returnAddress type (the address that points to a bytecode instruction).

Of these, 64-bit data of long and double types takes up two local variable spaces (Slot), while the rest of the data types occupy only one. The memory space required by the local variable table is allocated during compilation. When entering a method, how much local variable space needs to be allocated in the frame is completely determined, and the size of the local variable table will not be changed during the operation of the method.

In the Java virtual machine specification, two exceptions are specified for this area: if the stack depth requested by the thread is greater than the depth allowed by the virtual machine, a StackOverflowError exception will be thrown; if the virtual machine stack can be dynamically expanded (most of the current Java virtual machines can be dynamically expanded, but the Java virtual machine specification also allows fixed-length virtual machine stacks), when the extension cannot apply for enough memory, an OutOfMemoryError exception will be thrown.

Local method stack (Native Method Stacks)

The role of the local method stack (Native Method Stacks) is very similar to that of the virtual machine stack, except that the virtual machine stack performs Java methods (that is, bytecode) services for the virtual machines, while the local method stacks serve the Native methods used by the virtual machines. The language, usage and data structure of the methods in the local method stack are not mandatory in the virtual machine specification, so the specific virtual machine can implement it freely. Some virtual machines (such as the Sun HotSpot virtual machine) directly combine the local method stack and the virtual machine stack into one. Like the virtual machine stack, the local method stack area throws StackOverflowError and OutOfMemoryError exceptions.

Where is the OutOfMemoryError?

A clear understanding of memory structure can also help you understand different OutOfMemoryErrors:

Exception in thread "main": java.lang.OutOfMemoryError: Java heap space

Reason: objects cannot be allocated to heap memory

Exception in thread "main": java.lang.OutOfMemoryError: PermGen space

Reason: a class or method cannot be loaded into a persistent generation. It may occur when a program loads many classes, such as referencing many third-party libraries

Exception in thread "main": java.lang.OutOfMemoryError: Requested array size exceeds VM limit

Reason: the created array is larger than the space of heap memory

Exception in thread "main": java.lang.OutOfMemoryError: requestbytes for. Out of swap space? Reason: failed to assign local allocation. JNI, local libraries, or Java virtual machines all allocate memory space from the local heap. Exception in thread "main": java.lang.OutOfMemoryError: (Native method) reason: the same local method memory allocation failure, but JNI or local method or Java virtual machine found that JDK8- abandoned permanent generation (PermGen) ushered in metaspace (Metaspace) 1. Background 2. Why to abandon the permanent generation (PermGen) 3. In-depth understanding of metaspace (Metaspace) 4. Summary = text division line = 1. Where is the background 1.1 permanent generation (PermGen)? According to the hotspot jvm structure (the virtual machine stack and the local method stack are combined): the above figure is quoted from the network, but there is a problem: the method area and the heap heap are memory areas shared by threads. About the method zone and permanent generation: in HotSpot JVM, the permanent generation of this discussion is the method area of the figure above (called the method area in the JVM specification). The Java virtual machine specification only defines the concept of a method zone and its role, not how to implement it. There is no permanent generation on other JVM. 1.2 the change of abandoned JDK8 permanent generation of JDK8 permanent generation is as follows: 1. New generation: Eden+From Survivor+To Survivor2. Old age: OldGen3. Permanent generation (implementation of the method area): PermGen--- > replaced by Metaspace (local memory) II. Why to discard permanent generation (PermGen) 2.1.official instructions refer to JEP122: http://openjdk.java.net/jeps/122, original intercept: MotivationThis is part of the JRockit and Hotspot convergence effort. JRockit customers do not need to configure the permanent generation (since JRockit does not have a permanent generation) and are accustomed to not configuring the permanent generation. That is, removing permanent generations is an effort to integrate HotSpot JVM and JRockit VM, because JRockit does not have permanent generations and does not need to configure permanent generations. 2.2 problems are easy to occur in practical use due to insufficient permanent generation memory or memory leakage, an exception java.lang.OutOfMemoryError is exposed: in fact, PermGen has gradually moved the content of permanent generation to other areas during JDK7, such as moving to native area, moving to heap area, etc., while JDK8 has abolished permanent generation and switched to metadata. Third, deeply understand the memory size of metaspace (Metaspace). Metaspace is the implementation of method area in HotSpot jvm, which is mainly used to store class information, constant pool, method data, method code and so on. The method area is logically part of the heap, but it is often called a "non-heap" in order to distinguish it from the heap. The essence of meta-space is similar to that of permanent generation, which is the realization of the legal area in the JVM specification. However, the biggest difference between metaspace and permanent generation is that metaspace is not in the virtual machine, but uses local memory. Theoretically depends on the amount of memory that can be virtualized on a 32-bit / 64-bit system It can be seen that it is not unlimited and requires configuration parameters. 3.2 the size of the Metaspace initialized by the commonly used configuration parameter 1.MetaspaceSize, which controls the threshold of GC occurrence in metaspace. After GC, dynamically increase or decrease MetaspaceSize. By default, this value fluctuates from 12m to 20m depending on the platform. Use the Java-XX:+PrintFlagsInitial command to check the local initialization parameter 2.MaxMetaspaceSize to limit the upper limit of Metaspace growth, so as to prevent Metaspace from using local memory indefinitely and affecting other programs due to certain circumstances. The default value of this parameter on this machine is 4294967295B (approximately 4096MB). 3.MinMetaspaceFreeRatio calculates the free space ratio of the current Metaspace after Metaspace GC. If the free space ratio is less than this parameter (that is, the actual non-idle ratio is too large and there is not enough memory), the virtual machine will increase the size of the Metaspace. The default value is 40, which is 40%. Setting this parameter can control the growth rate of Metaspace, too small value will lead to slow growth of Metaspace, and the use of Metaspace tends to be saturated, which may affect the loading of classes later. Too large a value will cause Metaspace to grow too fast, wasting memory. 4.MaxMetasaceFreeRatio after Metaspace GC, the free space ratio of the current Metaspace is calculated. If the free space ratio is greater than this parameter, then the virtual machine frees up part of the space of the Metaspace. The default value is 70, which is 70%. The largest increase in 5.MaxMetaspaceExpansionMetaspace. The default value for this parameter on this machine is 5452592B (approximately 5MB). The minimum amount of 6.MinMetaspaceExpansionMetaspace growth. On this machine, the default value of this parameter is 340784B (approximately 330KB). 3.3 Test and track the metaspace size 3.3.1. The test string constant 1 public class StringOomMock {2 static String base = "string"; 3 4 public static void main (String [] args) {5 Listlist = new ArrayList (); 6 for (int item0polii)

< Integer.MAX_VALUE;i++){ 7 String str = base + base; 8 base = str; 9 list.add(str.intern());10 }11 }12 }在eclipse中选中类-》run configuration->

The "java application-" new parameters are as follows: because the maximum memory is set to 20m, it will soon overflow, as shown in the following figure: in jdk8: 1. The string constant is transferred from the permanent generation to the heap. two。 Persistent generation no longer exists and the PermSize MaxPermSize parameter has been removed. (see the last two lines in the picture) 3.3.2. Test metaspace overflow by definition, we test the metaspace overflow by loading the class. The code is as follows: 1 package jdk8; 2 3 import java.io.File; 4 import java.lang.management.ClassLoadingMXBean; 5 import java.lang.management.ManagementFactory; 6 import java.net.URL; 7 import java.net.URLClassLoader; 8 import java.util.ArrayList; 9 import java.util.List 10 11 / * * 12 * 13 * @ ClassName:OOMTest14 * @ Description: simulated class loading overflow (metaspace oom) 15 * @ author diandian.zhang16 * @ date on April 27,2017 9oom 454017 * / 18 public class OOMTest {19 public static void main (String [] args) {20 try {21 / / prepare url 22 URL url = new File ( "D:/58workplace/11study/src/main/java/jdk8"). ToURI (). ToURL () 23 URL [] urls = {url}; 24 / get JMX interface 25 ClassLoadingMXBean loadingBean = ManagementFactory.getClassLoadingMXBean () about type loading; 26 / / for cache class loader 27 ListclassLoaders = new ArrayList () 28 while (true) {29 / / load type and cache classloader instance 30 ClassLoader classLoader = new URLClassLoader (urls); 31 classLoaders.add (classLoader); 32 classLoader.loadClass ("ClassA") 33 / / displays quantity information (total number of types loaded, currently valid types, number of types that have been unloaded) 34 System.out.println ("total:" + loadingBean.getTotalLoadedClassCount ()); 35 System.out.println ("active:" + loadingBean.getLoadedClassCount ()) 36 System.out.println ("unloaded:" + loadingBean.getUnloadedClassCount ()); 37} 38} catch (Exception e) {39 e.printStackTrace () 40} 41} 42} to quickly overflow, set the parameter:-XX:MetaspaceSize=8m-XX:MaxMetaspaceSize=80m, and the running result is as follows: the figure above confirms that the class loading (the function of the method area) in our JDK8 is no longer in the permanent PerGem, but in Metaspace. It can be viewed with JVisualVM, which is more intuitive. Fourth, summing up this paper explains the origin and nature of Metaspace, common configuration, and monitoring testing. The size of metaspace is dynamic, but not infinite, and it is best to pay attention to the size from time to time so as not to affect the server memory. Reference article https://segmentfault.com/a/1190000009707894https://www.cnblogs.com/hysum/p/7100874.htmlhttp://c.biancheng.net/view/939.htmlhttps://www.runoob.com/https://blog.csdn.net/android_hl/article/details/53228348 here, on the "what is the structure of JVM memory" study is over, I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report