Java 的自动内存管理主要是针对对象内存的回收和对象内存的分配。同时,Java 自动内存管理最核心的功能是 堆 内存中对象的分配与回收。
Java 堆是垃圾收集器管理的主要区域,因此也被称作 GC 堆(Garbage Collected Heap)。
从垃圾回收的角度来说,由于现在收集器基本都采用分代垃圾收集算法,所以 Java 堆被划分为了几个不同的区域,这样我们就可以根据各个区域的特点选择合适的垃圾收集算法。
在 JDK 7 版本及 JDK 7 版本之前,堆内存被通常分为下面三部分:
下图所示的 Eden 区、两个 Survivor 区 S0 和 S1 都属于新生代,中间一层属于老年代,最下面一层属于永久代。

JDK 1.8 及之后 PermGen(永久代) 已被 Metaspace(元空间) 取代,元空间使用的是直接内存 。
关于Java内存区域的详细介绍,请参考这篇文章——JVM面试题详解系列——JVM内存区域详解。
在Java虚拟机规范中,方法区被定义为堆的一个逻辑部分,但是与Java堆的其他部分(如新生代、老年代)不同,方法区是非堆(Non-Heap)内存,因为它不是由Java堆管理的内存区域。而Java堆主要包括新生代和老年代,以及元数据区(在Java 8及以上版本中)。
因此,Java堆内存主要分为以下几个部分:
新生代(Young Generation):用于存放新创建的对象,分为Eden区和两个Survivor区(S0和S1)。
老年代(Old Generation):用于存放长期存活的对象,大多数情况下,新生代中的对象经过多次垃圾回收后,如果仍然存活,就会被移到老年代。
元数据区(Meta Space):在Java 8及以上版本中,用于存放JVM加载的类信息、常量池、方法等,取代了原来的永久代。因此,方法区(或永久代/元数据区)是Java堆的逻辑部分,但是它不是Java堆的实际组成部分,而是Java堆之外的一块非堆内存。
在Java虚拟机规范中,方法区被定义为堆的一个逻辑部分,但是与Java堆的其他部分(如新生代、老年代)不同,方法区是非堆(Non-Heap)内存,因为它不是由Java堆管理的内存区域。而Java堆主要包括新生代和老年代,以及元数据区(在Java 8及以上版本中)。
因此,Java堆内存主要分为以下几个部分:
新生代(Young Generation):用于存放新创建的对象,分为Eden区和两个Survivor区(S0和S1)。
老年代(Old Generation):用于存放长期存活的对象,大多数情况下,新生代中的对象经过多次垃圾回收后,如果仍然存活,就会被移到老年代。
元数据区(Meta Space):在Java 8及以上版本中,用于存放JVM加载的类信息、常量池、方法等,取代了原来的永久代。因此,方法区(或永久代/元数据区)是Java堆的逻辑部分,但是它不是Java堆的实际组成部分,而是Java堆之外的一块非堆内存。
大多数情况下,对象在新生代的 Eden 区分配。当 Eden 区没有足够的空间时,虚拟机将发起一次 Minor GC。
既然虚拟机采用了分代回收的思想来管理内存,那么就必须识别哪些对象应该放在新生代,哪些对象应该放在老年代。为了做到这一点,虚拟机给每个对象一个对象年龄(Age)计数器。
大多谁情况下,对象首先在 Eden 区分配。如果对象在 Eden 区出生,并且经历了一次 Minor GC 后仍能够存活,并且能够被 Survivor 区容纳,将被移动到 Survivor 区(S0 或 S1),并将对象年龄设为1(Eden 区 -> Survivor 区后对象的初始年龄变为 1)。
对象在 Survivor 中每熬过一次 Minor GC,年龄就增加 1 岁,当它的年龄增加到一定程度(晋升老年代的年龄阈值—MaxTenuringThreshold),就会被晋升到老年代中。对象晋升到老年代的年龄阈值,可以通过参数 -XX:MaxTenuringThreshold 来设置。
Hotspot 遍历所有对象时,按照年龄从小到大对其所占用的内存大小进行累积, 当累积到某个年龄时,对象所占用的内存大小超过了
survivor 区的50%时(默认值是 50%, 可以通过 -XX:TargetSurvivorRatio=percent 来设置),
取这个年龄和 MaxTenuringThreshold 中更小的一个值,作为新的晋升老年代的年龄阈值
注意: 默认晋升到老年代的年龄阈值取决于所使用的垃圾回收器,一般是 15,但是 CMS 是 6。
大对象就是指需要大量连续内存空间的对象(比如:字符串、数组)。
大对象直接进入老年代主要是为了避免为大对象分配内存时由于分配担保机制带来的复制而降低效率。
JVM 将内存分为新生代和老年代,垃圾回收时会根据对象的年龄(经过几次垃圾回收)将其放置于相应的区域。因为大对象往往占用较多内存且生命周期较长,所以将它们直接分配到老年代有助于避免频繁进行内存复制和回收,提高性能。 此外,将大对象直接分配到老年代还可以避免由于新生代空间不足而触发的额外垃圾回收,进一步提高了程序的执行效率。
大对象生命周期较长的原因可能是它们需要存储大量数据,且这些数据在程序执行过程中需要一直存在。例如,一个图片或视频文件在内存中会占据较大的空间,并且通常需要在很长的时间内保持不变。相比之下,一些小型对象可能只是瞬时使用并被很快销毁,因此它们的生命周期较短。
大对象通常是指占用较大内存空间的对象,包括但不限于以下类型:
图像或视频文件:这些文件往往比较大,需要占用较多的内存空间。
大型数据集合:例如大型数组、列表或哈希表等。
长字符串:长度较长的字符串也可能占用较多内存空间。
大型缓存对象:例如在内存中维护的大型缓存等。
总之,大对象的定义可能因程序执行环境和程序本身而异,但其特点通常是占用较大的内存空间,生命周期较长。
针对 HotSpot VM 的实现,它里面的 GC 其实准确分类只有两大种:
部分收集 (Partial GC):
整堆收集 (Full GC): 收集整个 Java 堆和方法区。
空间分配担保是为了确保在 Minor GC 之前老年代本身还有容纳新生代所有对象的剩余空间。
JDK 6 Update 24 之前,在发生 Minor GC 之前,虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间,如果这个条件成立,那这一次 Minor GC 可以确保是安全的。
如果不成立,虚拟机会先查看 -XX:HandlePromotionFailure 参数的设置值是否允许担保失败(Handle Promotion Failure); 如果允许,那会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小,如果大于,将尝试进行一次 Minor GC,尽管这次 Minor GC 是有风险的; 如果小于,或者 -XX: HandlePromotionFailure 设置不允许冒险,那这时就要改为进行一次 Full GC。
JDK 6 Update 24 之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小,就会进行 Minor GC,否则将进行 Full GC。
因为 Survivor 区的对象每进行一次 Minor GC 后,存活的对象年龄会加 1 ,如果某些对象的年龄增长到晋升老年代的年龄阈值,这些对象就会进入到老年代中。假设一种极端的情况,新生代的所有对象都集中在 Survivor 区,并且经过某次 Minor GC 后所有的对象都还存活,并且都达到了晋升老年代的年龄阈值,那么就意味着所有的新生代对象都将进入老年代,所以此时老年代必须还有容纳新生代所有对象的剩余空间,这次 Minor GC 才能安全进行。
堆中几乎存放着所有的对象实例,对堆进行垃圾回收的第一步就是要判断哪些对象已经死亡(即不能再被任何途径使用的对象)。
给对象添加一个引用计数器
这个方法实现简单,效率高,但是目前主流的虚拟机中并没有选择这个算法来管理内存,其最主要的原因是它很难解决对象之间相互循环引用的问题。
所谓对象之间的相互引用问题,如下面代码所示:除了对象 objectA 和 objectB 相互引用着对方之外,这两个对象之间再无任何引用。但是他们因为互相引用对方,导致它们的引用计数器都不为 0,于是引用计数算法无法通知 GC 回收器回收他们。
public class TestA {
Object instance = null;
public static void main(String[] args) {
TestA objectA = new TestA();
TestA objectB = new TestA();
objectA.instance = objectB;
objectB.instance = objectA;
}
解释: 此时,objectA 被 objectB 引用,objectB 被 objectA 引用。如果想要回收 objectA 就要先回收 objectB,让 objectB 释放对 objectA 的引用,但是 objectB 又被 objectA 引用,如果想要回收 objectB 就要先回收 objectA,让 objectA 释放对 objectB 的引用。二者之间相互循环引用,这样程序运行结束垃圾回收器也无法回收这两个对象。
JVM会从一组称为 “GC Roots” 的根对象开始,递归地遍历所有对象的引用链。在这个过程中被发现的对象都被认为是 “可达的”,即仍然被某些代码所引用,因此应该保留在内存中。而未被发现的对象则被认为是 “不可达的”,即没有任何引用指向它们,因此可以被垃圾回收器清理掉。
下图中的 Object5 ~ Object7 之间虽有引用关系,但它们到 GC Roots 不可达,因此为需要被回收的对象。

可作为GC Roots的节点主要在全局性的引用(例如常量或类静态属性)与执行上下文(例如栈帧中的本地变量表)中。
虚拟机栈(栈帧中的本地变量表)中引用的对象:每个线程在运行时都有一个虚拟机栈,其中包含了多个栈帧,每个栈帧代表了一次方法调用。栈帧中的本地变量表可以存储基本类型和对象引用,并且在方法执行过程中会动态变化。只要虚拟机栈中的某个栈帧还在执行,那么该栈帧中的本地变量表中引用的对象就是可达的。
方法区中的类静态属性引用的对象:类的静态属性存放在方法区中,而且它们的生命周期与类的生命周期相同。如果某个类的静态属性引用了某个对象,那么这个对象就是可达的。
方法区中常量引用的对象:在Java程序中,字符串字面值、final修饰的基本数据类型和字符串类型的值都可以被看作是常量。如果某个常量引用了某个对象,那么这个对象就是可达的。
JNI(Java Native Interface)中引用的对象:JNI允许Java代码调用本地语言(如C或C++)编写的函数库,也允许本地语言编写的函数库调用Java代码。如果本地代码中引用了某个Java对象,那么这个对象就是可达的。因此,JVM需要跟踪JNI中的引用关系,以确保被引用的对象不会在垃圾回收时被误删。
当一个对象在可达性分析时被判定为不可达对象时,不会马上被回收,还需要进行两次标记。
第一次标记:判断当前对象是否有 finalize() 方法并且该方法没有被执行过,若不存在则标记为垃圾对象,等待回收;若有的话,并且该方法没有被执行,则进行第二次标记;
第二次标记将当前对象放入 F-Queue 队列,并生成一个 finalize 线程去执行该方法,虚拟机不保证该方法一定会被执行,这是因为如果线程执行缓慢或进入了死锁,会导致回收系统的崩溃;
如果执行了 finalize() 方法之后仍然没有与 GC Roots 有直接或者间接的引用,则该对象会被回收。
不一定,看 Reference 类型,弱引用在 GC (不论内存是否充足) 时会被回收,软引用在内存不足的时候,即 OOM 前会被回收。
以前我们使用的大部分引用实际上都是强引用,这是使用最普遍的引用。如果一个对象具有强引用,那就类似于必不可少的生活用品,垃圾回收器绝不会回收它。当内存空间不足,Java 虚拟机宁愿抛出 OutOfMemoryError 错误,使程序异常终止,也不会靠随意回收具有强引用的对象来解决内存不足问题。
如果一个对象只具有软引用,那就类似于可有可无的生活用品。如果内存空间足够,垃圾回收器就不会回收它,如果内存空间不足了,就会回收这些对象的内存。只要垃圾回收器没有回收它,该对象就可以被程序使用。
软引用可用来实现内存敏感的高速缓存。
软引用可以和一个引用队列(ReferenceQueue)联合使用,如果软引用所引用的对象被垃圾回收,JAVA 虚拟机就会把这个软引用加入到与之关联的引用队列中。
如果一个对象只具有弱引用,那就类似于可有可无的生活用品。
弱引用与软引用的区别在于:只具有弱引用的对象的生命周期更加短暂。在垃圾回收器线程扫描它所管辖的内存区域的过程中,一旦发现了只具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存。
不过,由于垃圾回收器是一个优先级很低的线程, 因此不一定会很快发现那些只具有弱引用的对象。、
弱引用可以和一个引用队列(ReferenceQueue)联合使用,如果弱引用所引用的对象被垃圾回收,Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。
"虚引用"顾名思义,就是形同虚设,与其他几种引用都不同,虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用,那么它就和没有任何引用一样,在任何时候都可能被垃圾回收。
虚引用主要用来跟踪对象被垃圾回收的活动。
虚引用必须和引用队列(ReferenceQueue)联合使用。 当垃圾回收器准备回收一个对象时,如果发现它还有虚引用,就会在回收对象的内存之前,把这个虚引用加入到与之关联的引用队列中。
程序可以通过判断引用队列中是否已经加入了虚引用,来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列,那么就可以在所引用的对象的内存被回收之前采取必要的行动。
特别注意,在程序设计中一般很少使用弱引用与虚引用,使用软引用的情况较多,这是因为软引用可以加速 JVM 对垃圾内存的回收速度,可以维护系统的运行安全,防止内存溢出(OutOfMemory)等问题的产生。
Java中的四种引用类型是:
Object obj = new Object(); // obj 是强引用
SoftReference<Object> softRef = new SoftReference<>(obj); // obj 对象被软引用关联
WeakReference<Object> weakRef = new WeakReference<>(obj); // obj 对象被弱引用关联
ReferenceQueue<Object> queue = new ReferenceQueue<>();
PhantomReference<Object> phantomRef = new PhantomReference<>(obj, queue); // obj 对象被虚引用关联
运行时常量池主要需要回收的是废弃的常量。那么,我们如何判断一个常量是废弃常量呢?
JDK1.7 之前运行时常量池逻辑包含字符串常量池,被存放在方法区, 此时 hotspot 虚拟机对方法区的实现为永久代
JDK1.7 字符串常量池被从方法区拿到了堆中, 这里没有提到运行时常量池,也就是说字符串常量池被单独拿到堆,运行时常量池剩下的东西还在方法区,
也就是 hotspot 中的永久代 。
JDK1.8 hotspot 移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池还在堆, 运行时常量池还在方法区,
只不过方法区的实现从永久代变成了元空间(Metaspace)。
假如在字符串常量池中存在字符串 “abc”,如果当前没有任何 String 对象引用该字符串常量的话,就说明常量 “abc” 就是废弃常量,如果这时发生内存回收的话而且有必要的话,“abc” 就会被系统清理出常量池了。
方法区主要需要回收的是无用的类,那么如何判断一个类是无用的类的呢?
要判定一个类是“无用的类”,类需要同时满足下面 3 个条件才能算是 “无用的类” :
ClassLoader已经被回收。Java.lang.Class对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。HashMap中为什么引入红黑树,而不是AVL树呢1.概述开始学习这个知识点之前我们需要知道,在JDK1.8以及之前,针对HashMap有什么不同。JDK1.7的时候,HashMap的底层实现是数组+链表JDK1.8的时候,HashMap的底层实现是数组+链表+红黑树我们要思考一个问题,为什么要从链表转为红黑树呢。首先先让我们了解下链表有什么不好???2.链表上述的截图其实就是链表的结构,我们来看下链表的增删改查的时间复杂度增:因为链表不是线性结构,所以每次添加的时候,只需要移动一个节点,所以可以理解为复杂度是N(1)删:算法时间复杂度跟增保持一致查:既然是非线性结构,所以查询某一个节点的时候
SPI接收数据左移一位问题目录SPI接收数据左移一位问题一、问题描述二、问题分析三、探究原理四、经验总结最近在工作在学习调试SPI的过程中遇到一个问题——接收数据整体向左移了一位(1bit)。SPI数据收发是数据交换,因此接收数据时从第二个字节开始才是有效数据,也就是数据整体向右移一个字节(1byte)。请教前辈之后也没有得到解决,通过在网上查阅前人经验终于解决问题,所以写一个避坑经验总结。实际背景:MCU与一款芯片使用spi通信,MCU作为主机,芯片作为从机。这款芯片采用的是它规定的六线SPI,多了两根线:RDY和INT,这样从机就可以主动请求主机给主机发送数据了。一、问题描述根据从机芯片手
西安华为OD面试体验开始投简历技术面试进展工作进展开始投简历去年一整年一直在考研和工作之间纠结,感觉自己的状态好像当时的疫情一样差劲。之前刚毕业的时候投了个大厂的简历,结果一面写算法的时候太拉跨了,虽然知道时dfs但是代码熟练度不够,放在平时给足时间自己可以调试通过,但是熟练度不够那面试当时就写不出来被刷了。说真的算法学到后期我感觉最重要的是熟练度和背板子(对于我这种普通玩家来说),面试题如果一上来短时间内想不出思路就完蛋了。然后由于当时找的工作不是很理想就又想考研了。但是考研是有风险的,我自我感觉自己可能冲不上那个学校,而找工作一个没成可以继续找嘛。本着抱着试试看的态度在boss上投了简历,
文章目录一、项目场景二、基本模块原理与调试方法分析——信源部分:三、信号处理部分和显示部分:四、基本的通信链路搭建:四、特殊模块:interpretedMATLABfunction:五、总结和坑点提醒一、项目场景 最近一个任务是使用simulink搭建一个MIMO串扰消除的链路,并用实际收到的数据进行测试,在搭建的过程中也遇到了不少的问题(当然这比vivado里面的debug好不知道多少倍)。准备趁着这个机会,先以一个很基本的通信链路对simulink基础和相关的debug方法进行总结。 在本篇中,主要记录simulink的基本原理和基本的SISO通信传输链路(QPSK方式),计划在下篇记
使用facebook登录后,我被重定向到/#_=_,其中显示主页。这种垃圾也出现在其他URL中,例如当注册失败并被重定向到/users/sign_in#_=_为什么会发生这种情况,我该如何解决? 最佳答案 如果你真的不想要它,一些简单的javascript就可以了:if(window.location.hash=="#_=_"){window.location.hash="";} 关于ruby-on-rails-为什么Devise/Omniauth会向URL添加垃圾?,我们在StackO
我有UTF-8字符串:Website•Facebook那是中间的一颗子弹又名•或0xE20x800xA2此值已正确存储在数据库中,并使用默认设置使用Rails3和ruby1.9.3正确显示在屏幕上。我正在尝试通过HTML电子邮件发送此邮件,但是当一切都说完之后,接收端看到的是垃圾:这背后的代码很简单,我有一个ActionMailer子类(默认使用UTF-8)设置以在布局中发送带有UTF-8内容编码的HTML电子邮件:email.html.erb布局文件:"all"%>内容使用与呈现网页相同的View,重要的一行是:我已经尝试了很多很多force_encoding的排列,e
所以从Ruby2.2+版本开始引入了符号垃圾回收。我在irb中编写了以下代码片段:before=Symbol.all_symbols.size#=>3331100_000.timesdo|i|"sym#{i}".to_symendSymbol.all_symbols.size#=>18835GC.startSymbol.all_symbols.size#=>3331因此,正如预期的那样,它收集了使用to_sym动态生成的所有符号。那么GC是如何知道收集哪些符号的呢?即使它们在程序中被引用,它会收集符号吗?符号垃圾回收是如何工作的?如果我创建的其中一个符号在程序中被引用,它还会收集它吗?
点击->操作系统复习的文章集目录操作系统线程线程是什么进程与线程的关系用户态/内核态操作系统资源管理内核态用户态内核态/用户态切换程序运行类型分析计算密集型IO密集型结合进程,线程来理解程序运行类型分析协程基础上下文切换协程协程为什么叫协作式线程?协程的优缺点操作系统线程典型问题:简述进程和线程的区别以下内容带您一步步了解线程是什么比进程更小的独立运行的基本单位-线程(Threads)线程的提出主要是为了提高系统内程序并发执行的程度,从而进一步提升系统的吞吐量,充分发挥多核CPU的优越性而设计的引入进程是为了操作系统更加方便地管理程序,使得多个程序能并发管理和执行而线程则是为了减少程序在并发执
如果我使用类似的方法defself.get_service_clientreturn@service_clientif!@service_client.nil?@service_client=#initializelogicend现在@service_client是一个类的实例变量。它在内存中有多长时间?只要类在内存中(即像静态变量一样),我可以指望它不会被重新初始化吗? 最佳答案 类也是Ruby中的实例,但是当您以通常的方式定义类时,它会被分配给一个常量,并且该常量会被其他常量引用,从而阻止其被收集。因此,该类将无限期地存储在内存
【动态规划】一、背包问题1.背包问题总结1)动规四部曲:2)递推公式总结:3)遍历顺序总结:2.01背包1)二维dp数组代码实现2)一维dp数组代码实现3.完全背包代码实现4.多重背包代码实现一、背包问题1.背包问题总结暴力的解法是指数级别的时间复杂度。进而才需要动态规划的解法来进行优化!背包问题是动态规划(DynamicPlanning)里的非常重要的一部分,关于几种常见的背包,其关系如下:在解决背包问题的时候,我们通常都是按照如下五部来逐步分析,把这五部都搞透了,算是对动规来理解深入了。1)动规四部曲:(1)确定dp数组及其下标的含义(2)确定递推公式(3)dp数组的初始化(4)确定遍历顺