zgc的Allocate stall原理

1. zgc的内存管理分成两级管理模式：首先是分配内存页面，其次才是从内存页面中分配对象，
2. Allocate stall发生在分配内存页面的阶段，与jvm的ZStallOnOutOfMemory（默认为true）参数密切相关，当ZStallOnOutMemory参数为false，此时分配内存页面，当时当前没有空闲的内存页面时，jvm就会直接抛出OutOfMemory异常。
3. 当ZStallOnOutOfMemory为true时，此时如果内存页面分配失败，则产生一个阻塞的页面分配请求插入到请求队列的末尾，然后启动zgc垃圾回收,当zgc垃圾回收回收到空闲的页面空间时，就会把该页面分配给队列中阻塞等待的页面分配请求.

正常内存充足情况下应用线程的最大阻塞时间是初始标识，重新标识，初始转移中的最大值，然而当发生Allocate stall时，由于需要回收到空闲页面应用线程才能继续运行下去，所以应用线程需要等待一直到有空闲的内存页面为止，而这个时间一般需要经过：初始标识+并发标识+重新标识+清理 或者 初始标识+并发标识+重新标识+清理（假设这里没有页面完全都是垃圾对象） + 初始转移+并发转移 这些步骤之后，应用线程才能获取到空闲的页面继续运行。

Allocation stall对应的触发垃圾回收的方式是发送异步消息+循环等待的方式，区别于System.gc的发送同步消息的方式，两者的区别只是在这个过程中会不会主动让出cpu的问题.

以上所述，尽量不要让zgc进入到Allocate Stall中，如果发现了这个日志，需要调整zgc的参数(比如ZAllocationSpikeTolerance或者ZCollectionInterval)，提早进行zgc的回收.