静态代码块不可直接初始化数据库连接池，但可在类加载时触发已托管连接池的预热以实现“首次可用”，前提是连接池支持校验、配置已就绪且不阻塞加载。
静态代码块不适合直接初始化数据库连接池，但可以作为轻量级预热入口，在类加载时触发连接池的“首次可用”状态——前提是连接池本身支持预热、配置已就绪、且不阻塞类加载过程。
适用前提：不是所有连接池都适合静态块预热
只有满足以下条件的连接池才可考虑在 static 块中触发预热：
- 连接池实现支持连接初始化校验（如 HikariCP 的 connectionInitSql 或 Druid 的 initConnectionSqls）
- 全部配置项（JDBC URL、用户名、密码、超时等）已在类加载前确定，可通过系统属性、环境变量或 final static 常量获取
- 连接池构造不依赖 Spring 容器、ServletContext 或其他运行时上下文
- 预热逻辑不包含重试、异步等待或阻塞式健康检查——否则会卡死类加载，导致应用启动失败
正确用法：用静态块触发连接池“第一次真正可用”
核心思路是：让连接池实例本身由 Spring 或 Servlet 容器管理，而通过静态块在类加载时调用其预热方法，确保首个业务请求到来前连接已建立并校验通过。
- 把连接池声明为 public static final 字段，避免被重复初始化
- 在 static 块中调用 pool.getConnection() 后立即归还，配合 connection-test-query 配置，使连接完成握手与会话初始化
- 验证预热效果：通过 getActiveConnections() 或 getTotalConnections() 确认连接数已达 minimumIdle
- 捕获异常并提供明确 fallback，例如记录日志后设为 null，避免 ExceptionInInitializerError 导致类不可用
典型误用：哪些绝对不能做
以下操作放入 static 块会导致启动失败或行为不可控：
- 在 static 块中 new HikariDataSource() 并传入未初始化的 Spring Environment 或 @Value 注入的值
- 尝试从远程配置中心（Nacos/ZooKeeper）拉取数据库地址——网络延迟会阻塞整个类加载流程
- 读取外部文件路径（如 /etc/app/db.conf），该路径在打包环境可能不存在，抛出 FileNotFoundException 却无处捕获
- 调用尚未初始化的日志框架（如 SLF4J Logger），此时 logger 可能为 null 或静默失效
替代方案：更可靠的初始化时机
若项目使用标准 Web 或 Spring 生态，应优先选择容器生命周期机制：
- Web 应用：用 ServletContextListener.contextInitialized()，确保 ServletContext 就绪后再建池
- Spring Boot：用 @PostConstruct（Bean 内部）或 ApplicationRunner（应用级），天然支持依赖注入和异常处理
- Serverless 场景：静态块预热可接受，但必须搭配 connection-timeout 和 fail-fast 配置，避免冷启动超时
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
