GraalVM Native Image 进程能否被 jps 检测到？#
答案是肯定的，但只在特定条件下！如果你在编译时使用参数 --enable-monitoring=jmxserver,jmxclient,jvmstat 启用了 jstat 和 jmx 等监控功能，那么你的 native image 进程就会在 jps 中显示。如果没有启用这些标志，它们对 jps 来说仍然是不可见的。
我们当前的策略：GraalVM vs JVM 使用#
以下是我们如何在技术栈中战略性地利用这两种技术：
1. Lambda 风格任务 → GraalVM Native Image#
对于像不频繁但数据量大的定时任务（想想每周报告或临时数据导出）这样的工作负载，我们全力投入 GraalVM Native Image。以下是为什么这样做完全合理：
为什么不使用传统微服务？#
- 资源浪费是真实存在的：你需要为峰值处理需求调整微服务大小，大部分时间让资源闲置
- 扩展的舞蹈：为了与持久化微服务保持成本效益，你需要在任务运行前以更高的内存/CPU 重启，然后在之后缩小规模——多么麻烦！
为什么这些工作负载非常适合无服务器#
- K8s CronJobs 和 AWS Lambda 是理想的平台，但它们要求极快的启动时间
- Native Image 在这里大放异彩：快速启动时间加上更简单的依赖树，使迁移变得直接
2. 长期运行的微服务 → 坚持使用 JVM#
对于我们的常驻服务，JVM 仍然是我们首选，但有一些智能优化：
存储密集型服务#
对于管理大量存储 I/O 连接的微服务，我们采取谨慎的方法：
- 暂时跳过 CRaC - 持久连接有太多移动部件
- 启用 CDS 以加快类加载
- 考虑 Graal JIT 作为 C2 编译器的即插即用替代品
无状态服务 → 全程使用 CRaC#
对于没有重度存储依赖的服务 - Web 引擎、API 网关和广告服务（具有重度本地缓存） - CRaC 是游戏规则改变者。这些正是需要在需求激增时快速扩展的流量敏感服务！
这种混合方法为我们提供了两全其美：批处理工作负载的极快无服务器执行，以及实时流量的优化、快速扩展的微服务。
