java类什么时候被卸载？java的类加载后什么时候会被释放

大家好，关于java类什么时候被卸载很多朋友都还不太明白，今天小编就来为大家分享关于java的类加载后什么时候会被释放的知识，希望对各位有所帮助！

Java垃圾回收:GC在什么时候对什么做了什么

GC在什么时候对什么做了什么？

要回答这个问题，先了解下GC的发展史、jvm运行时数据区的划分、jvm内存分配策略、jvm垃圾收集算法等知识。

先说下jvm运行时数据的划分，粗暴的分可以分为堆区(Heap)和栈区(Stack)，但jvm的分法实际上比这复杂得多，大概分为下面几块：

1、程序计数器(Program Conuter Register)

程序计数器是一块较小的内存空间，它是当前线程执行字节码的行号指示器，字节码解释工作器就是通过改变这个计数器的值来选取下一条需要执行的指令。它是线程私有的内存，也是唯一一个没有OOM异常的区域。

2、Java虚拟机栈区(Java Virtual Machine Stacks)

也就是通常所说的栈区，它描述的是Java方法执行的内存模型，每个方法被执行的时候都创建一个栈帧(Stack Frame)，用于存储局部变量表、操作数栈、动态链接、方法出口等。每个方法被调用到完成，相当于一个栈帧在虚拟机栈中从入栈到出栈的过程。此区域也是线程私有的内存，可能抛出两种异常：如果线程请求的栈深度大于虚拟机允许的深度将抛出StackOverflowError；如果虚拟机栈可以动态的扩展，扩展到无法动态的申请到足够的内存时会抛出OOM异常。

3、本地方法栈(Native Method Stacks)

本地方法栈与虚拟机栈发挥的作用非常相似，区别就是虚拟机栈为虚拟机执行Java方法，本地方法栈则是为虚拟机使用到的Native方法服务。

4、堆区(Heap)

所有对象实例和数组都在堆区上分配，堆区是GC主要管理的区域。堆区还可以细分为新生代、老年代，新生代还分为一个Eden区和两个Survivor区。此块内存为所有线程共享区域，当堆中没有足够内存完成实例分配时会抛出OOM异常。

5、方法区(Method Area)

方法区也是所有线程共享区，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。GC在这个区域很少出现，这个区域内存回收的目标主要是对常量池的回收和类型的卸载，回收的内存比较少，所以也有称这个区域为永久代(Permanent Generation)的。当方法区无法满足内存分配时抛出OOM异常。

6、运行时常量池(Runtime Constant Pool)

运行时常量池是方法区的一部分，用于存放编译期生成的各种字面量和符号引用。

垃圾收集(Garbage Collection)并不是Java独有的，最早是出现在Lisp语言中，它做的事就是自动管理内存，也就是下面三个问题：

1、什么时候回收

2、哪些内存需要回收

3、如何回收

1、什么时候回收？

上面说到GC经常发生的区域是堆区，堆区还可以细分为新生代、老年代，新生代还分为一个Eden区和两个Survivor区。

1.1对象优先在Eden中分配，当Eden中没有足够空间时，虚拟机将发生一次Minor GC，因为Java大多数对象都是朝生夕灭，所以Minor GC非常频繁，而且速度也很快；

1.2 Full GC，发生在老年代的GC，当老年代没有足够的空间时即发生Full GC，发生Full GC一般都会有一次Minor GC。大对象直接进入老年代，如很长的字符串数组，虚拟机提供一个-XX:PretenureSizeThreadhold参数，令大于这个参数值的对象直接在老年代中分配，避免在Eden区和两个Survivor区发生大量的内存拷贝；

1.3发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，如果大于，则进行一次Full GC，如果小于，则查看HandlePromotionFailure设置是否允许担保失败，如果允许，那只会进行一次Minor GC，如果不允许，则改为进行一次Full GC。

2、哪些内存需要回收

jvm对不可用的对象进行回收，哪些对象是可用的，哪些是不可用的？Java并不是采用引用计数算法来判定对象是否可用，而是采用根搜索算法(GC Root Tracing)，当一个对象到GC Roots没有任何引用相连接，用图论的来说就是从GC Roots到这个对象不可达，则证明此对象是不可用的，说明此对象可以被GC。对于这些不可达对象，也不是一下子就被GC，而是至少要经历两次标记过程：如果对象在进行根搜索算法后发现没有与GC Roots相连接的引用链，那它将会第一次标记并且进行一次筛选，筛选条件是此对象有没有必要执行finalize()方法，当对象没有覆盖finalize()方法或者finalize()方法已经被虚拟机调用执行过一次，这两种情况都被视为没有必要执行finalize()方法，对于没有必要执行finalize()方法的将会被GC，对于有必要有必要执行的，对象在finalize()方法中可能会自救，也就是重新与引用链上的任何一个对象建立关联即可。

3、如何回收

选择不同的垃圾收集器，所使用的收集算法也不同。

在新生代中，每次垃圾收集都发现有大批对象死去，只有少量存活，则使用复制算法，新生代内存被分为一个较大的Eden区和两个较小的Survivor区，每次只使用Eden区和一个Survivor区，当回收时将Eden区和Survivor还存活着的对象一次性的拷贝到另一个Survivor区上，最后清理掉Eden区和刚才使用过的Survivor区，Eden和Survivor的默认比例是8：1，可以使用-XX:SurvivorRatio来设置该比例。

而老年代中对象存活率高，没有额外的空间对它进行分配担保，必须使用“标记-清理”或“标记-整理”算法。

android static 什么时候被回收

android中，定义的static变量属于全局变量，不会被GC回收,它们会一直占用内存。直到程序结束时才会被回收。

Android是用Java开发，其静态变量的生命周期遵守Java的设计。静态变量是在类被load的时候分配内存的，并且存在于方法区。当类被卸载的时候，静态变量被销毁。在PC机的客户端程序中，一个类被加载和卸载，可简单的等同于jvm进程的启动和结束。

一、静态变量在类被加载的时候分配内存。

当启动一个app的时候，系统会创建一个进程，此进程会加载一个Dalvik VM的实例，然后代码就运行在DVM之上，类的加载和卸载，垃圾回收等事情都由DVM负责。也就是说在进程启动的时候，类被加载，静态变量被分配内存。

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

一般情况下，所有的类都是默认的ClassLoader加载的，只要ClassLoader存在，类就不会被卸载，而默认的ClassLoader生命周期是与进程一致的。

java的类加载后什么时候会被释放

java的类加载后且当使用阶段完成之后，java类就进入了卸载阶段，也就是所谓的释放。

使用阶段包括主动引用和被动引用，主动饮用会引起类的初始化，而被动引用不会引起类的初始化。

一个java类的完整的生命周期会经历加载、连接、初始化、使用、和卸载五个阶段，当然也有在加载或者连接之后没有被初始化就直接被使用的情况，如图所示：

PS：关于类的卸载，在类使用完之后，如果满足下面的情况，类就会被卸载：

该类所有的实例都已经被回收，也就是java堆中不存在该类的任何实例。

加载该类的ClassLoader已经被回收。

该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。

如果以上三个条件全部满足，jvm就会在方法区垃圾回收的时候对类进行卸载，类的卸载过程其实就是在方法区中清空类信息，java类的整个生命周期就结束了。

hibernate二级缓存什么时候用

Hibernate缓存何时使用和如何使用？

Hibernate缓存分为二级，第一级存放于session中称为一级缓存，默认带有且不能卸载。第二级是由sessionFactory控制的进程级缓存。是全局共享的缓存，凡是会调用二级缓存的查询方法都会从中受益。

1.关于hibernate缓存的问题：

1.1.基本的缓存原理

Hibernate缓存分为二级，

第一级存放于session中称为一级缓存，默认带有且不能卸载。

第二级是由sessionFactory控制的进程级缓存。是全局共享的缓存，凡是会调用二级缓存的查询方法都会从中受益。只有经正确的配置后二级缓存才会发挥作用。同时在进行条件查询时必须使用相应的方法才能从缓存中获取数据。比如 Query.iterate()方法、load、get方法等。必须注意的是session.find方法永远是从数据库中获取数据，不会从二级缓存中获取数据，即便其中有其所需要的数据也是如此。

查询时使用缓存的实现过程为：首先查询一级缓存中是否具有需要的数据，如果没有，查询二级缓存，如果二级缓存中也没有，此时再执行查询数据库的工作。要注意的是：此3种方式的查询速度是依次降低的。

1.2.存在的问题

1.2.1.一级缓存的问题以及使用二级缓存的原因

因为Session的生命期往往很短，存在于Session内部的第一级最快缓存的生命期当然也很短，所以第一级缓存的命中率是很低的。其对系统性能的改善也是很有限的。当然，这个Session内部缓存的主要作用是保持Session内部数据状态同步。并非是hibernate为了大幅提高系统性能所提供的。

为了提高使用hibernate的性能，除了常规的一些需要注意的方法比如：

使用延迟加载、迫切外连接、查询过滤等以外，还需要配置hibernate的二级缓存。其对系统整体性能的改善往往具有立竿见影的效果！

（经过自己以前作项目的经验，一般会有3~4倍的性能提高）

1.2.2. N+1次查询的问题

1.2.2.1什么时候会遇到1+N的问题？

前提：Hibernate默认表与表的关联方法是fetch="select"，不是fetch="join",这都是为了懒加载而准备的。

1）一对多(<set><list>)，在1的这方，通过1条sql查找得到了1个对象，由于关联的存在，那么又需要将这个对象关联的集合取出，所以合集数量是n还要发出n条sql，于是本来的1条sql查询变成了1+n条。

2）多对一<many-to-one>，在多的这方，通过1条sql查询得到了n个对象，由于关联的存在,也会将这n个对象对应的1方的对象取出，于是本来的1条sql查询变成了1+n条。

3）iterator查询时,一定先去缓存中找（1条sql查集合,只查出ID），在没命中时，会再按ID到库中逐一查找，产生1+n条SQL

1.2.2.2怎么解决1+N问题？

1）lazy=true， hibernate3开始已经默认是lazy=true了；lazy=true时不会立刻查询关联对象，只有当需要关联对象（访问其属性，非id字段）时才会发生查询动作。

2）使用二级缓存，二级缓存的应用将不怕1+N问题，因为即使第一次查询很慢（未命中），以后查询直接缓存命中也是很快的。刚好又利用了1+N。

3)当然你也可以设定fetch="join"，一次关联表全查出来，但失去了懒加载的特性。

执行条件查询时，iterate（）方法具有著名的“n+1”次查询的问题，也就是说在第一次查询时iterate方法会执行满足条件的查询结果数再加一次（n+1）的查询。但是此问题只存在于第一次查询时，在后面执行相同查询时性能会得到极大的改善。此方法适合于查询数据量较大的业务数据。

但是注意：当数据量特别大时（比如流水线数据等）需要针对此持久化对象配置其具体的缓存策略，比如设置其存在于缓存中的最大记录数、缓存存在的时间等参数，以避免系统将大量的数据同时装载入内存中引起内存资源的迅速耗尽，反而降低系统的性能！！！

1.3.使用hibernate二级缓存的其他注意事项：

1.3.1.关于数据的有效性

另外，hibernate会自行维护二级缓存中的数据，以保证缓存中的数据和数据库中的真实数据的一致性！无论何时，当你调用save()、 update()或 saveOrUpdate()方法传递一个对象时，或使用load()、 get()、list()、iterate()或scroll()方法获得一个对象时,该对象都将被加入到Session的内部缓存中。当随后flush()方法被调用时，对象的状态会和数据库取得同步。

也就是说删除、更新、增加数据的时候，同时更新缓存。当然这也包括二级缓存！

只要是调用hibernate API执行数据库相关的工作。hibernate都会为你自动保证缓存数据的有效性！！

但是，如果你使用了JDBC绕过hibernate直接执行对数据库的操作。此时，Hibernate不会/也不可能自行感知到数据库被进行的变化改动，也就不能再保证缓存中数据的有效性！！

这也是所有的ORM产品共同具有的问题。幸运的是，Hibernate为我们暴露了Cache的清除方法，这给我们提供了一个手动保证数据有效性的机会！！

一级缓存，二级缓存都有相应的清除方法。

其中二级缓存提供的清除方法为：

按对象class清空缓存

按对象class和对象的主键id清空缓存

清空对象的集合中的缓存数据等。

1.3.2.适合使用的情况

并非所有的情况都适合于使用二级缓存，需要根据具体情况来决定。同时可以针对某一个持久化对象配置其具体的缓存策略。

适合于使用二级缓存的情况：

1、数据不会被第三方修改；

一般情况下，会被hibernate以外修改的数据最好不要配置二级缓存，以免引起不一致的数据。但是如果此数据因为性能的原因需要被缓存，同时又有可能被第3方比如SQL修改，也可以为其配置二级缓存。只是此时需要在sql执行修改后手动调用cache的清除方法。以保证数据的一致性

2、数据大小在可接收范围之内；

如果数据表数据量特别巨大，此时不适合于二级缓存。原因是缓存的数据量过大可能会引起内存资源紧张，反而降低性能。

如果数据表数据量特别巨大，但是经常使用的往往只是较新的那部分数据。此时，也可为其配置二级缓存。但是必须单独配置其持久化类的缓存策略，比如最大缓存数、缓存过期时间等，将这些参数降低至一个合理的范围（太高会引起内存资源紧张，太低了缓存的意义不大）。

3、数据更新频率低；

对于数据更新频率过高的数据，频繁同步缓存中数据的代价可能和查询缓存中的数据从中获得的好处相当，坏处益处相抵消。此时缓存的意义也不大。

4、非关键数据（不是财务数据等）

财务数据等是非常重要的数据，绝对不允许出现或使用无效的数据，所以此时为了安全起见最好不要使用二级缓存。

因为此时“正确性”的重要性远远大于“高性能”的重要性。

2.目前系统中使用hibernate缓存的建议

2.1.目前情况

一般系统中有三种情况会绕开hibernate执行数据库操作：

1、多个应用系统同时访问一个数据库

此种情况使用hibernate二级缓存会不可避免的造成数据不一致的问题，此时要进行详细的设计。比如在设计上避免对同一数据表的同时的写入操作，

使用数据库各种级别的锁定机制等。

2、动态表相关

所谓“动态表”是指在系统运行时根据用户的操作系统自动建立的数据表。

比如“自定义表单”等属于用户自定义扩展开发性质的功能模块，因为此时数据表是运行时建立的，所以不能进行hibernate的映射。因此对它的操作只能是绕开hibernate的直接数据库JDBC操作。

如果此时动态表中的数据没有设计缓存，就不存在数据不一致的问题。

如果此时自行设计了缓存机制，则调用自己的缓存同步方法即可。

3、使用sql对hibernate持久化对象表进行批量删除时

此时执行批量删除后，缓存中会存在已被删除的数据。

分析：

当执行了第3条（sql批量删除）后，后续的查询只可能是以下三种方式：

a. session.find（）方法：

根据前面的总结，find方法不会查询二级缓存的数据，而是直接查询数据库。

所以不存在数据有效性的问题。

b.调用iterate方法执行条件查询时：

根据iterate查询方法的执行方式，其每次都会到数据库中查询满足条件的id值，然后再根据此id到缓存中获取数据，当缓存中没有此id的数据才会执行数据库查询；

如果此记录已被sql直接删除，则iterate在执行id查询时不会将此id查询出来。所以，即便缓存中有此条记录也不会被客户获得，也就不存在不一致的情况。（此情况经过测试验证）

c.用get或load方法按id执行查询：

客观上此时会查询得到已过期的数据。但是又因为系统中执行sql批量删除一般是针对中间关联数据表，对于中间关联表的查询一般都是采用条件查询,按id来查询某一条关联关系的几率很低,所以此问题也不存在!

如果某个值对象确实需要按id查询一条关联关系,同时又因为数据量大使用了sql执行批量删除。当满足此两个条件时,为了保证按id的查询得到正确的结果,可以使用手动清楚二级缓存中此对象的数据的方法!!(此种情况出现的可能性较小)

2.2.建议

1、建议不要使用sql直接执行数据持久化对象的数据的更新，但是可以执行批量删除。（系统中需要批量更新的地方也较少）

2、如果必须使用sql执行数据的更新，必须清空此对象的缓存数据。调用

SessionFactory.evict(class)

SessionFactory.evict(class,id)等方法。

3、在批量删除数据量不大的时候可以直接采用hibernate的批量删除，这样就不存在绕开hibernate执行sql产生的缓存数据一致性的问题。

4、不推荐采用hibernate的批量删除方法来删除大批量的记录数据。

原因是hibernate的批量删除会执行1条查询语句外加满足条件的n条删除语句。而不是一次执行一条条件删除语句！！

当待删除的数据很多时会有很大的性能瓶颈！！！如果批量删除数据量较大,比如超过50条,可以采用JDBC直接删除。这样作的好处是只执行一条sql删除语句,性能会有很大的改善。同时，缓存数据同步的问题,可以采用 hibernate清除二级缓存中的相关数据的方法。

调用

SessionFactory.evict(class);

SessionFactory.evict(class,id)等方法。

所以说，对于一般的应用系统开发而言（不涉及到集群，分布式数据同步问题等），因为只在中间关联表执行批量删除时调用了sql执行，同时中间关联表一般是执行条件查询不太可能执行按id查询。所以，此时可以直接执行sql删除，甚至不需要调用缓存的清除方法。这样做不会导致以后配置了二级缓存引起数据有效性的问题。

退一步说，即使以后真的调用了按id查询中间表对象的方法，也可以通过调用清除缓存的方法来解决。

3、具体的配置方法

根据我了解的很多hibernate的使用者在调用其相应方法时都迷信的相信“hibernate会自行为我们处理性能的问题”，或者“hibernate会自动为我们的所有操作调用缓存”,实际的情况是hibernate虽然为我们提供了很好的缓存机制和扩展缓存框架的支持，但是必须经过正确的调用其才有可能发挥作用！！所以造成很多使用hibernate的系统的性能问题，实际上并不是hibernate不行或者不好，而是因为使用者没有正确的了解其使用方法造成的。相反，如果配置得当hibernate的性能表现会让你有相当“惊喜的”发现。下面我讲解具体的配置方法。

ibernate提供了二级缓存的接口：

net.sf.hibernate.cache.Provider,

同时提供了一个默认的实现net.sf.hibernate.cache.HashtableCacheProvider，

也可以配置其他的实现比如ehcache,jbosscache等。

具体的配置位置位于hibernate.cfg.xml文件中

<propertyname="hibernate.cache.use_query_cache">true</property>

<propertyname="hibernate.cache.provider_class">net.sf.hibernate.cache.HashtableCacheProvider</property>

很多的hibernate使用者在配置到这一步就以为完事了，

注意：其实光这样配，根本就没有使用hibernate的二级缓存。同时因为他们在使用hibernate时大多时候是马上关闭session，所以，一级缓存也没有起到任何作用。结果就是没有使用任何缓存，所有的hibernate操作都是直接操作的数据库！！性能可以想见。

正确的办法是除了以上的配置外还应该配置每一个vo对象的具体缓存策略，在影射文件中配置。例如：

<hibernate-mapping>

<classname="com.sobey.sbm.model.entitySystem.vo.DataTypeVO"table="dcm_datatype">

<cacheusage="read-write"/>

<idname="id"column="TYPEID"type="java.lang.Long">

<generatorclass="sequence"/>

</id>

<propertyname="name"column="NAME"type="java.lang.String"/>

<propertyname="dbType"column="DBTYPE"type="java.lang.String"/>

</class>

</hibernate-mapping>

关键就是这个<cache usage="read-write"/>，其有几个选择read-only,read-write,transactional,等

然后在执行查询时注意了，如果是条件查询，或者返回所有结果的查询，此时session.find()方法不会获取缓存中的数据。只有调用query.iterate()方法时才会调缓存的数据。

同时 get和 load方法是都会查询缓存中的数据

如果你还想了解更多这方面的信息，记得收藏关注本站。