1. JVM与Java体系结构
2. JVM-类加载子系统
3. JVM-运行时数据区概述及线程
4. JVM-程序计数器(PC寄存器)
5. JVM-虚拟机栈
6. JVM-本地方法接口
7. JVM-本地方法栈
8. JVM-堆
9. JVM-方法区
10.JVM-StringTable/StringPool
11.JVM-垃圾回收概述
12.JVM-垃圾回收相关算法
13.JVM-垃圾回收相关概念
14.JVM-垃圾回收器
内存分配的时候可能就在回收。垃圾回收之前怎么样的,现在怎么样的,未来怎么样的,几乎每个大版本都有GC的更新。
Java当时想达到跟C++一样的性能,而C++想跟Java一样不用显式分配内存以及回收,互相羡慕,就成了围墙。
垃圾收集,不是Java语言的伴生产物。早在1960年,第一门开始使用内存动态分配和垃圾收集技术的Lisp语言诞生。
关于垃圾收集有三个经典问题:
垃圾收集机制是Java的招牌能力,极大地提高了开发效率。如今,垃圾收集几乎成为现代语言的标配,即使经过如此长时间的发展,Java的垃圾收集机制仍然在不断的演进中,不同大小的设备、不同特征的应用场景,对垃圾收集提出了新的挑战,这当然也是面试的热点。
什么是垃圾(Garbage)?
如果不及时对内存中的垃圾进行清理,那么,这些垃圾对象所占的内存空间会一直保留到应用程序的结束,被保留的空间无法被其它对象使用,甚至可能导致内存溢出。
磁盘碎片整理
磁盘碎片整理的日子,磁盘整理的时候不要操作其他操作。
蚂蚁金服
百度
天猫
滴滴
京东
阿里
字节跳动
对于高级语言来说,一个基本认知是如果不进行垃圾回收,内存迟早都会被消耗完,因为不断地分配内存空间而不进行回收,就好像不停地生产生活垃圾而从来不打扫一样。
除了释放没用的对象,垃圾回收也可以清除内存里的记录碎片。碎片整理将所占用的堆内存移到堆的一端,以便JVM将整理出的内存分配给新的对象。
随着应用程序所应付的业务越来越庞大、复杂,用户越来越多,没有GC就不能保证应用程序的正常进行。而经常造成STW的GC又跟不上实际的需求,所以才会不断地尝试对GC进行优化。
在早期的C/C++时代,垃圾回收基本上是手工进行的。开发人员可以使用new关键字进行内存申请,并使用delete关键字进行内存释放。比如以下代码:
MibBridge *pBridge = new cmBaseGroupBridge();
// 如果注册失败,使用Delete释放该对象所占内存区域
if (pBridge->Register(kDestroy)!= NO_ERROR)
delete pBridge;
这种方式可以灵活控制内存释放的时间,但是会给开发人员带来频繁申请和释放内存的管理负担。倘若有一处内存区间由于程序员编码的问题忘记被回收,那么就会产生内存泄漏,垃圾对象永远无法被清除,随着系统运行时间的不断增长,垃圾对象所耗内存可能持续上升,直到出现内存溢出并造成应用程序崩溃。(内存泄露会导致内存溢出)
有了垃圾回收机制后,上述代码极有可能变成这样
MibBridge *pBridge = new cmBaseGroupBridge();
pBridge->Register(kDestroy);
现在,除了Java以外,C#、Python、Ruby等语言都使用了自动垃圾回收的思想,也是未来发展趋势,可以说这种自动化的内存分配和来及回收方式已经成为了线代开发语言必备的标准。(比喻:垃圾回收有点像保姆。)
自动内存管理,无需开发人员手动参与内存的分配与回收,这样降低内存泄漏和内存溢出的风险。
没有垃圾回收器,java也会和cpp一样,各种悬垂指针,野指针,泄露问题让你头疼不已。
自动内存管理机制,将程序员从繁重的内存管理中释放出来,可以更专心地专注于业务开发。
oracle官网关于垃圾回收的介绍
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html
对于Java开发人员而言,自动内存管理就像是一个黑匣子,如果过度依赖于“自动”,那么这将会是一场灾难,最严重的就会弱化Java开发人员在程序出现内存溢出时定位问题和解决问题的能力。
此时,了解JVM的自动内存分配和内存回收原理就显得非常重要,只有在真正了解JVM是如何管理内存后,我们才能够在遇见OutOfMemoryError时,快速地根据错误异常日志定位问题和解决问题。
当需要排查各种内存溢出、内存泄漏问题时,当垃圾收集成为系统达到更高并发量的瓶颈时,我们就必须对这些“自动化”的技术实施必要的监控和调节。
垃圾收集器可以对年轻代回收,也可以对老年代回收,甚至是全栈和方法区的回收。
从次数上讲: