不能依赖 static 块在 Tomcat 启动阶段可靠初始化数据库连接池，因其执行时机由类加载决定、上下文缺失、易重复执行且异常难捕获；应使用 ServletContextListener、Spring 的 @PostConstruct 或 ApplicationRunner 等标准生命周期机制。
不能依赖 static 块在 Tomcat 启动阶段可靠初始化数据库连接池。它可能早于 ServletContext 就执行，也可能晚于请求到来才触发，时机不可控、上下文缺失、错误难捕获。
static 块的执行时机完全由类加载行为决定
类是否被加载、何时被加载，取决于 JVM 的类加载策略和代码实际调用路径。比如：
- 你写了
static { initPool(); }，但没人引用该类（没调DatabaseUtil.getConnection()，也没在web.xml或 Spring 配置中声明），那它压根不会执行 - 某个 JSP 页面或过滤器里首次用到了这个工具类，
static块才执行——此时请求已进来，连接池“预热”失去意义 - 若类被多个 ClassLoader 加载（如热部署、OSGi 场景），
static块可能执行多次，连接池重复创建甚至泄漏 - 抛出未捕获异常（如配置文件不存在、DNS 解析失败）会导致
NoClassDefFoundError，整个类不可用，且日志里只显示“类加载失败”，不体现真实原因
ServletContextListener 是 Web 应用的标准启动入口
这是 Servlet 规范明确定义的、唯一能保证“Web 应用部署完成、ServletContext 可用、尚未接收任何请求”这一时机的扩展点。
- 实现
ServletContextListener接口，在contextInitialized(ServletContextEvent sce)中初始化连接池 - 通过
sce.getServletContext().getAttribute("dataSource")或setInitParameter注入到全局上下文中，供后续 Servlet/Filter 使用 - 必须在
web.xml中显式声明，或使用@WebListener注解（Servlet 3.0+） - 所有初始化逻辑都在主线程中执行，可安全调用
ServletContext.log()记录状态，异常也能被捕获并记录为 ERROR 级别
Spring 生态下优先用 ApplicationRunner 或 @PostConstruct
如果你用的是 Spring Boot 或 Spring MVC + 内嵌 Tomcat，static 块更不该出现——Spring 容器本身提供了更健壮、可测试、支持依赖注入的生命周期钩子。
-
@PostConstruct标注在@Component类的方法上：适合单个 Bean 内部资源初始化（如某 DAO 类自己建一个专用连接池） -
ApplicationRunner或CommandLineRunner：更适合应用级预热，可注入DataSource、RedisTemplate等任意 Bean，支持异步（@Async）、重试、错误降级 - 它们在
refresh()完成后执行，意味着所有 Bean 已实例化、AOP 代理就绪、配置属性已绑定——比static块能拿到更多上下文信息
如果真要保留 static 块，至少加三层防护
仅限极少数遗留系统无法改造、又必须用静态字段暴露连接池的场景。否则不建议。
- 用
volatile DataSource instance+ double-checked locking 封装初始化逻辑，避免多线程并发创建 -
static块里只写一行：if (instance == null) synchronized (...) { if (instance == null) instance = createPool(); }，把实际逻辑拆到私有方法中 - 每个
catch必须记录完整堆栈：log.error("Failed to init static connection pool", e)，不能只打印e.getMessage() - 在类文档头部加注释：
// WARNING: This static init does NOT guarantee execution at web startup. Do NOT use as startup signal.
真正容易被忽略的是：static 块不是“启动逻辑”，它只是“类初始化逻辑”。而 Web 启动 ≠ 类加载。一旦混淆这两者，排查问题时就会陷入“我明明写了初始化，为什么连不上库”的死循环。
