静态变量属于类、被所有实例共享且内存中仅一份，实例变量属于对象、每次new时独立分配；静态变量在类加载时初始化，可通过类名直接访问，但静态方法不能直接访问实例成员，且存在线程安全与Spring容器管理风险。
静态变量属于类，实例变量属于对象
静态变量用 static 修饰，被所有实例共享，内存中只有一份；实例变量每次 new 对象时都会分配独立空间。这意味着修改某个对象的实例变量不会影响其他对象，但修改静态变量会立即反映在所有对象上。
常见错误是误把计数器、缓存、配置项等写成实例变量，导致状态不一致。比如实现单例计数器时用了实例变量：count++，结果每个对象都从 0 开始加，完全失去计数意义。
- 静态变量初始化在类加载时完成，早于任何对象创建
- 实例变量在构造方法执行前初始化（按声明顺序），每个对象一份
- 静态变量可通过
ClassName.fieldName直接访问，无需实例 - 实例变量必须通过对象引用访问，如
obj.fieldName
静态变量不能直接访问实例成员
在静态方法（如 main）或静态上下文中，无法直接使用 this、super，也不能访问非静态字段或方法——编译器会报错 non-static variable xxx cannot be referenced from a static context。
这是语言设计的强制隔离：静态属于类层级，实例属于对象层级，二者生命周期和作用域不同。想绕过这个限制，只能显式传入对象引用，或者把依赖也改成静态。
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
public static void printName() { System.out.println(name); } // name 是实例变量 - 正确写法：
public static void printName(Person p) { System.out.println(p.name); } - 或把
name改为static String name（但语义通常不合理）
静态变量的线程安全风险比实例变量更突出
多个线程同时读写同一个静态变量，极易引发竞态条件。而实例变量默认天然“线程封闭”——只要对象不被共享，每个线程操作的是自己的副本。
典型场景如工具类中的静态缓存：private static Map<string object> cache = new HashMap();</string>，如果没做同步，put 和 get 并发调用可能破坏内部结构，甚至抛出 ConcurrentModificationException。
- 简单场景可用
Collections.synchronizedMap()包装 - 高并发推荐
ConcurrentHashMap - 避免在静态块中执行耗时或阻塞操作（如数据库连接、文件读取）
- 注意类加载器隔离：不同类加载器加载的同一类，其静态变量互不干扰
静态变量在 Spring 等框架中容易被意外重用
Spring 默认 Bean 是单例（Singleton），但静态变量不受 Spring 容器管理。如果在某个 @Service 类里定义了 public static List<string> tempData</string>，它会在整个 JVM 生命周期内存在，跨请求、跨 Bean 持久化，极易造成数据污染。
更隐蔽的问题是：测试时反复启动/关闭 ApplicationContext，静态变量不会重置，导致测试间相互干扰。
- 不要用静态变量存用户会话数据、临时计算结果、上下文信息
- 若需全局状态，优先考虑 Spring 的
@Scope("prototype")或ThreadLocal - 单元测试中可手动清理静态字段（如 JUnit 5 的
@AfterAll方法），但治标不治本
static。 
