冷启动与性能

用户第一次（或平台新建实例时）调用 Lambda，要经历 下载部署包、JVM 启动、类加载、Spring 初始化——这段 冷启动 延迟可能从几百毫秒到数秒。理解成因与缓解手段，才能判断 Serverless 是否满足你的 SLA。

学习目标

• 区分冷启动、warm 调用与 Provisioned Concurrency
• 列出 Java 运行时特有的启动成本
• 掌握包体积、初始化逻辑、SnapStart 等优化方向

冷启动从哪来

调度新实例
  → 下载/解压部署包（体积越大越慢）
  → 启动运行时（JVM 尤其明显）
  → 执行 static 块 / @PostConstruct / Spring Context
  → 才进入 handleRequest

Warm 调用 复用已初始化进程：仅执行业务代码。流量间歇性时，大量请求仍可能撞上冷启动。

优化策略

手段	效果	代价
减小包体积	少传少解压	拆依赖、避免 fat jar 塞满
精简初始化	少做启动时 IO	懒加载 DB 连接
提高 memory	更多 CPU，有时更快	GB-秒单价上升
Provisioned Concurrency	预热 N 个实例	持续计费，即使无请求
SnapStart（Java）	快照恢复 JVM	区域/运行时限制需查文档

// 反模式：Handler 类 static { 加载整个 Spring Boot }
// 较优：轻量 Handler + 必要 Bean；或 AWS SDK 直连，不用全套 Spring

与 scale-cache 不同：Provisioned Concurrency 是 预置计算实例，不是 Redis 缓存——买的是 已热好的 Lambda 容器。

何时接受冷启动

• 后台异步任务、定时报表：秒级延迟可接受
• 面向用户的同步 API：需压测 P99；若 P99 > 产品要求，考虑 Provisioned 或回 EC2

aws-lambda 在 AWS track 里也会提冷启动；本课强调 Java/Spring 栈的体感。

练习

• 用 CloudWatch Logs 找 REPORT 行中的 Init Duration 与 Duration
• 估算：去掉 unused dependency 对 50MB jar 的部署收益
• 写场景判断：Webhook 回调 vs 支付确认页 API，哪个更怕冷启动？

小结

冷启动是 FaaS 的物理定律；优化靠瘦包、懒初始化、预热或换架构。 下一课讲无状态函数如何把状态交给外部存储。