小白日更第三十九天-＞静态变量什么时候被回收

要想真正的知道这个问题的答案，需要一点jvm的基础。

静态变量什么时候分配

静态变量是在类初始化之前就在方法去的静态域中分配内存空间了。

静态变量在类被卸载的时候销毁。

那什么时候类卸载呢？
在<深入理解Java虚拟机：JVM高级特性与最佳实践（第3版） 周志明>3.2.5回收方法区中有这样几段话，供小伙伴们参考~

有些人认为方法区（如HotSpot虚拟机中的元空间或者永久代） 是没有垃圾收集行为的， 《Java虚
拟机规范》 中提到过可以不要求虚拟机在方法区中实现垃圾收集， 事实上也确实有未实现或未能完整
实现方法区类型卸载的收集器存在（如JDK 11时期的ZGC收集器就不支持类卸载） ， 方法区垃圾收集
的“性价比”通常也是比较低的： 在Java堆中， 尤其是在新生代中， 对常规应用进行一次垃圾收集通常
可以回收70%至99%的内存空间， 相比之下， 方法区回收囿于苛刻的判定条件， 其区域垃圾收集的回
收成果往往远低于此。
方法区的垃圾收集主要回收两部分内容： 废弃的常量和不再使用的类型。 回收废弃常量与回收
Java堆中的对象非常类似。 举个常量池中字面量回收的例子， 假如一个字符串“java”曾经进入常量池
中， 但是当前系统又没有任何一个字符串对象的值是“java”， 换句话说， 已经没有任何字符串对象引用
常量池中的“java”常量， 且虚拟机中也没有其他地方引用这个字面量。 如果在这时发生内存回收， 而且
垃圾收集器判断确有必要的话， 这个“java”常量就将会被系统清理出常量池。 常量池中其他类（接
口） 、 方法、 字段的符号引用也与此类似。
判定一个常量是否“废弃”还是相对简单， 而要判定一个类型是否属于“不再被使用的类”的条件就
比较苛刻了。 需要同时满足下面三个条件：
·该类所有的实例都已经被回收， 也就是Java堆中不存在该类及其任何派生子类的实例。
·加载该类的类加载器已经被回收， 这个条件除非是经过精心设计的可替换类加载器的场景， 如
OSGi、 JSP的重加载等， 否则通常是很难达成的。
·该类对应的java.lang.Class对象没有在任何地方被引用， 无法在任何地方通过反射访问该类的方
法。
Java虚拟机被允许对满足上述三个条件的无用类进行回收， 这里说的仅仅是“被允许”， 而并不是
和对象一样， 没有引用了就必然会回收。 关于是否要对类型进行回收， HotSpot虚拟机提供了-
Xnoclassgc参数进行控制， 还可以使用-verbose： class以及-XX： +TraceClass-Loading、 -XX：
+TraceClassUnLoading查看类加载和卸载信息， 其中-verbose： class和-XX： +TraceClassLoading可以在
Product版的虚拟机中使用， -XX： +TraceClassUnLoading参数需要FastDebug版[1]的虚拟机支持。
在大量使用反射、 动态代理、 CGLib等字节码框架， 动态生成JSP以及OSGi这类频繁自定义类加载
器的场景中， 通常都需要Java虚拟机具备类型卸载的能力， 以保证不会对方法区造成过大的内存压
力。

总结：
·该类所有的实例都已经被回收， 也就是Java堆中不存在该类及其任何派生子类的实例。
·加载该类的类加载器已经被回收， 这个条件除非是经过精心设计的可替换类加载器的场景， 如OSGi、 JSP的重加载等， 否则通常是很难达成的。
·该类对应的java.lang.Class对象没有在任何地方被引用， 无法在任何地方通过反射访问该类的方法。

以上就是我的理解，以及书中的内容。(好像都是书中的内容哈哈)