JVM 内存结构
- 线程私有
- 程序计数器 【记录当前线程执行到代码的位置】
- 虚拟机栈 【java 方法内的局部变量，方法参数；区别于本地方法，本地方法用的是本地方法栈】
- 线程共享
- 堆 【存储对象的信息】
- 方法区 【存储类的信息】
- 解释器：将 java 字节码翻译成适用于各个平台的机器码，以便于 CPU 执行 【当遇到相同代码时，会重复解释，效率不是很高】
- 即时编译器：负责发现热点代码，并把热点代码翻译成机器码缓存起来，下一次再遇到这种代码时，解释器就不会再去解释了，直接从即时编译器中缓存的机器码中取出 【可以提高效率】
哪些部分会出现内存溢出
- 不会出现内存溢出的区域 - 程序计数器
- 出现 OutOfMemoryError 的情况
- 堆内存耗尽 – 对象越来越多，又一直在使用，不能被垃圾回收
- 方法区内存耗尽 – 加载的类越来越多，很多框架都会在运行期间动态产生新的类
- 虚拟机栈累计 – 每个线程最多会占用 1M 内存，线程个数越来越多，而又长时间运行不销毁时
- 出现 StackOverflowEroor 的区域
- 虚拟机栈内部 – 方法调用次数过多
- 内存泄露：当某些对象不再被应用程序所使用，但是由于仍然被引用而导致垃圾收集器不能回收
方法区与永久代，元空间之间的关系
- 方法区是 JVM 规范中定义的的一块内存区域，用来存储元数据，方法字节码，即时编译器需要的信息等 (仅仅是个定义)
- 永久代是 HotSpot 虚拟机对JVM 规范的实现 (1.8 之前) (方法区的实现)
- 元空间时 HotSpot 虚拟机对JVM 规范的实现 (1.8 以后)，使用本地内存作为这些信息的存储空间 (方法区的实现)
JVM 内存参数
对于 JVM 内存配置参数：-Xmx10240m，-Xms10240m，-Xmn5120m，-XX:SurivorRatio=3，其最小内存值和Survivor去总大小分别是
- -Xmx：最大内存数
- -Xms：最小内存数
- -Xmn：虚拟机中新生代的内存数
- -XX:SurivorRatio：新生代伊甸园区与幸存区中的from区的比例，默认是8:1
- -XX:NewRatio=2:1 -> 新生代：老年代 = 1:2
- -Xss：控制每个线程占用内存的大小
JVM 垃圾回收算法
- 标记清除 (几乎已经被淘汰掉了)
-
GC Root：根对象，简单来说就是那些一定不能被清除的对象，比如正在使用的对象
-
加了标记的对象保存下来，没有加标记的对象就清除
-
虽然释放了很多内存，但是造成了内存碎片的问题，这些内存碎片的利用率不高
-
标记整理 (常用于老年代的垃圾回收)
-
清除掉垃圾之后，会对内存进行一次整理，解决了内存碎片的问题
-
随之而来的问题是效率会降低
-
标记复制 (常用于新生代的垃圾回收，但是不适用于老年代的垃圾回收，因为老年代存活的对象较多，复制的工作量大)
- 将标记出来的对象移动到空闲区
- 效率比标记整理法更高，但是更耗内存
说说 GC 和 分代回收算法
- GC 的目的在于实现无用对象内存自动释放，减少内存碎片，加快分配速度
- GC 要点
- 回收区域是堆内存，不包括虚拟机栈，在方法调用结束会自动释放方法占用的内存
- 判断无用对象，使用可达性分析算法，三色标记法标记存活对象，回收未标记对象
- GC 具体的实现为垃圾回收器
- GC 大都采用了分代回收思想，理论依据是大部分对象朝生夕灭，用完立刻就可以回收，另有少部分对象会长时间存活，每次很难回收，根据这两类对象的特性将回收区域分为新生代和老年代，不同区域应用不同的回收策略
- 根据 GC 的规模可以分成Minor GC，Mixed GC，Full GC
分代回收与 GC 规模
- 分代回收
- 伊甸园 eden，最初对象都分配在这里，与幸存者区称为新生代
- 幸存者 survivor，当伊甸园内存不足，回收后的幸存对象到这里，分成 from 和 to，采用标记复制算法 (from 和 to 会交换位置，谁空谁是 to)
- 老年代 old，当幸存者区对象熬过几次回收 (最多15次)，晋升到老年代 (幸存区内存不足或大对象会导致提前晋升)
- GC 规模
- Minor GC：发生在新生代的垃圾回收，暂停时间短
- Mixed GC：新生代 + 老年代部分区域的垃圾回收，G1 收集器特有
- Full GC：新生代 + 老年代完整垃圾回收，暂停时间长，应尽力避免
三色标记与并发漏标问题
- 用三种颜色记录对象的标记状态
- 黑色 – 已标记
- 灰色 – 标记中
- 白色 – 还未标记
- 漏标问题 – 记录标记过程中的变化
- Incremental Update (增量更新)
- 只要赋值发生变化，被复制的对象就会被记录
- Snapshot At The Begining，SATB (原始快照)
- 新加对象会被记录
- 被删除引用关系的对象也会被记录
- Incremental Update (增量更新)
垃圾回收器
- Parallel GC
- eden 内存不足发生 Minor GC，标记复制 STW
- old 内存不足发生 Full GC，标记整理 STW
- 注重吞吐量
- ConcurrentMarkSweep GC
- old 并发标记，重新标记时需要 STW，并发清除 (意味着有内存碎片)
- Failback Full GC
- 注重响应时间
- G1 GC (从 JDK9 开始，作为默认的垃圾回收器)
- 响应时间和吞吐量兼顾
- 划分成多个区域，每个区域都可以充当 eden，survivor，old，humongous (humongous主要用于存储大对象的，因为G1主要是标记复制算法，大对象的复制比较耗时间)
- 新生代回收：eden 内存不足，标记复制 STW
- 并发标记：old 并发标记，重新标记时需要 STW
- 混合收集：并发标记完成，开始混合收集，参与复制的有 eden，survivor，old，其中 old 会根据暂停时间目标，选择部分回收价值高的区域，复制时 STW
- Failback Full GC
项目中什么情况会内存溢出，怎么解决的
- 误用线程池导致的内存溢出 (比如等待队列中任务数过多，或者线程数过多)
- 查询数据量太大导致的内存溢出
- 动态生成类导致的内存溢出
类加载过程，双亲委派
-
类加载过程分为三个阶段
1 加载
- 将类的字节码载入方法区，并创建类.class 对象
- 如果此类的父类没有加载，先加载父类
- 加载是懒惰执行 (用到类的时候，才会加载)
2 链接
- 验证 – 验证类是否符合 Class 规范，合法性，安全性检查
- 准备 – 为 static 变量分配空间，设置默认值
- 解析 – 将常量池的符号引用解析为直接引用
3 初始化
- 执行静态代码块与非 final 静态变量的赋值 (final 修饰的非引用型静态变量在编译阶段就已经确定好值了，在准备阶段赋值)
- 初始化是懒惰执行
1. 访问 final static 修饰的基本类型变量，不会触发类的加载
2. 访问 final static 修饰的引用类型变量，会触发类的加载
-
何为双亲委派模式
- 所谓的双亲委派，就是指优先委派上级类加载器进行加载，如果上级类加载器
- 能找到这个类，由上级加载，加载后该类也对下级加载器可见
- 找不到这个类，则下级类加载器才有资格执行加载 (下级对上级是不可见的)
- 所谓的双亲委派，就是指优先委派上级类加载器进行加载，如果上级类加载器
- 双亲委派的目的有两点
- 让上级类加载器中的类对下级共享 (反之不行)，即能让你的类能依赖到 JDK 提供的核心类
- 让类的加载有优先次序，保证核心类优先加载
对象引用类型分为哪几类？
- 强引用
- 普通变量赋值即为强引用，如 A a = new A();
- 通过 GC Root 的引用链，如果强引用不到该对象，该对象才能被回收
- 软引用
- 例如：SoftReference a = new SoftReference(new A);
- 如果仅有软引用该对象时，首次垃圾回收不会回收该对象，如果内存仍然不足，再次回收时才会释放
- 软引用自身需要配合引用队列来释放
- 典型例子是反射数据
- 弱引用
- 例如：WearReference a = new WeakReference(new A());
- 如果仅有弱引用该对象时，只要发生垃圾回收，就会释放对象
- 弱引用自身需要配合引用队列来释放
- 典型例子是 ThreadLocalMap 中的 Entry 对象
- 虚引用
- 例如：PhantomReference a = new PhantomReference(new A())；
- 必须配合引用队列一起使用，当虚引用引用的对象被回收时，会将虚引用对象入队，由 Reference Handler 线程释放其关联的外部资源
- 典型例子是 Cleaner 释放 DirectByteBuffer 占用的直接内存
1752
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
