JVM hang, Eden zone 100%, all threads including gc threads are analyzed by blocked, jvmgc

JVM hang, Eden zone 100%, all threads including gc threads are analyzed by blocked, jvmgc
Jstat-gcutil pid 1000
S0 S1 E O P YGC YGCT FGC FGCT GCT
5.68 36.18 100.00 1.50 11.93 14 0.555 0 0.000
5.68 36.18 100.00 1.50 11.93 14 0.555 0 0.000
5.68 36.18 100.00 1.50 11.93 14 0.555 0 0.000
5.68 36.18 100.00 1.50 11.93 14 0.555 0 0.000

Jstack-F pid
Attaching to process ID 16063, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.0-b56
Deadlock Detection:

No deadlocks found.

Thread xxx: (state = BLOCKED)

Thread xxx: (state = BLOCKED)

..........

Thread xxx: (state = BLOCKED)

When the Eden area is 100%, the application memory cannot be allocated. The ygc is triggered, and the vmThread executes the ygc and is allocated to the GCTaskThread for execution. The vmThread is returned only after the GCTaskThread is executed. However, GCTaskThread sometimes needs to allocate heap memory during execution. At this time, Heap lock is held by the Application Thread applying for memory allocation, which turns into a deadlock.

Why does the Application Thread need to obtain heap_lock? Because if a thread triggers gc because the memory cannot be allocated, it will be the same if other threads apply again, therefore, the thread that triggered gc for the first time holds this lock, so that other application threads can wait without generating the same operation. Otherwise, there will be a large number of operations in the vmThread execution queue for the same reason.

The reason why CTaskThread sometimes needs to allocate heap memory during execution is that exceptions (check and load) may occur, and the exception information must be applied for heap memory (java space) before it can be returned to the application.

Currently, we cannot specify the VMS to reserve these heaps to handle this issue, which is a pitfall.

A jvm process starts with several threads.

However, the so-called single-threaded program we wrote is only one thread in the JVM program. The JVM itself is a multi-threaded program. At least one Garbage Collector thread must exist. I just installed a NetBeans6.0 file with a analyzer package, so I wrote a HelloWorld program and checked the JVM startup. There are several threads in it: the result is: in addition to my main thread, there are also four threads: Finalizer thread: the Java System thread Signal Dispatcher thread executed by the object before garbage collection: reference Handler thread, a Java System thread that processes signals from local operating systems for the JVM: Put the suspended objects to a high-priority Java System thread in the queue. Attach Listener thread: the user thread I personally guess is: The Finalizer thread's task is to call the finalize () method for garbage collection. The job of the Signal Dispatcher thread is to process the operating system, shield the operating system, and implement cross-platform Java. The task of the Reference Handler thread is to mark an unused object and put it in the queue of the recycle object for the Finalizer thread to release the memory. Last Attach Listener thread: this should be my Java Profile thread. It has nothing to do with JVM.

How does JVM schedule threads? What is this question?

There are two. The first one is responsible for reclaiming young's memory and placing the surviving objects from the eden area into the same vor1 area. When the same vor1 area is full, it is switched to another vor2, after several conversions, it is placed in the old area. The second one is responsible for scanning the heap memory. When the old area is full, fullGC is triggered.