JVM generational model

  • The young generation
  • The old s
  • The permanent generation

The life cycle of the object

  1. Most objects are short-lived
  2. A few are long-term survivors
    1. Static The object referenced by a static variable

The young generation, the old generation

The JVM divides the heap memory into two regions, the young and the old.

Young generation: Objects that are created and recycled soon after.

Old age: Stores objects that have been stored for a long time since they were created.

Why is the heap divided into young and old generations

Convenient garbage collection.

Objects in the young generation will be collected after they are created, and targeted garbage collection algorithms are designed for such cases.

Older objects, which are stored long after they are created, also require a garbage collection algorithm.

The permanent generation

TODO

Will the heap memory be garbage collected, but will the method area

Yes, classes in the method area will be reclaimed in the following cases

  1. First, all instances of the class are garbage collected
  2. The ClassLoader that loaded the current class is garbage collected
  3. There is no reference to the Class object of this Class

Each thread has its own Java virtual machine stack that holds information such as local variable tables. Is the virtual machine stack garbage collected?

Personal thought: No, as the method completes, the corresponding stack frame of the method is out of the stack

Interview questions:How are your objects allocated in JVM memory? How does it flow?

Ephemeral objects, in the Cenozoic;

Long-lived objects, in the old age

Most normal objects are allocated memory in the new generation first

Normal object:

Abnormal object:

What will trigger the next generation of garbage collection

Trigger conditions for the new generation of garbage collection

If the new generation of our pre-allocated memory space, almost all of the objects are filled! Now, suppose our code continues to run, and he needs to allocate an object in the next generation? We’re running out of memory in the new generation!

At this point, a garbage collection of the new Generation is triggered. The garbage collection of the new Generation, also known as **”Minor GC”, or sometimes “Young GC”, tries to collect all the garbage objects from the new generation that no one references.

Long-lived objects can evade multiple garbage collections

If an instance object in the new generation succeeds in 15 garbage collections and is still not collected, it is 15 years old.

15 is specified by the MaxTenuringThreshold configuration item.

15 is the age of the object, and its age is +1 after each garbage collection if the object is not collected (but survives).

The instance object is then moved to the old age. You are 15 years old, you are a mature old man lol

So the old age is for objects that are very old, and the old age is for objects that have survived a lot of garbage collection

Will old age trigger garbage collection

Answer: Of course!

  1. Older objects might run along with the code, no longer referenced by anyone, and need to be garbage collected
  2. As more and more objects enter the old age, the old age space is filled (the space is limited), and garbage collection is triggered

Thinking about the life cycle of objects

Can you combine the characteristics of the short lifetime objects, and the characteristics of the long lifetime objects, and think about the system that you’re working on, and sort out what the short lifetime objects are and what the long lifetime objects are.

Objects with short lifetime:

  1. prototype Bean
  2. An object created inside a method

Long-lived objects:

  1. singleton Bean
  2. Static variables

Hands-on experiment: See for yourself how to set the JVM memory size for an online system deployment

Core parameter

  • Machine configuration: 4core 8G Linux

  • JDK version: JDK8

-Xmx5440M -Xms5440M -XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+ParallelRefProcEnabled
Copy the code

-Xms Java heap memory size

The initial size of Java heap memory

-Xmx Maximum size of Java heap memory

The maximum size that Java heap memory is allowed to expand to

-Xmn New generation size in Java heap memory

Subtract out the new generation, and what remains is the size of the old

-xx :PermSize: permanent generation size

-xx :MaxPermSize: indicates the maximum size of the permanent generation

-Xss: stack memory size per thread

How do I set JVM parameters for an online deployment system

New arguments in JDK 1.8:

-xx :MaxMetaspaceSize=128m (MetaspaceSize is the default size of MetaspaceSize)

The system is started through the JAR package

java -Xms512M -Xmx512M -Xmn256M -Xss1M -XX:PermSize=128M -XX:MaxPermSize=128M  -jar App.jar
Copy the code

Deploy systems based on containers

Tomcat catalina.sh

Parameters of the graphic

-Xmx5440M -Xms5440M -XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+ParallelRefProcEnabled
Copy the code

Case analysis

(Case 1)How to set the JVM heap size for a payment system with millions of transactions per day?

What’s the pressure on a payment system that makes millions of transactions a day?

When the user initiates a payment request, the payment order (object) is created.

At the JVM level alone, the pressure is: millions of transactions per day, millions of paid order objects are created in the JVM every day.

Frequent creation of payment order objects.

So here’s the question:

  • How many servers will be deployed for the payment system
  • How much memory each server needs
  • How much heap memory space does the JVM on each machine need to allocate
  • How much memory space should be given to the JVM so that it can support the creation of so many payment orders in heap memory without running out of memory and crashing directly

Keep thinking:

1. How many orders per second the payment system needs to process

To address one of the core parameters of an online system, the proper size of the JVM heap memory, the first thing we need to calculate is how many payment orders per second our system is processing.

Some hypotheses:

  1. Assuming 1 million payment orders per day, the average user transaction will occur at peak times of the day, such as noon or evening.

  2. Let’s say the peak is a couple of hours a day, with a million dollars spread out over a couple of hours, so it’s about 100 orders per second, so let’s do it at 100 orders per second.

  3. Let’s say we deploy three machines to our payment system, each of which actually processes about 30 orders per second.

2. How long does each payment order take to process?

If the user makes a payment request, the payment needs to create a payment order object in the JVM, populate it with data, and then write the payment order to the database, among other things.

Continue the hypothesis analysis:

  1. Assume that the processing of a payment request, including the creation of a payment order, takes approximately 1 second.

  2. In general, a flow model you can have in mind is that each machine receives 30 payment order requests per second, and then creates 30 payment order objects in the JVM’s new generation, writes to the database, and so on.

  3. Then one second later, the 30 payment orders are processed, and the references to these payment order objects are recycled, leaving them as garbage objects that no one references in the JVM’s new generation.

  4. Then another 30 payment orders in the next second and repeat the process.

3. How much memory space is required for each payment order object

You just have to remember that an Integer variable has 4 bytes of data, a Long variable has 8 bytes of data, and other types of variables have how many bytes of data.

Typically, for a core class like a pay order, you’re going to count 20 instance variables, and then an object is probably a few hundred bytes in size.

Let’s say it’s a little bit bigger, even if a paid order object takes up 500 bytes of memory, which is less than 1KB.

An estimate of the memory footprint of the object

An object consists of an object header (4 bytes), object body (reference type 4 bytes instance data Integer 4 bytes, Long 8 bytes/base type), padding (complement 8 bytes)

The object header consists of markword (8 bytes) +kclass (4 bytes compression enabled by default). If it is an array, the record length is 4 bytes.

4. Memory usage of payment requests per second

That’s about 30 payment requests per second for a single machine.

30* 500 bytes =15000 bytes ≈ 15KB

5. The full payment system memory footprint needs to be evaluated

The previous analysis was all based on a single payment order object in a core business process, but that was only a small part of the analysis.

A real payment system running online would certainly create a large number of other objects per second, but we can combine this access pressure with the memory footprint of the core objects to give a rough estimate of how much memory the entire payment system would occupy per second.

In fact, if you want to estimate, you can multiply the previous calculation by a factor of 10 to 20. That is, in addition to the payment order object being created in memory, dozens of other objects are created every second.

Objects that are referenced by local variables of stack memory are created every second in the range of a few hundred kilobytes to 1MB.

And then the next second it comes in with a new request and it creates about a Megabyte of objects and puts them in the next generation, and then it becomes garbage, and then the next second.

After multiple cycles, there is too much garbage in the new generation, triggering Minor GC to collect it. This is a rough JVM-level memory usage model for a complete system.

How to set JVM parameters for payment system

Payment system machine configuration: 2 Core 4G / 4 Core 8G

With four gigabytes of memory, it’s actually relatively compact.

8GB memory reference JVM configuration:

-Xms3G -Xmx3G -Xmn2G

The new generation has a slightly larger memory, because the payment order object belongs to the short-lived object.

Every qualified engineer should, when the system goes live, make an estimate of system stress, then make an estimate of JVM memory, disk space size, network bandwidth, database stress, and then make a reasonable allocation of everything.

(Case 2)What about the JVM stack memory and permanent generation size for a payment system with millions of transactions per day?

Permanent generation size

The general setting of several hundred MB, the basic are enough.

Stack memory size

Thread-private stack memory space, default 512KB -> 1MB

Knowledge supplement

Why does Tomcat break parent delegation

Why Tomcat needs to break the parent delegate model:

(1) Different Web applications in Tomcat need to rely on different versions of the same third-party class library, and JAR class libraries need to be isolated from each other;

(2) The same version of a third-party class library can be shared by different Web applications

(3) The class libraries that Tomcat depends on must be isolated from the class libraries that the application depends on

(4) JSP needs to support the modification to take effect without restarting Tomcat: for the above class loading isolation and class update without restarting, customized development of various class loaders