一般我们不必关心Java的垃圾回收问题，JVM会帮我们处理；但是如果对JVM的GC机制不了解，可能会写出很影响性能的代码

text
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 
  在此之前，我们需要了解到JVM垃圾的回收的时候，有可能出现的一种情况：stop-the-world，即JVM判定有大量垃圾需要回收，除了GC线程外，其他线程均处于阻塞状态，知道GC任务完成。所以针对GC的优化工作就是主要是减少stop-the-world触发次数（一般来说就是Full GC）。


  JVM的垃圾回收，针对的是堆内存空间和方法区，而栈内存空间的数据会在超出作用域后JVM自动清理，不归GC管理。



  通常来说，堆内存空间被大致分为


        年轻代：对象被创建后被放入老年代，大部分对象会在这个区域保存直到销毁，但是GC多次运行后依然存在的对象会根据存活时间，依次移到老年代



        老年代: 所占用的空间要比年轻代大得多



        在年轻代的清理称为MinorGC,年老代称为Full GC



        GC对于年轻代 老年代 区域的扫描频率是不一样的，相对来说老年代扫描频率低很多



  一般来说GC通过一下的条件判断是否回收



  1.对象没有引用



  2.作用域发生未捕获的异常



  3.程序在作用域内正常执行完毕



  4.程序意外停止（如 kill -9 线程）



  5.执行System.exit()



  当然我们把杜对象显式的=null 后也是可以的



  注意以上情况只是被标记为可回收，但具体什么时间回收有JVM判断







  通常的优化做法是设置年轻代转年老代的转换比例/年龄阈值

=============================================

漏掉了持久区（方法区）的GC回收介绍

必须满足以下三个条件

1.所有实例都被回收

2.加载该类的类加载器被回收

3.Class对象无法通过任何对象被访问

原文地址：https://blog.csdn.net/xsf1840/article/details/79979200?ops_request_misc=&request_id=42e68fa23fde409eb981631ce130651a&biz_id=&utm_medium=distribute.pc_search_result.none-task-blog-2~all~koosearch~default-9-79979200-null-null.142^v88^insert_down28v1,239^v2^insert_chatgpt&utm_term=java%E4%BC%98%E5%8C%96