One GC problem locating and GC problem locating

One GC problem locating and GC problem locating

A colleague has a code segment that takes too long to execute and needs to be optimized,

Hashmultimap <Int, Bean> map = ...; for (400 w * 96) {// computing process Bean = doCompute (); // cache the computing result map. put (int, Bean );}

In the beginning, we thought it was caused by low doCompute efficiency in the computing process. Therefore, we wanted to optimize computing in various ways, such as computing in advance, multithreading, and ,.... And so on. The final result is as follows:

// Multi-threaded computing .... // put the calculation result into the queue concurrent1_queue queue = ...; queue. offer (doCompute ());..... // put the queue data into the cache Hashmultimap <Int, Bean> map = ...; map. put (int, queue. poll ());

But it still doesn't work. The cpu is 100% when running, and there is no reason to find it. When I get off work, I suddenly think it is caused by memory. Then I put it on the server for execution,-Xms20G-Xmx20G. There is no problem.

Analyzed and found the cause (for pure analysis, print the jvm log verification next week ):

For Hashmultimap and concurrent1_queue, the jvm gradually reaches the maximum stack because a single loop is put into the cache. Once the jvm finds that the memory is insufficient, the GC process is started, however, GC is not enough (because no instance needs to be recycled) to start GC again ,..., the cycle repeats, the Business Code cannot run, the CPU is fully occupied by GC, and no memory overflow exception is thrown.

Twists and turns in the problem locating process: it is easy to drill down the dead-end for the primary node, there are many good programmers, and we need to trust the jvm computing production level ....

In addition, record some knowledge that may be used:

By default, the initial memory allocated by JVM is 1/64 of the physical memory. By default, when the memory of the Free heapfreeratio parameter is smaller than 40%, the JVM will increase the size of the heap until the maximum limit of-Xmx is reached, -XX: MinHeapFreeRatio = 40.

By default, the maximum memory allocated by JVM is 1/4 of the physical memory. By default (the MaxHeapFreeRatio parameter can be adjusted) when the free heap memory is greater than 70%, the JVM will reduce the minimum heap limit until-Xms,-XX: maxHeapFreeRatio = 70.

The idle memory displayed through free cannot be fully allocated to the jvm. The ratio of available memory should be related to the jvm vendor and OS.