静态变量必须用static修饰且只能在类体中声明，属于类而非实例，内存分配在类加载的准备阶段，所有实例共享，存在线程安全与内存泄漏风险。
静态变量声明必须用 static 修饰，且只能在类级别出现
Java 中的静态变量属于类本身，不是某个实例。它不能写在方法里、构造器里，也不能用 local 变量的方式定义。常见错误是把 static int count = 0; 放在 main 方法内部——编译直接报错：modifier static not allowed here。
正确位置只有一处：类体中、所有方法外部。例如：
class Counter {
static int totalCount = 0; // ✅ 合法
void inc() {
static int local = 0; // ❌ 编译失败
}
}
-
static变量可以被public/private/protected修饰，但不能和final冲突（其实可以共存，只是语义不同） - 未显式初始化的
static变量会按类型默认赋值：int是0，Object是null - 多个类加载器下，同一个类名可能有多个
static变量副本，这点常被忽略
static 变量内存分配发生在类加载阶段，不是对象创建时
静态变量不随 new 出现而分配，而是在 JVM 加载该类的 Class 对象时，就分配在方法区（JDK 8+ 是元空间）里。这意味着即使你从没 new 过这个类的任何实例，只要引用过它的静态成员，类就会被加载，static 变量也就存在了。
比如下面这行代码就能触发类加载和静态变量初始化：
立即学习“Java免费学习笔记（深入）”；
System.out.println(Counter.totalCount);
- 类加载过程包括：加载 → 验证 → 准备 → 解析 → 初始化；
static变量在「准备」阶段分配内存并设默认值，在「初始化」阶段执行=右侧表达式或静态块 - 如果静态变量依赖另一个类的静态字段，可能引发意外的类加载顺序问题，甚至死锁（尤其在双亲委派被破坏时）
- JDK 7 之前方法区在永久代，容易
java.lang.OutOfMemoryError: PermGen space；JDK 8+ 默认用元空间，但若加载大量动态类，仍可能java.lang.OutOfMemoryError: Metaspace
静态变量共享性带来的线程安全风险
因为所有实例共享同一份静态变量，一旦多个线程并发修改，结果不可预测。这不是“有没有锁”的问题，而是“根本没考虑同步”的典型坑点。
比如计数器场景：
static int count = 0;
void increment() { count++; }
这行 count++ 实际是三步：读取、加1、写回。多线程下极易丢失更新。
- 简单场景可用
AtomicInteger替代：static AtomicInteger count = new AtomicInteger(0);，然后调用count.incrementAndGet() - 若逻辑复杂（如需原子地读-改-写），得用
synchronized块，锁对象建议用Counter.class，而不是this（后者对静态方法无效） - 注意：
static final引用对象本身不可变，但其内部状态仍可变（如static final List list = new ArrayList();），这点常被当成“线程安全”误用
静态变量生命周期长，不当持有易导致内存泄漏
静态变量的生命周期与类相同，只要类没被卸载，它就一直占着内存。最危险的是静态集合持有对象引用，尤其是 Activity、Context、View 等 Android 场景，或 Web 应用中持有 ServletRequest/Response。
典型反例：
static Map<String, Object> cache = new HashMap<>();
cache.put("user", currentUser); // currentUser 持有大量资源
- Web 应用中，若用静态
Map缓存用户 session 数据，服务器重启前这些对象永远不会被 GC - 替代方案优先选弱引用容器，如
WeakHashMap，或使用专门缓存库（Caffeine、Guava Cache），它们支持大小限制、过期策略 - 类卸载的前提是：该类的
ClassLoader可被回收。Web 容器热部署失败、自定义类加载器未释放，都会让静态变量“赖着不走”
静态变量不是“省事写法”，它是把双刃剑：省去了实例管理，却把责任全推给了开发者对生命周期和并发的理解。稍不留神，就卡在 GC 日志里查半天，或者线上突然 OOM。
