Jvm 如何减少线程达到安全点同步状态所花费的时间

关于这个问题：
在VM中的大量IO期间，由于停止线程需要更多的时间，我们面临JVM暂停/缓慢。在查看safepoint日志时，显示同步状态花费的时间最多

我们还尝试在超时延迟（-XX:+SafepointTimeout-XX:SafepointTimeoutDelay=200）上打印Safepoint跟踪，以了解是哪些线程导致了此问题，但似乎没有任何可疑之处。另外，在设置安全点的超时时，当所用时间处于“同步”状态时，我们不会得到超时检测打印

有关此安全点跟踪的问题：

安全点超时是如何工作的

记录线程详细信息后，安全点是否存在，所有线程是否恢复

将执行该VM操作。如果vmop是GC，将会发生什么

使用异步探查器：
尝试使用异步探查器进行safepoint评测，并注意到VM线程在SafepointSynchronize:：begin（）方法上花费的时间更多，C2编译器线程花费的时间几乎与VM线程相同

---

我们怀疑C2编译器是否需要时间才能达到安全点。是否有人能帮助我们解决这个问题，并将这一次解释给safepoint flamegraph。提前感谢。

安全点超时选项只影响日志记录，即线程不会中断，VM操作将正常运行，等等

---

SafepointTimeout

并不总是打印超时线程：打印时线程可能已经到达安全点。此外，如果操作系统冻结了整个进程，

SafepointTimeout

甚至可能检测不到超时

例如，这样的“冻结”经常发生

• 当一个进程在cgroup（容器）中耗尽其cpu配额时
• 当系统物理内存不足时，会发生
• 由于另一个进程的活动（例如，当

  实用程序检查系统时，我观察到JVM长时间暂停）

确实有一个时间到安全点评测选项（

--ttsp

），尽管正确使用它可能看起来很棘手。它在具有

jfr

输出的

wall

分析模式下工作得最好。在此配置中，async profiler将在safepoint同步期间对所有线程（运行线程和阻塞线程）进行采样，并用时间戳记录每个事件

然后可以使用JDK任务控制来分析这样的配置文件：选择长暂停周围的时间间隔，并查看该时间间隔内java线程的堆栈跟踪

---

请注意，如果JVM进程处于“冻结”状态，则异步探查器线程也不工作，即在此期间您将看不到收集的样本。通常，在挂钟评测模式下，所有线程都是均匀采样的。但是，如果您看到一个“间隙”（在某个时间间隔内错过的事件），这显然意味着JVM进程没有收到CPU时间。在本例中，JVM暂停的原因不在Java应用程序中，而是在操作系统/环境中。

感谢@apangin我们尝试了jfr输出的墙分析模式，在时间间隔内我们只能找到休眠线程，而没有找到运行线程。这似乎是冻结状态的情况。顺便说一句，在我们的例子中没有CPU短缺，只有IOWait存在。每当我们进行一定大小的磁盘写入（比如>1GB）时，就会发生这种情况。如果有任何方法可以调试冻结状态，请与我们分享？IO和同步状态之间有什么关系吗？@Arunkumar不看个人资料很难判断。但过多的I/O肯定会导致暂停。