此版本仍在开发中,尚不被认为是稳定的。对于最新的稳定版本,请使用 Spring Framework 6.2.10! |
JVM 检查点恢复
Spring 框架与 Project CRaC 实现的检查点/恢复集成,以允许实现能够使用 JVM 减少基于 Spring 的 Java 应用程序的启动和预热时间的系统。
使用此功能需要:
-
启用了检查点/恢复的 JVM(目前仅限 Linux)。
-
的存在
org.crac:crac
库(版本1.4.0
和以上)在类路径中。 -
指定所需的
java
命令行参数,例如-XX:CRaCCheckpointTo=PATH
或-XX:CRaCRestoreFrom=PATH
.
在指定的路径中生成的文件-XX:CRaCCheckpointTo=PATH 当请求检查点时,包含正在运行的 JVM 内存的表示,其中可能包含密钥和其他敏感数据。使用此功能时,应假设 JVM “看到”的任何值(例如来自环境的配置属性)都将存储在这些 CRaC 文件中。因此,应仔细评估生成、存储和访问这些文件的位置和方式的安全影响。 |
从概念上讲,检查点和恢复与SpringLifecycle
合同对于单个豆子。
正在运行的应用程序的按需检查点/还原
可以按需创建检查点,例如使用jcmd application.jar JDK.checkpoint
.在创建检查点之前,Spring 会停止所有正在运行的 bean,让它们有机会在需要时通过实现来关闭资源Lifecycle.stop
.恢复后,将重新启动相同的 Bean,并使用Lifecycle.start
允许 Bean 在相关时重新打开资源。对于不依赖 Spring 的库,可以通过实现自定义检查点/恢复集成来提供org.crac.Resource
并注册相关实例。
利用正在运行的应用程序的检查点/还原通常需要额外的生命周期管理,以正常停止和开始使用文件或套接字等资源,并停止活动线程。 |
请注意,在以固定速率定义计划任务时,例如使用@Scheduled(fixedRate = 5000) ,当使用按需检查点/还原还原 JVM 时,将执行检查点和还原之间的所有遗漏执行。如果这不是您想要的行为,建议以固定延迟安排任务(例如,使用@Scheduled(fixedDelay = 5000) )或使用 cron 表达式,因为这些表达式是在每次任务执行后计算的。 |
如果在预热的 JVM 上创建检查点,则恢复的 JVM 将同样预热,从而立即实现潜在的峰值性能。此方法通常需要访问远程服务,因此需要一定程度的平台集成。 |
启动时自动检查点/恢复
当-Dspring.context.checkpoint=onRefresh
JVM 系统属性,则在
启动期间LifecycleProcessor.onRefresh
阶段。此阶段完成后,所有非惰性初始化的单例都已实例化,并且InitializingBean#afterPropertiesSet
已调用回调;但生命周期尚未开始,并且ContextRefreshedEvent
尚未出版。
出于测试目的,还可以利用-Dspring.context.exit=onRefresh
JVM 系统属性,其中
触发类似的行为,但它不是创建检查点,而是在同一生命周期退出 Spring 应用程序
阶段,不需要 Project CraC 依赖项/JVM 或 Linux。这对于检查连接到远程
当 bean 未启动时,需要服务,并且可能会优化配置以避免这种情况。
如上所述,特别是在 CRaC 文件作为可部署工件(例如容器镜像)的一部分提供的情况下,在作时假设 JVM“看到”的任何敏感数据最终都会出现在 CRaC 文件中,并仔细评估相关的安全影响。 |
自动检查点/恢复是一种将应用程序启动“快进”到应用程序上下文即将启动的阶段的方法,但它不允许拥有完全预热的 JVM。 |