static用于明确成员属于类而非实例，满足共享性或脱离对象存在时使用；适用于全局变量、常量、工具方法、类初始化；误用会导致状态污染、内存泄漏和线程安全问题。
Java中用static不是为了“加个修饰符”，而是明确告诉JVM：这个成员属于类本身，不随对象而生，也不因对象而灭。关键在“要不要被所有实例共享”和“能不能脱离对象存在”——满足其一，就该考虑static。
需要全局唯一值时用static变量
当某个数据对所有对象都一样，且修改后需同步生效，它就该是静态变量。比如学校名称、系统版本号、数据库连接池大小。这类信息不随个体变化，重复存多份纯属浪费内存，还增加维护成本。
- 用
public static final定义常量（如PI、MAX_RETRY），编译期确定，安全又高效 - 用
private static封装内部状态（如计数器、缓存容器），通过公共静态方法控制访问 - 避免直接用对象引用修改静态变量（如
obj.count++），易误导他人以为是实例行为
无需对象上下文的方法用static方法
如果一个方法只依赖传入参数，不读写任何实例字段，也不调用实例方法，那它天然适合声明为static。典型如工具类中的字符串处理、数学计算、JSON解析等。
-
main必须是static——程序启动时还没对象，只能靠类名触发 - 静态方法里不能直接访问
this、实例变量或非静态方法，否则编译报错 - 可以放心被任意线程调用（前提是方法体本身无共享可变状态）
类加载时就要执行的逻辑用static代码块
有些初始化操作只需做一次，比如读配置文件、注册驱动、预热缓存。放在static代码块里，能确保在类第一次被使用前完成，且仅执行一次。
- 多个
static块按书写顺序执行，早于任何构造方法 - 适合放轻量级、确定成功的初始化；重逻辑或可能抛异常的，建议改用静态方法+显式调用
- 不能访问实例成员，但可操作静态变量和调用静态方法
避免误用static的三个典型陷阱
static不是万能钥匙，强行套用会埋下隐患。
- 把本该随对象隔离的状态设为静态（如用户登录态、临时缓冲区），导致多实例互相干扰
- 在静态方法里new大量对象却不释放，容易引发内存泄漏（尤其在Web容器中）
- 忽略线程安全：多个线程同时修改同一个静态变量，结果不可预测，需配合
synchronized或原子类
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
