JVM CPU Full Problem locator

1. The thread does not release, causing the old area to be full, the system keeps FULLGC

The discovery of applications is not FGC, but frequent ygc.

YGC also has anomalies, S1 and S0 regions are jumping from 0 to 99%

Look at the heap size can be found in the memory of the young area is constantly from 0 to 99, and the old area is slowly increasing, has not reached the state of FGC. But the follow-up is expected to continue to rise, resulting in FGC channel, the application can not provide services.

After discovering YGC frequent about 3 hours, finally began the frequent Fgc,old district full.

The following are the case of heap size and FGC:

You can see that almost 10 seconds old area is full to cause a FGC, and the old area size is 10G (how scary, 10 g 10 seconds to run out)

Check the state of the memory is not the old area is too small, is used full of the cause of the constant FGC, because it is obviously big enough, if 10G is not enough, then the application must be problematic.

To view thread CPU usage for a process:

Top: Identify higher process numbers

top-h-P process number isolated , showing all threads! Then sort by CPU, such as

Get a few threads that are CPU intensive and turn into 16 binary

Using Jstack to see thread stack information within a process (jstack 24820 > Abc.log)

Vim edit Abc.log to find the 16 binary number of threads obtained above

If more than one user makes multiple queries at the same time (one user can make multiple queries), multiple threads of SSH will occur.

2. Multithreaded operation thread Unsafe variables

such as multithreaded Operation HashMap

JVM CPU Full Problem locator