structure changed
This commit is contained in:
@@ -10,7 +10,7 @@ export default defineUserConfig({
|
|||||||
description: "vuepress-theme-hope 的文档演示",
|
description: "vuepress-theme-hope 的文档演示",
|
||||||
|
|
||||||
theme,
|
theme,
|
||||||
|
|
||||||
// 和 PWA 一起启用
|
// 和 PWA 一起启用
|
||||||
// shouldPrefetch: false,
|
// shouldPrefetch: false,
|
||||||
});
|
});
|
||||||
|
|||||||
@@ -6,10 +6,10 @@ export default navbar([
|
|||||||
"/demo/",
|
"/demo/",
|
||||||
{
|
{
|
||||||
text: "面试",
|
text: "面试",
|
||||||
link: "/interview/x-interview.md",
|
link: "/interview/",
|
||||||
icon: "lightbulb",
|
icon: "lightbulb",
|
||||||
// 仅在 `/interview/` 激活
|
// 仅在 `/interview/` 激活
|
||||||
activeMatch: "^/interview/$",
|
// activeMatch: "^/interview/$",
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
text: "指南",
|
text: "指南",
|
||||||
|
|||||||
@@ -17,10 +17,17 @@ export default sidebar({
|
|||||||
prefix: "guide/",
|
prefix: "guide/",
|
||||||
children: "structure",
|
children: "structure",
|
||||||
},
|
},
|
||||||
|
{
|
||||||
|
text: "面试",
|
||||||
|
icon: "lightbulb",
|
||||||
|
prefix: "interview/",
|
||||||
|
children: ["java/"],
|
||||||
|
},
|
||||||
{
|
{
|
||||||
text: "幻灯片",
|
text: "幻灯片",
|
||||||
icon: "person-chalkboard",
|
icon: "person-chalkboard",
|
||||||
link: "https://ecosystem.vuejs.press/zh/plugins/markdown/revealjs/demo.html",
|
link: "https://ecosystem.vuejs.press/zh/plugins/markdown/revealjs/demo.html",
|
||||||
},
|
},
|
||||||
],
|
],
|
||||||
|
"/interview/": "structure",
|
||||||
});
|
});
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: 主要功能与配置演示
|
title: 主要功能与配置演示
|
||||||
index: false
|
index: true
|
||||||
icon: laptop-code
|
icon: laptop-code
|
||||||
category:
|
category:
|
||||||
- 使用指南
|
- 使用指南
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: 面试
|
title: 面试
|
||||||
index: false
|
icon: lightbulb
|
||||||
icon: laptop-code
|
|
||||||
sidebar: false
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
<Catalog/>
|
||||||
@@ -1,11 +1,17 @@
|
|||||||
---
|
---
|
||||||
|
# dir:
|
||||||
|
# text: Java全栈面试
|
||||||
|
# icon: laptop-code
|
||||||
|
# collapsible: true
|
||||||
|
# expanded: true
|
||||||
|
# link: true
|
||||||
|
# index: true
|
||||||
title: Java全栈面试
|
title: Java全栈面试
|
||||||
index: false
|
index: true
|
||||||
icon: laptop-code
|
# icon: laptop-code
|
||||||
sidebar: false
|
# sidebar: true
|
||||||
toc: true
|
# toc: true
|
||||||
editLink: false
|
# editLink: false
|
||||||
headerDepth: 5
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 1 Java基础
|
## 1 Java基础
|
||||||
@@ -4543,3 +4549,266 @@ private static int add(int a, int b) {
|
|||||||
- **本地方法栈(Native Method Stack)**
|
- **本地方法栈(Native Method Stack)**
|
||||||
|
|
||||||
Java 虚拟机栈用于管理 Java 方法的调用,而本地方法栈用于管理本地方法的调用
|
Java 虚拟机栈用于管理 Java 方法的调用,而本地方法栈用于管理本地方法的调用
|
||||||
|
|
||||||
|
#### 什么是方法区(线程共享)?
|
||||||
|
|
||||||
|
方法区(method area)只是 **JVM 规范**中定义的一个概念,用于存储类信息、常量池、静态变量、JIT编译后的代码等数据,并没有规定如何去实现它,不同的厂商有不同的实现。而**永久代(PermGen)\**是 \*\*Hotspot\*\* 虚拟机特有的概念, Java8 的时候又被\**元空间**取代了,永久代和元空间都可以理解为方法区的落地实现。
|
||||||
|
|
||||||
|
JDK1.8之前调节方法区大小:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
-XX:PermSize=N //方法区(永久代)初始大小
|
||||||
|
-XX:MaxPermSize=N //方法区(永久代)最大大小,超出这个值将会抛出OutOfMemoryError
|
||||||
|
```
|
||||||
|
|
||||||
|
JDK1.8开始方法区(HotSpot的永久代)被彻底删除了,取而代之的是元空间,元空间直接使用的是本机内存。参数设置:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
-XX:MetaspaceSize=N //设置Metaspace的初始(和最小大小)
|
||||||
|
-XX:MaxMetaspaceSize=N //设置Metaspace的最大大小
|
||||||
|
```
|
||||||
|
|
||||||
|
**栈、堆、方法区的交互关系**
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 永久代和元空间内存使用上的差异?
|
||||||
|
|
||||||
|
Java虚拟机规范中只定义了方法区用于存储已被虚拟机加载的类信息、常量、静态变量和即时编译后的代码等数据
|
||||||
|
|
||||||
|
1. jdk1.7开始符号引用存储在native heap中,字符串常量和静态类型变量存储在普通的堆区中,但分离的并不彻底,此时永久代中还保存另一些与类的元数据无关的杂项
|
||||||
|
2. jdk8后HotSpot 原永久代中存储的类的**元数据将存储在metaspace**中,而**类的静态变量和字符串常量将放在Java堆中**,metaspace是方法区的一种实现,只不过它使用的不是虚拟机内的内存,而是本地内存。在元空间中保存的数据比永久代中纯粹很多,就只是类的元数据,这些信息只对编译期或JVM的运行时有用。
|
||||||
|
3. 永久代有一个JVM本身设置固定大小上线,无法进行调整,而**元空间使用的是直接内存,受本机可用内存的限制,并且永远不会得到java.lang.OutOfMemoryError**。
|
||||||
|
4. **符号引用没有存在元空间中,而是存在native heap中**,这是两个方式和位置,不过都可以算作是本地内存,在虚拟机之外进行划分,没有设置限制参数时只受物理内存大小限制,即只有占满了操作系统可用内存后才OOM。
|
||||||
|
|
||||||
|
#### 堆区内存是怎么细分的?
|
||||||
|
|
||||||
|
对于大多数应用,Java 堆是 Java 虚拟机管理的内存中最大的一块,被所有线程共享。此内存区域的唯一目的就是存放对象实例,几乎所有的对象实例以及数据都在这里分配内存。
|
||||||
|
|
||||||
|
为了进行高效的垃圾回收,虚拟机把堆内存**逻辑上**划分成三块区域(分代的唯一理由就是优化 GC 性能):
|
||||||
|
|
||||||
|
1. 新生带(年轻代):新对象和没达到一定年龄的对象都在新生代
|
||||||
|
2. 老年代(养老区):被长时间使用的对象,老年代的内存空间应该要比年轻代更大
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Java 虚拟机规范规定,Java 堆可以是处于物理上不连续的内存空间中,只要逻辑上是连续的即可,像磁盘空间一样。实现时,既可以是固定大小,也可以是可扩展的,主流虚拟机都是可扩展的(通过 `-Xmx` 和 `-Xms` 控制),如果堆中没有完成实例分配,并且堆无法再扩展时,就会抛出 `OutOfMemoryError` 异常。
|
||||||
|
|
||||||
|
- **年轻代 (Young Generation)**
|
||||||
|
|
||||||
|
年轻代是所有新对象创建的地方。当填充年轻代时,执行垃圾收集。这种垃圾收集称为 **Minor GC**。年轻一代被分为三个部分——伊甸园(**Eden Memory**)和两个幸存区(**Survivor Memory**,被称为from/to或s0/s1),默认比例是`8:1:1`
|
||||||
|
|
||||||
|
1. 大多数新创建的对象都位于 Eden 内存空间中
|
||||||
|
2. 当 Eden 空间被对象填充时,执行**Minor GC**,并将所有幸存者对象移动到一个幸存者空间中
|
||||||
|
3. Minor GC 检查幸存者对象,并将它们移动到另一个幸存者空间。所以每次,一个幸存者空间总是空的
|
||||||
|
4. 经过多次 GC 循环后存活下来的对象被移动到老年代。通常,这是通过设置年轻一代对象的年龄阈值来实现的,然后他们才有资格提升到老一代
|
||||||
|
|
||||||
|
- **老年代(Old Generation)**
|
||||||
|
|
||||||
|
旧的一代内存包含那些经过许多轮小型 GC 后仍然存活的对象。通常,垃圾收集是在老年代内存满时执行的。老年代垃圾收集称为 主GC(Major GC),通常需要更长的时间。
|
||||||
|
|
||||||
|
大对象直接进入老年代(大对象是指需要大量连续内存空间的对象)。这样做的目的是避免在 Eden 区和两个Survivor 区之间发生大量的内存拷贝
|
||||||
|
|
||||||
|
#### JVM中对象在堆中的生命周期?
|
||||||
|
|
||||||
|
1. 在 JVM 内存模型的堆中,堆被划分为新生代和老年代
|
||||||
|
- 新生代又被进一步划分为 **Eden区** 和 **Survivor区**,Survivor 区由 **From Survivor** 和 **To Survivor** 组成
|
||||||
|
2. 当创建一个对象时,对象会被优先分配到新生代的 Eden 区
|
||||||
|
- 此时 JVM 会给对象定义一个**对象年轻计数器**(`-XX:MaxTenuringThreshold`)
|
||||||
|
3. 当 Eden 空间不足时,JVM 将执行新生代的垃圾回收(Minor GC)
|
||||||
|
- JVM 会把存活的对象转移到 Survivor 中,并且对象年龄 +1
|
||||||
|
- 对象在 Survivor 中同样也会经历 Minor GC,每经历一次 Minor GC,对象年龄都会+1
|
||||||
|
4. 如果分配的对象超过了`-XX:PetenureSizeThreshold`,对象会**直接被分配到老年代**
|
||||||
|
|
||||||
|
#### JVM中对象的分配过程?
|
||||||
|
|
||||||
|
为对象分配内存是一件非常严谨和复杂的任务,JVM 的设计者们不仅需要考虑内存如何分配、在哪里分配等问题,并且由于内存分配算法和内存回收算法密切相关,所以还需要考虑 GC 执行完内存回收后是否会在内存空间中产生内存碎片。
|
||||||
|
|
||||||
|
1. new 的对象先放在伊甸园区,此区有大小限制
|
||||||
|
2. 当伊甸园的空间填满时,程序又需要创建对象,JVM 的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC),将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区
|
||||||
|
3. 然后将伊甸园中的剩余对象移动到幸存者 0 区
|
||||||
|
4. 如果再次触发垃圾回收,此时上次幸存下来的放到幸存者 0 区,如果没有回收,就会放到幸存者 1 区
|
||||||
|
5. 如果再次经历垃圾回收,此时会重新放回幸存者 0 区,接着再去幸存者 1 区
|
||||||
|
6. 什么时候才会去养老区呢? 默认是 15 次回收标记
|
||||||
|
7. 在养老区,相对悠闲。当养老区内存不足时,再次触发 Major GC,进行养老区的内存清理
|
||||||
|
8. 若养老区执行了 Major GC 之后发现依然无法进行对象的保存,就会产生 OOM 异常
|
||||||
|
|
||||||
|
#### 什么是 TLAB (Thread Local Allocation Buffer)?
|
||||||
|
|
||||||
|
- 从内存模型而不是垃圾回收的角度,对 Eden 区域继续进行划分,JVM 为每个线程分配了一个私有缓存区域,它包含在 Eden 空间内
|
||||||
|
- 多线程同时分配内存时,使用 TLAB 可以避免一系列的非线程安全问题,同时还能提升内存分配的吞吐量,因此我们可以将这种内存分配方式称为**快速分配策略**
|
||||||
|
- OpenJDK 衍生出来的 JVM 大都提供了 TLAB 设计
|
||||||
|
|
||||||
|
#### 为什么要有 TLAB ?
|
||||||
|
|
||||||
|
- 堆区是线程共享的,任何线程都可以访问到堆区中的共享数据
|
||||||
|
- 由于对象实例的创建在 JVM 中非常频繁,因此在并发环境下从堆区中划分内存空间是线程不安全的
|
||||||
|
- 为避免多个线程操作同一地址,需要使用加锁等机制,进而影响分配速度
|
||||||
|
|
||||||
|
尽管不是所有的对象实例都能够在 TLAB 中成功分配内存,但 JVM 确实是将 TLAB 作为内存分配的首选。
|
||||||
|
|
||||||
|
在程序中,可以通过 `-XX:UseTLAB` 设置是否开启 TLAB 空间。
|
||||||
|
|
||||||
|
默认情况下,TLAB 空间的内存非常小,仅占有整个 Eden 空间的 1%,我们可以通过 `-XX:TLABWasteTargetPercent` 设置 TLAB 空间所占用 Eden 空间的百分比大小。
|
||||||
|
|
||||||
|
一旦对象在 TLAB 空间分配内存失败时,JVM 就会尝试着通过使用加锁机制确保数据操作的原子性,从而直接在 Eden 空间中分配内存。
|
||||||
|
|
||||||
|
### 5.3 GC垃圾回收
|
||||||
|
|
||||||
|
#### 如何判断一个对象是否可以回收?
|
||||||
|
|
||||||
|
- **引用计数算法**
|
||||||
|
|
||||||
|
给对象添加一个引用计数器,当对象增加一个引用时计数器加 1,引用失效时计数器减 1。引用计数为 0 的对象可被回收。
|
||||||
|
|
||||||
|
两个对象出现循环引用的情况下,此时引用计数器永远不为 0,导致无法对它们进行回收。
|
||||||
|
|
||||||
|
正因为循环引用的存在,因此 Java 虚拟机不使用引用计数算法。
|
||||||
|
|
||||||
|
- **可达性分析算法**
|
||||||
|
|
||||||
|
通过 GC Roots 作为起始点进行搜索,能够到达到的对象都是存活的,不可达的对象可被回收。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Java 虚拟机使用该算法来判断对象是否可被回收,在 Java 中 GC Roots 一般包含以下内容:
|
||||||
|
|
||||||
|
- 虚拟机栈中引用的对象
|
||||||
|
- 本地方法栈中引用的对象
|
||||||
|
- 方法区中类静态属性引用的对象
|
||||||
|
- 方法区中的常量引用的对象
|
||||||
|
|
||||||
|
#### 对象有哪些引用类型?
|
||||||
|
|
||||||
|
无论是通过引用计算算法判断对象的引用数量,还是通过可达性分析算法判断对象是否可达,判定对象是否可被回收都与引用有关。
|
||||||
|
|
||||||
|
Java 具有四种强度不同的引用类型。
|
||||||
|
|
||||||
|
- **强引用**
|
||||||
|
|
||||||
|
被强引用关联的对象不会被回收。
|
||||||
|
|
||||||
|
使用 new 一个新对象的方式来创建强引用。
|
||||||
|
|
||||||
|
```java
|
||||||
|
Object obj = new Object();
|
||||||
|
```
|
||||||
|
|
||||||
|
- **软引用**
|
||||||
|
|
||||||
|
被软引用关联的对象只有在内存不够的情况下才会被回收。
|
||||||
|
|
||||||
|
使用 SoftReference 类来创建软引用。
|
||||||
|
|
||||||
|
```java
|
||||||
|
Object obj = new Object();
|
||||||
|
SoftReference<Object> sf = new SoftReference<Object>(obj);
|
||||||
|
obj = null; // 使对象只被软引用关联
|
||||||
|
```
|
||||||
|
|
||||||
|
- **弱引用**
|
||||||
|
|
||||||
|
被弱引用关联的对象一定会被回收,也就是说它只能存活到下一次垃圾回收发生之前。
|
||||||
|
|
||||||
|
使用 WeakReference 类来实现弱引用。
|
||||||
|
|
||||||
|
```java
|
||||||
|
Object obj = new Object();
|
||||||
|
WeakReference<Object> wf = new WeakReference<Object>(obj);
|
||||||
|
obj = null;
|
||||||
|
```
|
||||||
|
|
||||||
|
- **虚引用**
|
||||||
|
|
||||||
|
又称为幽灵引用或者幻影引用。一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用取得一个对象。
|
||||||
|
|
||||||
|
为一个对象设置虚引用关联的唯一目的就是能在这个对象被回收时收到一个系统通知。
|
||||||
|
|
||||||
|
使用 PhantomReference 来实现虚引用。
|
||||||
|
|
||||||
|
```java
|
||||||
|
Object obj = new Object();
|
||||||
|
PhantomReference<Object> pf = new PhantomReference<Object>(obj);
|
||||||
|
obj = null;
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 有哪些基本的垃圾回收算法?
|
||||||
|
|
||||||
|
- **标记 - 清除**
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
将存活的对象进行标记,然后清理掉未被标记的对象。
|
||||||
|
|
||||||
|
不足:
|
||||||
|
|
||||||
|
- 标记和清除过程效率都不高;
|
||||||
|
- 会产生大量不连续的内存碎片,导致无法给大对象分配内存。
|
||||||
|
|
||||||
|
- **标记 - 整理**
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存。
|
||||||
|
|
||||||
|
- **复制**
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
将内存划分为大小相等的两块,每次只使用其中一块,当这一块内存用完了就将还存活的对象复制到另一块上面,然后再把使用过的内存空间进行一次清理。
|
||||||
|
|
||||||
|
主要不足是只使用了内存的一半。
|
||||||
|
|
||||||
|
现在的商业虚拟机都采用这种收集算法来回收新生代,但是并不是将新生代划分为大小相等的两块,而是分为一块较大的 Eden 空间和两块较小的 Survivor 空间,每次使用 Eden 空间和其中一块 Survivor。在回收时,将 Eden 和 Survivor 中还存活着的对象一次性复制到另一块 Survivor 空间上,最后清理 Eden 和使用过的那一块 Survivor。
|
||||||
|
|
||||||
|
HotSpot 虚拟机的 Eden 和 Survivor 的大小比例默认为 8:1,保证了内存的利用率达到 90%。如果每次回收有多于 10% 的对象存活,那么一块 Survivor 空间就不够用了,此时需要依赖于老年代进行分配担保,也就是借用老年代的空间存储放不下的对象。
|
||||||
|
|
||||||
|
- **分代收集**
|
||||||
|
|
||||||
|
现在的商业虚拟机采用分代收集算法,它根据对象存活周期将内存划分为几块,不同块采用适当的收集算法。
|
||||||
|
|
||||||
|
一般将堆分为新生代和老年代。
|
||||||
|
|
||||||
|
- 新生代使用: 复制算法
|
||||||
|
- 老年代使用: 标记 - 清除 或者 标记 - 整理 算法
|
||||||
|
|
||||||
|
#### 分代收集算法和分区收集算法区别?
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
- **分代收集算法**
|
||||||
|
|
||||||
|
当前主流 VM 垃圾收集都采用”分代收集”(Generational Collection)算法, 这种算法会根据 对象存活周期的不同将内存划分为几块, 如 JVM 中的 新生代、老年代、永久代,这样就可以根据 各年代特点分别采用最适当的 GC 算法
|
||||||
|
|
||||||
|
在新生代-复制算法:
|
||||||
|
|
||||||
|
每次垃圾收集都能发现大批对象已死, 只有少量存活. 因此选用复制算法, 只需要付出少量 存活对象的复制成本就可以完成收集
|
||||||
|
|
||||||
|
在老年代-标记整理算法:
|
||||||
|
|
||||||
|
因为对象存活率高、没有额外空间对它进行分配担保, 就必须采用“标记—清理”或“标 记—整理”算法来进行回收, 不必进行内存复制, 且直接腾出空闲内存.
|
||||||
|
|
||||||
|
1. **ParNew**: 一款多线程的收集器,采用复制算法,主要工作在 Young 区,可以通过 `-XX:ParallelGCThreads` 参数来控制收集的线程数,整个过程都是 STW 的,常与 CMS 组合使用。
|
||||||
|
2. **CMS**: 以获取最短回收停顿时间为目标,采用“标记-清除”算法,分 4 大步进行垃圾收集,其中初始标记和重新标记会 STW ,多数应用于互联网站或者 B/S 系统的服务器端上,JDK9 被标记弃用,JDK14 被删除。
|
||||||
|
|
||||||
|
- **分区收集算法**
|
||||||
|
|
||||||
|
分区算法则将整个堆空间划分为连续的不同小区间, 每个小区间独立使用, 独立回收. 这样做的 好处是可以控制一次回收多少个小区间 , 根据目标停顿时间, 每次合理地回收若干个小区间(而不是 整个堆), 从而减少一次 GC 所产生的停顿。
|
||||||
|
|
||||||
|
1. **G1**: 一种服务器端的垃圾收集器,应用在多处理器和大容量内存环境中,在实现高吞吐量的同时,尽可能地满足垃圾收集暂停时间的要求。
|
||||||
|
2. **ZGC**: JDK11 中推出的一款低延迟垃圾回收器,适用于大内存低延迟服务的内存管理和回收,SPECjbb 2015 基准测试,在 128G 的大堆下,最大停顿时间才 1.68 ms,停顿时间远胜于 G1 和 CMS。
|
||||||
|
|
||||||
|
#### 什么是Minor GC、Major GC、Full GC?
|
||||||
|
|
||||||
|
JVM 在进行 GC 时,并非每次都对堆内存(新生代、老年代;方法区)区域一起回收的,大部分时候回收的都是指新生代。
|
||||||
|
|
||||||
|
针对 HotSpot VM 的实现,它里面的 GC 按照回收区域又分为两大类:部分收集(Partial GC),整堆收集(Full GC)
|
||||||
|
|
||||||
|
- 部分收集:不是完整收集整个 Java 堆的垃圾收集。其中又分为:
|
||||||
|
- 新生代收集(Minor GC/Young GC):只是新生代的垃圾收集
|
||||||
|
- 老年代收集(Major GC/Old GC):只是老年代的垃圾收集
|
||||||
|
- 目前,只有 CMS GC 会有单独收集老年代的行为
|
||||||
|
- 很多时候 Major GC 会和 Full GC 混合使用,需要具体分辨是老年代回收还是整堆回收
|
||||||
|
- 混合收集(Mixed GC):收集整个新生代以及部分老年代的垃圾收集
|
||||||
|
- 目前只有 G1 GC 会有这种行为
|
||||||
|
- 整堆收集(Full GC):收集整个 Java 堆和方法区的垃圾
|
||||||
Reference in New Issue
Block a user