static块不适合Tomcat启动预热，因其执行时机不可控、依赖类首次主动引用，无法保证在应用可用前完成；应使用ServletContextListener或Spring的@PostConstruct/ApplicationRunner等标准机制。
Static块不能在Tomcat启动时“预热全局数据”，这是个常见误解。Java类的static初始化块（static {}）只在类首次被加载并初始化时执行，而这个时机由JVM决定，通常发生在该类第一次被主动引用时——不一定是Tomcat启动时，更不保证在Web应用完全可用前执行。直接依赖static块做启动预热，极易导致数据未加载、并发问题或启动失败。
为什么static块不适合做Tomcat启动预热
Tomcat启动过程中，类加载是按需触发的。Servlet、Filter、Listener等组件的类可能在第一个HTTP请求到达时才加载；某些工具类甚至全程不被使用。static块若写在这样的类里，根本不会执行。即使放在某个被早期加载的类中，也缺乏启动生命周期控制，无法感知ServletContext、无法读取web.xml或application.properties，也无法捕获初始化异常并优雅降级。
真正可靠的方式：使用ServletContextListener
这是Servlet规范定义的标准扩展点，专为Web应用启动/关闭阶段设计，能安全访问ServletContext和初始化参数：
- 创建一个实现ServletContextListener接口的类
- 在contextInitialized()方法中加载缓存、初始化连接池、预热计算结果等
- 在web.xml中声明，或用@WebListener注解（Servlet 3.0+）
- 所有操作都在Tomcat完成Web应用部署后、接受请求前执行，时机可控、上下文完整
替代方案：Spring Boot用户用@PostConstruct或ApplicationRunner
如果你用的是Spring生态（包括Spring MVC + Tomcat嵌入式）：
- @PostConstruct标注在@Component类的方法上，适合单Bean内部初始化
- ApplicationRunner或CommandLineRunner接口更适合应用级预热逻辑，可依赖注入任意Bean，支持异步和错误处理
- 它们在Spring容器刷新完毕、所有Bean就绪后执行，比static块更健壮、可测试、易维护
如果非要用static，至少加一层防护
极少数遗留场景下不得不保留static初始化，务必做到：
- 用volatile + double-checked locking确保线程安全
- 把实际加载逻辑封装进方法，static块只触发一次调用，避免阻塞类加载
- 加上try-catch并记录ERROR日志，防止因异常导致类加载失败而整个应用瘫痪
- 明确文档说明：“此static初始化不保证在Web启动时执行，请勿依赖其作为启动信号”
