重庆江津网站建设,衡水做外贸网站,wordpress用户前台投稿,中国万网陈峰欣在JVM专题七#xff1a;JVM垃圾回收机制中提到JVM的垃圾回收机制是一个自动化的后台进程#xff0c;它通过周期性地检查和回收不可达的对象#xff08;垃圾#xff09;#xff0c;帮助管理内存资源#xff0c;确保应用程序的高效运行。今天就让我们来看看JVM到底是怎么定… 在JVM专题七JVM垃圾回收机制中提到JVM的垃圾回收机制是一个自动化的后台进程它通过周期性地检查和回收不可达的对象垃圾帮助管理内存资源确保应用程序的高效运行。今天就让我们来看看JVM到底是怎么定义“垃圾”对象的。 JVM垃圾对象判断方法
JVM在垃圾回收Garbage Collection简称GC过程中定义“垃圾”对象主要是根据对象是否还可达来判断。以下是一些判断对象是否成为垃圾的常见标准 引用计数法这是一种简单的垃圾回收方法每个对象都有一个引用计数器每当有引用指向该对象时计数器加一每当引用离开作用域或被赋值为null时计数器减一。当引用计数器为零时对象被认为是垃圾。但这种方法无法处理循环引用的问题。 可达性分析这是现代JVM中常用的垃圾回收方法。从一系列的“GC Roots”开始所有能够通过引用链到达的对象都被认为是存活的而那些无法到达的对象则被认为是垃圾。GC Roots通常包括 虚拟机栈栈帧中的本地变量表中的引用对象方法区中的类静态属性引用的对象运行时常量池中引用的对象JNIJava Native Interface的引用对象 不可达的对象即使对象不可达JVM也不会立即回收它们。JVM会将这些对象标记为“即将回收”的状态。在下一次垃圾回收周期中这些对象会被真正回收。 对象的finalize()方法如果对象在被标记为垃圾之前定义了finalize()方法JVM会给予对象最后一次“自救”的机会。在下一次垃圾回收时JVM会尝试调用这个对象的finalize()方法。如果对象在finalize()方法中重新与GC Roots建立了连接它将被移出即将回收的列表。 分代收集JVM通常采用分代收集算法将对象分为新生代和老年代。新生代中的对象通常存活时间较短而老年代中的对象存活时间较长。JVM会根据对象的年龄来决定它们应该在哪个区域。
垃圾回收是一个复杂的过程JVM会根据当前的内存使用情况和对象的生命周期来决定何时以及如何回收对象。
JVM回收对象示例
局部变量作为GC Roots public class App {public static void main(String[] args) {runApp(args);System.out.println();}private static void runApp(String[] args) {SpringApplication sApp new SpringApplication();sApp.run(App.class, args);
// sApp.getRunListeners(args);}
}public class SpringApplication {public String run(Class appClass, String[] args) {System.out.println(my Spring Application );return run args;}public String getRunListeners( String[] args) {System.out.println(My getRunListeners );String myRunListenersVar myRunListenersVar;this.getSpringFactoriesInstances(args);return run args;}public String getSpringFactoriesInstances( String[] args) {System.out.println(My getSpringFactoriesInstances );String mySpringFactoriesInstancesVar mySpringFactoriesInstances;return run args;}}上述代码中最关键的一段是 SpringApplication sApp new SpringApplication();代码分析如下图所示 JVM垃圾回收线程扫描到Spring Appliedcation发现它有一个GC Roots此时就不能回收了。
静态变量作为GC Roots
除了上述代码外咱们在看一个常见的代码。
public class App {public static SpringApplication sApp new SpringApplication();public static void main(String[] args) {runApp(args);System.out.println();}private static void runApp(String[] args) {SpringApplication sApp new SpringApplication();sApp.run(App.class, args);}
}
上述 public static SpringApplication sApp new SpringApplication() 代码分析如下图所示 JVM垃圾回收线程扫描到Spring Appliedcation发现它有一个GC Roots此时就不能回收了。相信有细心的小伙伴注意到这块代码与上述代码在示意图上的区别了他们GC Roots 所在区域不一样一个是在JVM栈中一个是在JVM的方法区且特意把颜色换成同堆内存一样的颜色其实就是想说这块区域是共享内存而局部变量是线程内存。
因此这里留一个小小的思考问题大家直观感受下这两个引用谁引用持有的时间会更长一点
简单总结只要对象被局部变量或静态变量引用就不会被回收。
Java中不同对象类型
我们在进行可达性分析的时候常常提到局部变量持有某个对象的引用或者静态变量持有某个对象引用但是我们脑海里需要清楚一个概率那就是java中有不同的引用类型他们分别是强引用、软引用、弱引用和虚引用。
强引用
强引用是最常见的引用类型它使得对象在任何情况下都不会被垃圾回收除非显式地将引用设置为null或超出作用域。如下代码所示
public class App {public static SpringApplication app new SpringApplication();
} 软引用
软引用提供了一种在内存不足时可以被回收的机制。它们通常用于缓存当内存足够时对象不会被回收但如果内存不足垃圾回收器会尝试回收这些对象。使用软引用可以提高应用的内存效率但需要权衡对象被回收的概率.
import java.lang.ref.SoftReference;
// ...public class ConfigurationPropertyUtils {// ...private static final SoftReferenceConfigurationPropertyCache cache new SoftReference(null);public static T T getCached(BeanFactory beanFactory, ClassT cacheType) {// ...SoftReferenceConfigurationPropertyCache ref cache;ConfigurationPropertyCache cpCache (ref ! null ? ref.get() : null);if (cpCache null) {cpCache new ConfigurationPropertyCache(beanFactory, cacheType);cache new SoftReference(cpCache);}// ...return cpCache.getProperty();}// ...
}
在这段代码中ConfigurationPropertyUtils类使用了一个静态的软引用cache来存储配置属性的缓存。当调用getCached方法时如果缓存不存在或已被垃圾回收就会创建一个新的ConfigurationPropertyCache实例并用软引用包装后存储起来。由于软引用对象在内存不足时会被回收这有助于减少垃圾回收器的压力避免长时间的GC停顿提高应用的响应性。
所以在软引用放到缓存这个场景就非常实用想想内存充足我就不回收内存不够了我回收而缓存基本上都是为了提升性能的现在内存都不足了还有啥自行车能运行就不错啦
弱引用
弱引用不会阻止垃圾回收器回收对象即使内存充足也会被回收。它们通常用于监听或观察对象的状态而不阻止对象的回收。弱引用在内存不足时更有可能被回收因为它们对对象的生命周期没有任何控制。
public class ThreadPoolTaskExecutor extends ExecutorConfigurationSupportimplements AsyncListenableTaskExecutor, SchedulingTaskExecutor {private final Object poolSizeMonitor new Object();private int corePoolSize 1;private int maxPoolSize Integer.MAX_VALUE;private int keepAliveSeconds 60;private int queueCapacity Integer.MAX_VALUE;private boolean allowCoreThreadTimeOut false;Nullableprivate TaskDecorator taskDecorator;Nullableprivate ThreadPoolExecutor threadPoolExecutor;// Runnable decorator to user-level FutureTask, if different
// 聚焦这里哈private final MapRunnable, Object decoratedTaskMap new ConcurrentReferenceHashMap(16, ConcurrentReferenceHashMap.ReferenceType.WEAK);} 上述代码是Spring的ThreadPoolTaskExecutor节选部分注意ThreadPoolTaskExecutor本身并不直接使用弱引用来引用任务对象。它主要使用弱引用来缓存线程池中的Future任务以便在内存不足时可以回收这些不再需要的Future对象。这样做可以避免因缓存大量已完成或取消的任务的Future引用而导致的内存泄漏问题。 一个对象被线程池持有强引用那么即使这个对象不再被其他地方使用它也不会被垃圾回收器回收因为线程池中的引用阻止了垃圾回收。使用弱引用可以确保当没有其他强引用存在时线程池中的任务可以被垃圾回收。
虚引用
虚引用是最弱的引用类型它们几乎不提供任何保护对象可以随时被回收。虚引用的主要作用是跟踪对象被回收的状态通过ReferenceQueue来接收通知。
因为虚引用接触比较少暂时就不讨论了下面对他们四个应用简单总结下
强引用只要强引用存在对象就不会被垃圾回收。软引用内存不足时软引用对象会被垃圾回收适用于缓存等场景。弱引用弱引用对象在下一次垃圾回收时会被回收适合用于监听或观察对象状态。虚引用虚引用几乎不阻止对象回收主要用于跟踪对象被垃圾回收的状态
到这里我们已经Java介绍完垃圾对象的判断方法并举出例子演示给大家看同样提出几个问题我们在介绍完GC Roots的时候分为不同类型的时候提出问题他们引用时间的长短对于引用时间长短不同可以等价不同的对象实例存活时间。不同对象回收的机制一样嘛如果不一样根据什么特点区分呢回收以后内存空间要怎么整理呢本章结束有时间小伙伴可以回头看看前面的文章回忆下各个区域的特点和整个分配的过程。从下一章我们将开始慢慢介绍GC算法需要前面的铺垫。 专题汇总
JVM专题一深入分析Java工作机制
JVM专题二Java如何进行编译的
JVM专题三Java代码如何运行
JVM专题四JVM的类加载机制
JVM专题五类加载器与双亲委派机制
JVM专题六JVM的内存模型
JVM专题七JVM垃圾回收机制
JVM专题八JVM如何判断可回收对象
JVM专题九JVM分代知识点梳理
JVM专题十JVM中的垃圾回收机制
JVM专题十一JVM 中的收集器一
JVM专题十二JVM 中的收集器二
JVM专题十三总结与整理面试常用
