随着近几年云计算、云原生的成熟发展，细心研究与观察，我们可以发现，云厂商其实都在围绕着云，不断面向用户，帮助用户做“将本增效”，不断降低基础设施的成本，进一步提升投入产出比的质量。且研发团队在架构设计层面，其实都需要综合考量研发效率、性能、资源成本等多个因数之间的平衡，而不是仅仅围绕着业务研发本身，这才是综合性成本考量法。
按照对目前司内敏态应用的日常生产运行分析以及目前降本增效的大背景下，22年12月份，个人开始对敏态应用的资源做进一步地思考，争取以技术的手段去解决一些降本增效事情。通过调研与技术考察，我们发现，除了系列大厂有能力和资源对底层设施做优化乃至重构外，其实社区中也不断涌现出了很多能帮助我们进一步做技术布局与降本增效的技术方向和产品。
目前我部的应用系统的后端技术语言都围绕着java整个体系进行，所以在运行层都依托于JVM进行，从目前的司内调研情况来看，分为敏态和稳态系统，有如下情况：
1、其中敏态应用基本都基于JDK8，其中敏态包括上容器云的和非上容器云的，上容器云的应用都统一使用成熟的瘦身版本的OpenJDK支撑应用的运行，非上容器云的都普遍以基础架构统一部署的oracle openjdk；
2、稳态的应用都普遍以传统的方式部署，且jdk的版本多样，从1.6到1.8几乎都存在，而且很多稳态应用还是基于1.6的版本进行。
不管是基于1.6的，还是基于1.8的，其实从技术层面上来看，JVM都依托的的oracle的hotspot，此底层运行基础设施不变。而openjdk一定程度上来说，是一款比较重的产品，所以这就给了我们一定的方向思考，我们是否可以在jdk乃至jvm这些底层基础设施上做一些优化考量？
经过考察、研究、数据验证以及技术团队的系列应用试运行(非生产)，计划进行部内OpenJ9的推广。
首先，我们先看下什么是OpenJ9。以下是我的总结。
1、IBM开源贡献给社区，经过多年的发展，目前已相当成熟；
2、其和oracle/sun的hotspot一样，也是jdk的一个实现；
3、其是更轻的JVM
为了更形象，我参照社区的技术分析，做了张简图。
从上图可以知道，不管是oracle的(目前我们在用的)，还是OpenJ9的，其实他的上层的java规范是不变的，说的直白点，目前针对于研发同学，应用无需做改造，大家其实都是java这个老祖宗的后代，同源同宗。
只是不同的是JVM的区别，可以这么理解，IBM和社区进一步结合云的趋势，让自己的技术视野变得更广阔。这里多说一句，我们应该知道，类似于阿里这类大厂，其实都有自己的JVM团队，他们其实就是在hotspot的角度上去做优化，最终其实还是hotspot。
既然说了这么多，那OpenJ9又有哪些特点呢？我们先看一个官方说明(后面，我们也会进一步去进行验证)。
` 42% faster startup time，启动时间快42% 66% smaller footprint after startup，启动后占用内存减少66% Faster ramp-up time in the cloud，云端环境快速提升吞吐量 63% smaller footprint during load，高负载时减少63%的占用空间 `
从以上官方社区的说明我们可以看到，其在应用启动速度、应用内存占用上都有了很大的变化。其中，启动速度对应着研发效能；内存占用对应着降本，从目前来看，起码在政策背景上，技术符合司内宣导方向。
为进一步说明其特新，我们看一张OpenJ9的架构图。
从架构图中我们可以看到，除了和hotspot类似的组件模型外(编译、执行、垃圾回收模型等)，其增多了SCC和DDR两个新特性，那这两个是做什么用的呢？
SCC，Shared class cache，表面意思就是他能够通过一定的分析，把编译好的字节码进行缓存，所以这个点，其实就是它整体应用启动速度能够加快 的一个关键原因。
DDR，Direct dump reader，增强了字节码查询工具、指令集等，这个对于研发来说，在性能优化的过程中，才会有一定的体现。
除了以上的特性，OpenJ9和HotSpot还有一些小的对比，比如在GC的策略上、AttachAPI上以及一些指令工具上，具体不做详细介绍，后期随着内部推广的深度进行，进一步做分析。感兴趣的可以到社区去进行学习了解。
接下来，我这边就以技术团队的相关服务做验证。
所有验证会分为几个阶段。
第一阶段，应用本身的启动时间、内存/CPU的数据占用；
第二阶段，应用并发验证；
第三阶段，稳定性测试与对比
我这里挑选了两个服务，一个是分布式任务调度平台、一个是统一网关。第一个应用是CPU密集型的应用，第二个应用日常流量比较大，IO相对密集。本次验证，为第一阶段的验证。
我们先看下应用的启动时间对比。
这里，我做了应用在三种情况下的启动时间对比。其中hotspot和openj9(未开启指令)在正常情形下，启动速度其实差不多，有些时候openj9反而会慢一点。而一旦开启了quickstart/scc等指标，我们会发现，整体启动速度下降一半，有很大的变化。
接下来，我们验证相关应用在资源占用上的情况对比与分析。本次主要验证的是一段时间区间的静态验证。
左图，是在hotspot上的运行情况，右图使用的是openj9，可以看到在内存占用上还是有不小的差异。
应用都为在容器云上运行，都分配的为1024M的内存，从数值来看，HotSpot下，应用启动后到平稳运行所占用的内存为：875.52M；OpenJ9下，应用启动后到平稳运行所占用的内存为：323M，减少了超过50%内存使用量，效果还是比较明显。
同时，我们在看下堆的情况，这里拿了两个静态峰值做了对比。
可以看到，在整个堆的占用上，相差一半左右。
接着，我们再看下非堆的使用情况。
非堆的使用上，差异有40M左右的差异。
所以，从这些静态数据对比来看，我们其实可以去猜测，OpenJ9的JVM在对象的创建以及内存的分配上大概是做了一些方面的优化，目前个人也逐步在对所可能涉及到的优化原理猜想进行验证中，后面随着推广的展开，也会进一步去做更多的分享。
除了以上的静态数据验证外，接下来也会有详细的并发动态验证数据，届时会有更详细的测评指标供给大家查看。
—————–EOF——————