[2022-04-27]
近期遇到了一个客户的问题，先把发现的信息和找到的文档做一个记录，回头再来翻一下。
现象：
目前收集到的信息：
How to reduce time taken on threads reaching Safepoint - Sync state
没有发生GC也进入了安全点？这段关于安全点的JVM源码有点意思！
[JVM源码分析之安全点safepoint]
(https://www.jianshu.com/p/c79c5e02ebe6)
[2022-04-28] 补充：
客户在4月初做过一次环境调整，做了部分环境升级和补丁处理。
经过跟客户的沟通，昨晚做了环境迁移，复制了早先的一份环境（虚拟机），重新搭建了我们的应用服务，搭建完成以后，今天使用系统恢复正常。
上面两个关于SafaPoint的文章其实描述两个不同的场景，分别是由于系统原因导致JVM无法进入安全点以及由于JVM自身的设计与代码执行之间的碰撞导致的无法进入安全点。
从目前的实际验证情况来看，基本排除了我们的应用是由于后者的原因导致此前的问题，而是前者，而目前还不清楚实际原因，待后续排查以后，再来做补充。
[2023-02-20]补充：
遇到客户在使用FastJSON进行对象序列化字符串转换时，遇到无法进入SafePoint的问题，且在设置了timeout参数的情况下，仍然出现了系统停顿近2分钟的情况。
异常点是：
SerializeWriter的writeStringWithDoubleQuote方法
尝试做了参数配置调整，观察中
增加了-XX:+UseCountedLoopSafepoints，允许系统在可数循环中加入安全点
[2023-02-22]补充：
确认添加-XX:+UseCountedLoopSafepoints参数后，问题解决了。
问题确实是由于FastJSON执行序列化时间过长，导致系统无法进入安全点导致的系统挂起。加入此参数后，允许在int循环中加入安全点，保证了系统不会被长时间挂起。
当然，FastJSON序列化时间长的问题需要单独处理，然而，那就是另外一个话题了。
增加了一个文档，记录如下缩短进入安全点的策略
https://stackoverflow.com/questions/67232199/how-to-reduce-time-taken-on-threads-reaching-safepoint-sync-state
奇怪的知识又增加了
