之前对OpenJ9进行了静态数据验证，从整体验证的结果看，使用了OpenJ9的应用，在处于平稳期的时候，所占用的内存与以往所用的Oracle的HotSpot相比，下降了约40%-60%区间不等，在整体的资源使用率上，得到了很大的压缩。
同时，通过多个启动时间数据的验证，证明使用了OpenJ9的应用在启动时间上与以往的Oracle HotSpot减少了50%，提高了应用启动的速度。
而应用是随时会随着业务变化，经过一段时间的动态数据验证(主要是通过压测)，我们更好地去观测和分析OpenJ9在真实流量情况下的运行情况。
首先，先说下结论。
1、整体使用OpenJ9和HotSpot的应用，做压测对比，在流量缓和的情况下，整体性能相当；
2、若在流量到达顶峰(比如某应用的真实顶峰TPS为500)，OpenJ9的性能稍逊于HotSpot，需要对使用OpenJ9的应用进行CPU和内存提升；
3、同时，我们在压测的过程中发现，OpenJ9的应用的fullgc次数高于HotSpot的(原生情况，未开启相关JVM参数调优)，且CPU高。次数高的原因，除了性能外，还与OpenJ9所使用的GC策略有关系，OpenJ9在GC策略上，会进行Idle heap GC，其是指，通过计算发现有一些heap空间长时间不用，它就会主动发起回收；而Hotspot，会通过年龄代和使用可触达进行判别，所以在策略上还是有一定差异；CPU高，是因为FullGC的工作是需要CPU协助的。
所以，从以上结论，我们可以得到一个初步的OpenJ9使用策略。
1、产线应用在评估是否用OpenJ9之前，一定要先评估下自己的未来流量情况(当然，不用OpenJ9也需要评估^_^，这是对自己应用技术负责的态度) ，若日常流量不高(比如有些系统每天就几个人使用又或者在特定时刻才会有流量高峰) ，则可以按照真实使用情况考虑是否用OpenJ9并评估资源申请情况；
2、对于一些流量比较大的应用，若期望使用OpenJ9进行将本增效，产线应用可以通过压测等手段，合理进行内存申请与流量低谷资源释放，从而真正达到“资源降本”的目的。
如下内容是通过客观的压测，所出的相关数据报告，可做参考。
我们通过对开源社区的spring cloud gateway进行压测，统一网关的场景属于CPU和IO都较为密集的应用，所以能客观分析用了OpenJ9的真实指标情况。其次，也重点压测了包括短链平台、分布式ID生成平台的情况，结论和如下网关的数据大体相当。
所以，本次以网关压测的数据进行考究，所压测的接口的业务场景为：报文加解密。通过对此接口压测，单实例(2C2G)的峰值为500TPS，此次参照这个基准进行压测。
—————–EOF——————