Java 中 static 变量实现配置类怎么做

在 Ja va 领域，用 static 变量来实现配置类，几乎是每个开发者都会接触到的思路。先说说核心认知：它的本质，其实是利用了类加载时的初始化机制，在内存里“一锤定音”，提供一个全局可读的配置项。但这里有个门槛必须跨过去——它只适合那种启动即固定、无需动态刷新的只读场景，不是什么场景都能往上套的通用方案。

最稳妥的方案：用 static final 定义常量型配置

如果你问我的话，最简单也最安全的做法，就是把配置值声明为 public static final。编译期就能确定下来，线程安全，而且一旦定义就不可变，几乎没有什么后顾之忧。

• 这类写法特别适合数据库 URL、超时毫秒数、或者像 ENABLE_CACHE = true 这样的开关标志——总之，都是运行时不会变脸的参数。
• 有个好习惯别忘了：配合一个 private 构造器，彻底堵死实例化的通道，强化一下工具类的语义。
• 举个例子：

public class AppConfig {
  private AppConfig() {} // 禁止实例化

  public static final int TIMEOUT_MS = 5000;
  public static final String DB_URL = "jdbc:mysql://localhost:3306/app";
  public static final boolean IS_DEBUG = Boolean.parseBoolean(System.getProperty("debug", "false"));
}

需要外部配置时：用 static 块做一次性加载

很多项目的配置不是写死在代码里的，而是从 properties 文件或者环境变量中读取。这个时候，static 块就成了你的好帮手。它可以保证在类首次被使用的时候，配置一次性加载完毕。

• 异常处理是这里的重点：静态块里一旦抛了异常，整个类都会加载失败。建议的做法是捕获异常、设一个默认值，或者直接抛出一个 ExceptionInInitializerError 也别藏着掖着。
• 还有一个实战中的教训：static 块里千万别干重活，比如去远程拉配置。它一旦阻塞，所有依赖这个类的代码都得等着，代价太大。
• 看个例子：

public class AppConfig {
  private static final Properties props = new Properties();
  public static final String API_HOST;

  static {
    try (InputStream is = AppConfig.class.getResourceAsStream("/app.properties")) {
      if (is != null) props.load(is);
    } catch (IOException e) {
      // 记日志，设默认值
      props.setProperty("api.host", "https://api.example.com");
    }
    API_HOST = props.getProperty("api.host", "https://api.example.com");
  }
}

必须警惕的是：别用普通 static 变量存可变配置

除非你有一套明确的同步策略，否则千万别拿非 final 的 static 字段去存那些可能会被修改的配置——比如运行时的某个开关。

• 多线程环境下，直接赋值会碰到可见性问题：一个线程改了，另一个线程读到的可能还是旧值。
• 如果实在需要动态更新，可以考虑用 volatile（适用于布尔值或数值这类简单类型），或者 AtomicReference 来兜底。
• 更稳妥的做法，是把它封装成一个方法，比如 isFeatureEnabled()，内部加锁或者用原子变量来控制访问。

和 Spring @Configuration 或现代配置中心的对比

纯 static 配置类最大的优点是轻量，但它的短板也一样明显——缺乏灵活性。

• 它无法自动监听文件变化，没办法按 profile 切换配置，更不支持像 ${port} 这样的占位符解析。
• 如果是微服务场景，建议还是用 Nacos、Apollo，或者 Spring Boot 的 @ConfigurationProperties 这类方案。
• static 配置更适合的场景是：嵌入式系统、脚本工具、单元测试的辅助类，或者一些规模不大的项目。

说到底，这个方案本身并不复杂，但细节上很容易踩坑。static 配置的本质是“类级别的缓存”，关键就两个字：时机和安全性。初始化时机把握对了，线程安全考虑周全了，用起来确实省事；反过来，一个地方没想清楚，排查起问题来也够你头疼一阵的。