当前位置:网站首页>JVM call not used once in ten years

JVM call not used once in ten years

2022-07-05 05:05:00 Extraordinary~

JVM from GC Perspective , Partition of heap ?

answer :java Heap from GC The angle can be divided into old age and new generation . Among them, the new generation . among The Cenozoic is subdivided into Eden Area and two Survivor District (S0 and S1)

Why divide the heap memory into two pieces instead of just an old age ?

answer : because JAVA object %90 The above objects are " transient " among GC The cost of recycling is high , To improve performance, put the newly generated object in Eden District , Will carry it many times GC Of " Old fool " Put it on the old generation

Then why should the Cenozoic continue to subdivide ?

because Eden Most objects in the area have a short life , that Eden Every time it's full, clean up the garbage , The surviving objects are migrated to the elderly area , The old age area is full , It triggers Full GC Full GC It's very time consuming , To set up s One purpose of the district is to Eden A buffer pool has been added in the district and the elderly , Distribute some objects who are not old enough , Increase garbage collection performance

Survivor Will there be garbage collection in the area ?

Meeting , But not actively garbage collection , yes Eden The garbage is collected in the garbage collection area , Default Eden Area and S0 and S1 Billy in the district is 8:1:1

Directly into a piece Eden Area and 1 block S Can't the district ?

This involves the younger generation of garbage collection algorithms ( Copy algorithm ) Set the two Survivor The biggest advantage of the zone is that it solves fragmentation

Introduce to you JVM Of 7 Garbage collection algorithm in ?

1. Reachability analysis algorithm ( Marking stage )

2. Mark - Clear algorithm ( Young generation elimination stage )

3. Copy algorithm ( Young generation elimination stage )

4. Marking algorithm ( Old age clearance stage )

5. Generational collection algorithm

6. Incremental collection algorithm

7. Partition algorithm (G1 The collector )

JVM How the work of each region is coordinated ?

jvm It can be divided into runtime data area and class loader , Execution engine , Local method library

The runtime data area contains the following sections :

1. Method area : Non heap

2. Virtual machine stack : Local method

3. Native Method Stack :native Method

4. Pile up : The new generation , Old age

5: Program counter : Mark the position of the line executed by the current thread , It is convenient to continue to execute the non runtime data area after the context switching is completed :

6. Class loader : Start class adder , Extend the classloader , system class loader , Custom class loaders

7. Execution engine : Interpret the bytecode instruction / Compiled into local machine instructions on the corresponding platform ;

8: Local method library :java Call cross language (C,C++) The interface of

Pile up , Stack , How to coordinate the data storage between method areas ?

answer : The stack points to the method area ; The stack points to the heap , Heap points to method area , The method area points to the heap :

Stack ----> Method area

Dynamic links point to klass The address of the object in the method area

Stack ----> Pile up

The reference variable stored in the local variable table , Point to the address where the real object is stored in the heap

Method area ----> Pile up (JDK8 In the future, the method area is no longer pointing to the heap )

JDK7 Previously, staticity was in the method area ;

JDK8 And then , There are metadata classes in the heap Class in ;

Pile up ----> Method area

klass pointer Function to find the class that the object depends on

Do you understand the parental delegation mechanism ?

Parents delegate : Sandbox security mechanism , Prevention core API The library was tampered with at will

There are other scenarios that break the parental delegation mechanism , Because it is limited by the class loader model , In some cases, the parent loader cannot load the required file , stay JDBC Tomcat, The scene needs to be loaded by the subclass loader class The file breaks the parental delegation mechanism .

Do you know the memory allocation strategy ?

Free list :idea( Free ),used( Already used ),available( You can use )

Pointer collision : Optional +CAS

Why introduce meta space ?

1. Permanent generation of shortcomings

There is a memory bottleneck

GC: String constant pool , Dynamic bytecode

Store class information

2. Meta space can solve permanent problems , Is there a problem with it ?

Meta space stores the class loading information of the application , The current implementation of recycling will generate memory fragments

The way G1 The collector

system.gc and runtime. getRuntime(). gc() What can I do ?

System.gc() Call... Internally Runtime.gc().

Insist on saying the difference Runtime.gc() yes native method.

and System.gc() Right and wrong native method, It calls... In turn Runtime.gc(); call gc Method by default , The trigger is displayed full gc, At the same time, the old generation and the new generation are recycled , Trying to free memory occupied by discarded objects .

system.gc The call comes with a disclaimer , There is no guarantee that the garbage collector will call . namely gc() The function just reminds the virtual machine , Programmers want a garbage collection . But this recycling cannot guarantee that it will be carried out , When to recycle depends on jvm. If you call gc After the method, I want gc Must be implemented , You can call... Additionally system. runFinalization Method .

JVM Mediation idea

In fact, at work , There are few opportunities to get in touch with jvm tuning , I spend most of my time writing CRUD Code , But if something really goes wrong online , Then think again jvm Tuning is a little late , So we need to store this knowledge first .

The interviewer thought : Mainly to see what you have done to JVM Have you considered and summarized the performance problems .

It can be said from three aspects :

  1. Cause... At work JVM Is the performance problem caused by code problems or JVM Parameter problem ?

  2. JVM How to monitor and troubleshoot performance problems ?

  3. How to optimize parameters according to performance problems ?

Code checking

First of all, the first aspect , In fact, most of them JVM Performance issues , It's not about the parameters we set , In general , It's all done with default parameters , The real problem is that there is something wrong with the code you write , Such as frequent creation of large objects , Then reference them and don't release , Then these big objects enter the old generation , The garbage collector can't recycle them , There's not enough memory in the old days , Cause frequent Full GC, Every time Full GC Will trigger STW, That is, the Caton phenomenon , So the performance is very poor ?

How to monitor

This is for logging , We can use logs to quickly locate performance problems .

  • Logging is this command :

-XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:gc.log Replication failed. Replication succeeded 
  • Then you can also set the automatic export after memory overflow Dump file :

-XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\jvm.dump Replication failed. Replication succeeded 
  • In addition, if you want to export immediately dump file , Just use this command :

jmap -dump:format=b,file=D:/demo.hprof pid Replication failed. Replication succeeded 

Of course , We'd better put dump File obtained , Then put it into local tools for analysis .

How to analyze dump file

In the second aspect , Get dunp After the document , It's analysis

Speaking of common analysis tools , Of course, it's necessary jvisualvm Visualization tools , You can type in the command jvisualvm open , Then load the previous dump Just file it . This tool will show which large objects are occupying the existing . You can also use JProfiler Visual chemical tools to check .

The whole idea Is to get dump file , Put it into a visualization tool to analyze , Most cases are caused by large objects , Then combine with your own code , See where the object is not recycled after creation , Then optimize the code .

How to check Full GC

occasionally , We can only check through the command on the online server , Then you can only use the command line tool to check , In fact, the idea is also very conventional :

  1. jps -l Found the pid

  2. ps -mp -o THREAD,tid,time Navigate to the specific thread .

  3. printf “%x\n” , Thread pid To 16 Base number , such as 0xf58

  4. jstack pid | g rep ( representative ) -A 10 0xf58 View the thread's stack log , We can't find the problem. Go on .

  5. There is no way out , Can only dump The memory file is analyzed with visual tools , then Fix after locating the code .

analysis YGC

Most of the time , Newly created objects will be created in the new generation Eden Regional distribution , When Eden When there is not enough space allocated in the area , The virtual machine will happen once Minor GC, That is to say YGC. Occurs frequently YGC It will also affect the performance .

Analyze the growth rate of young generation objects .

Every time 5 Once per second , perform 10 Time , Then look at this 50 Seconds eden The increasing trend of the area , You can know the growth rate of young generation objects .

jstat -gc pid 5000 10 Replication failed. Replication succeeded 

Ideas : If eden The area is growing rapidly , So it happened YGC The frequency of will also be very high , explain Eden The area is too small , It can be turned up Eden District ( adjustment -Xmn Parameters ), Then test it again , See if the small is reduced YGC Recovery frequency .

In addition, if YGC after , There are more living objects than Survivor Of 50%, They will enter the old age .

our Tuning ideas It is to minimize the number of objects entering the elderly , To reduce the occurrence of FGC The frequency of . So by adjusting Eden The size of the area , Reduce the frequency of objects entering the old age .

Parameter tuning

The third aspect , How to optimize parameters . In general , Just use the default parameter , But some scenarios still need parameter tuning .

The tuning idea is as follows :

  • The first step must be to see what parameters are configured :jinfo -flags pid.

  • Then look at it. Java Version of ,Java 7 and Java 8 There's a big difference ,Java 8 The permanent zone has been cancelled , Added metaspace District , Be specific to The impact of recycling , Put it back and share . see Java Version of command :jinfo -sysprops pid.

  • General Settings -Xms=-Xmx, This gives you a fixed size of heap memory , Reduce GC The number and time taken , Can make the heap relatively stable .

  • -Xmn Set the size of the new generation , Too small will increase YGC, Too big to reduce the size of the older generation , It is generally set to the whole heap 1/4 To 1/3.

  • Set up -XX:+DisableExplicitGC Disable the system System.gc(), To prevent manual triggering FGC Cause problems .

When does garbage collection trigger ?

Generally, it is divided into Minor GC and Full GC Two cases .

The timing of garbage collection for the younger generation (Minor GC)

  • When Eden When there is not enough space in the area

When the whole heap triggers garbage collection (FULL GC)

  • When the object size of the young generation promoted to the old generation was larger than the remaining space of the old generation .

  • When the space utilization rate of the old age exceeds a certain threshold

  • When meta space is insufficient (JDK1.7 Permanent generation shortage )

  • call System.gc() when , System recommendation implementation Full GC, But not necessarily .

原网站

版权声明
本文为[Extraordinary~]所创,转载请带上原文链接,感谢
https://yzsam.com/2022/186/202207050500255609.html