为方便交流，建了一个数据库相关的群，现在还可以扫码入群。欢迎对这个领域有兴趣的朋友扫码入群。
前言
SAP的所有Java类的产品，基本上都是采用自家的JDK。自版本8或以前，称为SAP JVM/JDK。自版本8以后，就称之为：sapmachine-jdk-<version>了。
而在BTP云平台上，对应的Java Buildpack，默认采用的就是SAP的JDK了。而JDK11的最后维护周期在今年11月份以后，就停止维护了，意味着一些相应的bug到时候就不会有相应的fix了。这也促使广大用户主动积极的升级自己的应用程序，迁移到支持JDK17了。那么问题来了，这个升级的理由是什么？
详情分析
BTP平台中，使用的最多的是基于Cloud Foundry搭建的云服务。Java应用程序在部署时，需要一个yaml格式的manifest清单文件。
下边是一个简单的示例，使用的是JDK17的相关JVM配置。
---
applications:
- name: service-foofoo
routes:
- route: foofoo-development.{domain}
buildpacks:
- sap_java_buildpack_jakarta
stack: cflinuxfs4
memory: 4G
instances: 2
path: target/foofoo.jar
timeout: 600
health-check-type: http
env:
SPRING_PROFILES_ACTIVE: cloud
JBP_CONFIG_JAVA_OPTS: '[ java_opts: ''-Xss512K -XX:+UseG1GC -XX:+DisableExplicitGC -XX:MaxHeapFreeRatio=30 -XX:MinHeapFreeRatio=10 -XX:-ShrinkHeapInSteps -XX:G1PeriodicGCInterval=300000 -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=35 -XX:+UnlockDiagnosticVMOptions -XX:GCLockerRetryAllocationCount=100 --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.io=ALL-UNNAMED --add-opens java.base/sun.security.util=ALL-UNNAMED --add-opens java.base/sun.security.x509=ALL-UNNAMED'' ]'
JBP_CONFIG_COMPONENTS: "jres: ['com.sap.xs.java.buildpack.jre.SAPMachineJRE']"
JBP_CONFIG_SAP_MACHINE_JRE: "[memory_calculator_v2: {headroom: 5}]"
services:
- logs
简单说明：
buildpacks: sap_java_buildpack_jakarta, 这个值，专指用的是JDK17. 以前的老版本，用的值是sap_java_buildpack.
JBP_CONFIG_COMPONENTS: "jres: ['com.sap.xs.java.buildpack.jre.SAPMachineJRE']", 这个特指用的是SAPMachine JVM， 自JDK11以及以上版本，用的就是这个值。
JBP_CONFIG_SAP_MACHINE_JRE: "[memory_calculator_v2: {headroom: 5}]", 这个也是SAP JDK的选项，表示整个进程当中，有5%的内存是本地非JVM堆内存。因为本地容器本身也需要内存。如果不设该值，那么Buildpack的内置算法会让-Xmx占用所有剩余内存。导致的后果就是在-Xmx峰值到达以前，容器因为自身的本地内存不够，会导致进程被杀死。
前不久，有一篇短文：云上JDK17 Crash的案例及补救方案
里边提到了JDK17在某些特殊场景中的处理方案：增加了jvm选项：-XX:+UnlockDiagnosticVMOptions -XX:GCLockerRetryAllocationCount=100，让GCLocker的逻辑有多次尝试的功能。
实际上，我们从dynatrace的APM监控里可以看到，JDK11到JDK17的升级转变以后，相同的负载情况下，系统在内存开销方面发生了巨大的变化。
JDK17前后对比简图：
自5号左右升完级以后，8GB的内存基本上都用到了不到2G.而以前基本上同样的负载，能把8G内存全都打满。
这也从侧面反映jdk17在GC方面，其处理性能得到了非常大的改进。
在老版本当中，当时为了想改进GC，还特意加大了GC线程的数量：
-XX:ConcGCThreads=10 -XX:ParallelGCThreads=10 -XX:-UseDynamicNumberOfGCThreads
实际上，它只是降低了GC的相应处理时间，但是GC本身并没有及时得到执行。
在jdk17里头，我们将这里的10个线程数，直接降到2，依然能取得很好的效果。
我是【Sean】, 微信: _iihero, 欢迎大家长按关注并加星公众号：数据库杂记。有好资源相送，同时为你提供及时更新。已关注的朋友，发送0、1到7，都有好资源相送。
往期导读:
1. PostgreSQL中配置单双向SSL连接详解
2. 提升PSQL使用技巧：PostgreSQL中PSQL使用技巧汇集(1)
3. 提升PSQL使用技巧：PostgreSQL中PSQL使用技巧汇集(2)
4. PostgreSQL SQL的基础使用及技巧
5. PostgreSQL开发技术基础:过程与函数
6. PostgreSQL中vacuum 物理文件truncate发生的条件
7. PostgreSQL中表的年龄与Vacuum的实验探索：Vacuum有大用
8. PostgreSQL利用分区表来弥补AutoVacuum的不足
9. 也聊聊PostgreSQL中的空间膨胀与AutoVacuum
10. 正确理解SAP BTP中hyperscaler PG中的IOPS (AWS篇)
11. 由浅入深高可用(HA)之: HAProxy
