静态成员本身不会被垃圾回收器回收，其生命周期完全绑定类：随类加载而初始化，存于方法区（元空间），仅当类被卸载时才释放，而类卸载需满足类实例全回收、类加载器不可达、class对象无强引用三个严苛条件，实践中几乎永不发生。
静态成员本身不会被垃圾回收器单独回收，它的生命周期完全绑定在类上。
静态成员的内存归属
静态变量和静态方法属于类，存储在方法区（JDK 8+ 后为元空间），不是堆中的对象。它们随类加载而初始化，不依赖任何实例存在。
- 类加载时，静态变量完成初始化并分配内存
- 只要类还活着，静态变量就一直存在
- 即使所有该类的实例都被回收，静态变量仍保留在内存中
静态成员何时可能“消失”
静态成员只有在它所属的类被彻底卸载时才会释放，而这需要同时满足三个严格条件：
- 该类的所有实例（包括子类实例）都已被垃圾回收
- 加载该类的类加载器本身已变成不可达对象（即也被判定为垃圾）
- 该类对应的 java.lang.Class 对象没有任何强引用（例如没被缓存、没传给反射或 JNI）
这三个条件极少同时成立，尤其在主流应用服务器（如 Tomcat）或 Spring 环境中，类加载器通常长期存活，因此静态成员几乎等同于“永不回收”。
容易被误认为“回收”的情况
实际开发中，常有以下情形让人误以为静态变量被回收了：
- 静态变量被重新赋值为 null 或新对象：原引用指向的对象可能被回收，但静态变量本身（字段容器）仍在
- 使用弱引用/软引用包装静态缓存：被包装的对象可被回收，但静态字段仍持有弱引用对象
- Web 应用热部署失败后旧类残留：看似“类卸载”，实则因引用未清导致类无法卸载，静态成员持续占用内存
实践建议
避免因静态成员引发内存泄漏：
- 不在静态变量中长期持有大对象（如缓存全量用户数据、未关闭的连接池）
- 若必须缓存，优先选用 WeakReference 或 SoftReference，或使用 ConcurrentHashMap + 定期清理
- 在模块卸载或上下文销毁时（如 ServletContextListener#contextDestroyed），显式清空关键静态引用
- 排查内存泄漏时，重点关注 static 字段引用的堆对象是否意外延长了生命周期
