1. -Xms与-Xmx一致的场景
   适用场景
   • 生产环境：生产环境通常需要应用运行的稳定性和性能。设置相同的Xms和Xmx可以避免JVM在运行过程中不断调整堆的大小，减少性能波动。
   • 长生命周期的应用：如果应用在长时间运行过程中内存需求稳定，并且你预估应用需要使用较大的内存块，那么设置Xms等于Xmx会更合适。
   • 避免频繁的堆扩展和收缩：当应用的内存需求变化较少，或是频繁调整堆大小会影响性能时，一致的Xms和Xmx可以避免堆动态扩展/收缩带来的CPU和GC开销。
   优点
   • 稳定的内存使用，无需JVM在运行时重新分配内存，减少性能波动。
   • 避免应用在堆扩展或收缩过程中触发的Full GC。
   示例场景
   • 高并发服务：如电商、金融系统、在线服务等，需要长时间维持稳定的服务。
   • 大数据处理：如批处理、大规模数据集处理系统，其内存需求较为稳定，且需要处理大块数据。

2.-Xms与-Xmx不一致的场景
适用场景
• 开发和测试环境：开发和测试环境下，应用的内存需求可能会有波动，但你不需要为内存分配太多资源。因此，可以设置较小的Xms，以便JVM根据实际需求进行动态扩展。
• 内存需求有明显波动：如果应用的内存需求在不同负载情况下变化明显，如启动时内存占用较少，但在运行过程中占用逐步增加，则可以设置Xms较小，Xmx较大，以应对内存需求的动态变化。
• 节省内存资源：在内存资源有限的环境中（如容器化部署、云环境），将Xms设置较小，以便根据实际负载动态调整内存使用，避免浪费资源。

优点
• 灵活性：能够根据负载动态调整内存分配，特别是在初始阶段内存需求较少的应用中。
• 节省资源：在初始阶段，系统不会分配大量内存，从而节省系统资源。
示例场景
• 微服务：内存使用量随请求量变化较大，或者依赖外部服务的应用，其初始内存使用较少。
• 定时任务：不需要持续占用大量内存的应用，内存使用随着任务进行而增加。

在GC优化完成之后，我们把目标转到了数据库连接池上。
调整了最大连接数（常见的建议是设置为 CPU 核心数 x 2 + 1，并视业务实际并发量进行调整），最小连接数（以根据系统的最低负载需求来设置，一般建议设置为 5-10 个），连接等待超时，空闲连接检测与回收等
然后这里需要说明的是，数据库不归我们管，我通过navicat等客户端查到的数据库连接池，好像只有几百（客户PIN跳板机恰巧迁移，现在看不了）

我们拉上了客户的IT，客户的k8s的RainBond服务商。
但是苦于没有直观的证据，客户这边给出的答复就是整个公司用的都是我们的系统，不会有问题。这其实和技术层面没有半毛钱关系，完全是定责的问题，整个过程极其漫长和痛苦。我们先后派出区域开发，产研，交付总监等（很明显能看出，之前是技术，后面就是扯皮了），但是效果依旧不大。
于是我们采用了一些其他的兜底方案。

客户需要检测我们的服务器状态，于是增加了zabbix，增加了Prometheus对我们的业务进行了抽取，将整体服务器状态抽取到Grafana
当然只是监控和预警。

由于某些不可抗力，以及沟通的障碍性，我们采用了第一版本的兜底方案。
1.我们将服务器pod增加到了6台，每天pod的内存调整到了容器允许的最大值（32G）
2.我们去除了健康检测机制（因为一旦检测失败，就开始不停的重启机器）
3.增加了定时任务，每天凌晨手工重启服务，进行手工释放内存
4.向客户申请了服务器资源，准备脱离RainBond平台进行部署

经过多次协商之后，我们申请到了一堆的机器，进行安装部署我们新的环境。（额外提一嘴，由于与客户关系太僵硬了，我最一开始出的docker-swarm部署方案被驳回了）

部署完成之后，我发现有个服务系统同样宕机了，但是后面发现是因为这台机器内存过小，在走计划任务之后，oom自己宕机了。于是和客户协商之后，我下线了这个机器。

最终部署完了，验证之后，有天客户告诉我，服务不响应了。我紧急上线进行了排查，查询到了第一次服务假死现象。我有8台主业务服务，nginx配置了集群，但是路由到某台机器之后，服务无返回。
最终我处理完了这个问题，重启了这个服务。然后我惊讶的发现，我有几台服务器的容器的up time是在几小时前。
我当时就慌了，我一下子就想到我是不是错怪RainBond平台，我们并没用真正意义上解决掉这个问题。

基于这样容器无故宕机的事情，我第一时间向上汇报了情况。不过由于之前的反复和客户的沟通无果，加上每次协调产品委员会都很耗时。我们第一时间进行了回避这样的问题。
于是，这就是2.0的鬼鬼祟祟兜底方案
具体方案依据就是：我不相信同一时间所有业务服务都挂了。只要nginx实现，自动下线和故障恢复。那么在同一时间，哪怕我的业务服务，挂了一台两台，无所谓，整体业务是可以使用的。
nginx配置：