Serverless的精髓是按需付费，可冷启动一直是横在IT行业面前的“毫秒天花板”。传统Java SpringBoot在AWS Lambda首次调用耗时可达8秒，Python虽然启动快，却在密集计算环节落后，于是我们把两种语言拉到同一擂台，用相同的图像resize业务做对比，目标是p99冷启动<100ms，同时保持CPU与内存不变。

1-251119205640262.png

Java队派出GraalVM Native Image，提前在构建期做静态分析，把反射、动态代理、JNI全部塞入config文件，生成一个18MB的可执行ELF。实验发现，把SpringBoot替换成Micronaut后，启动时间从2.4s骤降到120ms，但体积膨胀至32MB，反而拖慢网络下载。于是我们合并了三个优化：1）采用upx压缩+lz4解压，把ELF压到11MB；2）使用Lambda SnapStart，让Firecracker微VM在第一次成功后即刻打快照，后续实例复用内存页，实测额外缩减62ms；3）把代码段对齐到2MB大页，降低page fault，从12次降到3次，最终冷启动p99=78ms，成功达标。

Python队则走另一条路线：CPython 3.11+pybind11+libpython.a编译成单个so，再用GitHub开源项目“pex”把所有依赖打包成可挂载的zip，运行时通过memfd_create直接映射进内存，避免磁盘IO。同时，借助Python 3.11的JIT（copy-and-patch），把热点字节码编译成机器码，CPU密集场景提升2.7倍。最终镜像体积只有7MB，冷启动p99=65ms，略胜Java一筹，但长尾波动更大，原因是GC依旧受引用计数影响，偶发decref雪崩。

1-251119205J05M.png

综合来看，如果业务偏向计算型且团队熟悉JVM生态，Java Native Image+SnapStart是更稳的选择；若追求脚本灵活、依赖更新频繁，则Python JIT化更适合。Serverless冷启动优化没有银弹，唯有把语言运行时、平台快照、网络下载、内存对齐四个维度同时压缩，才能把“按需”二字真正写入IT行业的成本结构里。

1-251119205R03E.png