静态变量和静态方法需明确业务角色与风险：静态变量用于可控共享状态，须防并发与误覆盖；静态方法仅适用于无状态工具逻辑，不可依赖实例成员或Spring上下文。
静态变量和静态方法不是“能用就行”，而是要清楚它在业务中承担什么角色、带来什么风险。用对了，代码简洁高效；用错了，容易出并发问题、内存泄漏或逻辑混乱。
静态变量：共享状态要可控
静态变量本质是类级别共享资源，适合存全局不变量或需跨实例协调的状态。
-
推荐场景：配置缓存（如
ConfigLoader.CACHE）、连接池计数器、日志上下文ID生成器、单例工厂的持有引用 -
必须加保护：多线程写操作不能裸用
static int counter = 0;和counter++，应改用AtomicInteger或同步块（锁MyClass.class） - 注意初始化时机：静态变量在类首次主动使用时由 JVM 单线程初始化，这部分天然线程安全；但后续运行时修改仍需自行保障
- 避免误当实例变量用：不要在构造器里反复赋值静态变量，否则每次 new 都覆盖——这不是共享，是覆盖
静态方法：无状态工具才真正安全
静态方法没有 this，意味着它不依赖对象生命周期，也不保存调用上下文。这是它被广泛用于工具类的根本原因。
-
适合写成 static 的：纯计算（
MathUtils.add()）、字符串处理（StringUtils.isBlank()）、对象判空（Objects.isNull()）、JSON 转换入口（JsonUtil.toJson()） -
不能写成 static 的：需要访问实例字段、调用实例方法、依赖 Spring 注入的 bean、涉及事务或线程上下文（如
SecurityContextHolder.getContext()） -
常见报错提示：
non-static variable xxx cannot be referenced from a static context—— 不是语法卡你，是语义上“这里还没对象，你却要找对象的东西” -
若真需操作实例：显式传参，比如
Validator.validate(User user)，而不是在静态方法里 new User() 或调用 user.getName()
静态代码块和静态内部类：做初始化与解耦
它们不是“为了用 static 而用”，而是解决特定问题的利器。
- 静态代码块：只执行一次，适合加载驱动、注册协议、预热缓存。多个块按源码顺序执行，异常会中断类加载，慎加外部依赖（如远程配置中心超时）
- 静态内部类：不持外部类引用，适合替代 Handler、Runnable、Listener 等可能造成内存泄漏的场景。可访问外部类静态成员，但不能直接访问实例字段——这反而是优势，强制解耦
-
枚举类本质就是静态内部类：每个枚举常量都是
public static final实例，天生线程安全、不可变、可序列化
别踩这些坑
- 序列化不保存静态变量：反序列化后值仍是类加载时的值（或默认值），别指望它跨 JVM 持久化
- 静态方法无法被重写：子类同名 static 方法只是“隐藏”，调用取决于引用类型，不是实际类型——多态失效
- main 方法是 static 的，但不代表所有入口都该是：Spring Boot 启动类的 main 只是入口胶水，业务逻辑不该堆在 static 方法里
- 不要为省一个 new 而滥用 static：如果方法内部要频繁读写状态、依赖注入、或未来可能扩展为有状态服务，就老实用实例方式
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
