JVM - 11：JVM最让人无奈的痛点 Stop the World

新生代垃圾回收场景

我们新生代有三块区域 Eden 、s0、s1

此时系统不停运行

就会把Eden占满

这个时候就会触发Minor GC

触发垃圾回收会有专门的线程来处理的

而对不同的区域会有不同的垃圾回收器

相当于垃圾回收线程配合垃圾回收器使用垃圾回收算法对指定的区域进行回收

针对新生代的垃圾回收器

Serial
单线程，会直接暂停系统工作线程。通常不用

ParNew
支持多个线程回收

GC的时候还能创建对象吗

垃圾回收的时候，先标记处存活的对象，然后把存活的对象复制到另外一个s区域

如果这个期间允许创建对象

会出现即将清空的区域，会出现没有被标记到要存活的对象

全乱套了

所以在GC的时候允许创建对象是灰常不合适的

JVM的痛点：Stop the World

所以平时运行中的JVM最大的痛点，就是 Stop the World 停止工作

因为在垃圾回收的时候，要尽量让垃圾回收器专心工作

不能随便让Java创建对象了

所以此时，JVM会直接在后台进入Stop the World状态

也就是说，他会直接停止我们写的Java系统的所有工作线程，让我们写的代码不再运行！

这样的话，垃圾回收的时候，就不会创建新的对象

Stop the World造成的系统停顿

假设我们的垃圾回收需要100ms

那么就可能导致我们的系统会直接停顿100ms，不接受任何请求

最直接的影响就是，这期间用户发起的请求，会没有任何响应

如果内存分配不合理

平均10多分钟一次 Full GC

最直观的影响就是 10来分钟卡一次，一次可能几秒甚至几十秒

所以，无论是新生代，还是老年代，尽量不要让GC频率过高

也避免持续时间过长

让系统无法正常运行

这也是JVM优化中，最需要关注的一个点