当前位置：首页 > news >正文

图灵300题-21~40-笔记002

news 来源：原创 2025/7/26 14:49:53

图灵300题

图灵面试题视频：https://www.bilibili.com/video/BV17z421B7rB?spm_id_from=333.788.videopod.episodes&vd_source=be7914db0accdc2315623a7ad0709b85&p=20。
本文是学习笔记，如果需要面试没有时间阅读原博文，可以快速浏览笔记。
推荐深度阅读对应书籍或者知识点原文，避免碎片化学习。

21.Java中的异常体系

Java 的所有异常都来自顶层父类 Throwable。
Throwable 包含两个重要子类：Error 和 Exception。

Error：
表示程序运行过程中发生的严重错误，一旦出现此类错误，程序会被迫停止运行。
Exception：
表示程序运行时发生的异常，进一步分为两部分：
- RuntimeException（运行时异常）：
  通常由编程错误导致，例如空指针异常、数组越界异常等。
- 受检查的异常（Checked Exception）：
  多发生在编译期间，需要程序员通过显式使用 try-catch 块处理，或声明抛出的异常。

22. Java类加载器

JDK自带有三个类加载器：bootstrap ClassLoader、ExtClassLoader、AppClassLoader。

BootStrapClassLoader是ExtClassLoader的父类加载器，默认负责加载%JAVA_HOME%lib下的jar包和class文件。
ExtClassLoader是AppClassLoader的父类加载器，负责加载%JAVA_HOME%/lib/ext文件夹下的jar包和class类。
AppClassLoader是自定义类加载器的父类，负责加载classpath下的类文件。还可继承ClassLoader实现自定义类加载器。

23.类加载器双亲委派模型

Java 中存在的三层类加载器
BootstrapClassLoader
ExtensionClassLoader
AppClassLoader
双亲委派模型的工作机制
当一个类加载器（如 AppClassLoader）收到加载类的请求时，它首先不会尝试自己去加载这个类。在这个过程中，会先使用 findLoadedClass 方法来检查该类是否已经被加载过。如果没有被加载，类加载器不会自行去加载，而是把请求委派给父类加载器（ExtensionClassLoader），按照层级依次向上委派，父类加载器又会将请求委派给它自己的父类加载器（BootstrapClassLoader）。只有当父类加载器无法完成加载任务（即父类加载器返回 null）时，子类加载器才会尝试自己去加载这个类。这样可以避免重复加载，同时也保证了 Java 核心类库的安全性。

24. JVM判断对象可回收的方式

JVM判断对象是否可被回收主要有两种方式：

引用计数法：每个对象都有一个引用计数属性。当新增一个引用时，计数加1；引用释放时，计数减1。当引用计数为0时，该对象可被回收。然而，这种方法存在循环引用的问题，比如对象A引用对象B，对象B又引用对象A，即使它们都不再被其他部分的程序使用，由于相互引用，引用计数始终不为0，导致无法被回收。
可达性分析法：从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，证明此对象不可用，会被虚拟机判断为可回收对象。GC Roots包括以下几种对象：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象；
- 方法区中类静态属性引用的对象；
- 方法区中常量引用的对象；
- 本地方法栈中JNI（即一般说的Native方法）引用的对象。

需要注意的是，可达性算法中的不可达对象并非立即死亡，对象有一次自我拯救的机会。对象被系统宣告死亡至少要经历两次标记过程：第一次是经过可达性分析发现没有与GC Roots相连接的引用链；第二次是在由虚拟机自动建立的过程中。

25. JVM中的线程共享区

JVM运行时数据区中，堆区和方法区是所有线程共享的，而栈、本地方法栈、程序计数器是每个线程独有的。具体结构如下：

在这个结构中，堆区用于存放对象实例，方法区存储类的元数据、常量等信息，它们作为线程共享区，承担着重要的数据存储任务；而线程独有的区域则各自负责不同的线程执行相关功能。

26. JVM的垃圾回收算法

JVM常见的垃圾回收算法有以下几种：

Mark - Sweep标记清除算法：该算法分为标记和清除两个阶段。在标记阶段，会把垃圾内存标记出来；清除阶段则直接将标记的垃圾内存回收。这种算法虽然简单，但会产生大量的内存碎片，影响后续内存分配效率。
Copying拷贝算法：将内存按容量划分为大小相等的两块区域（一般称为 From Space 和 To Space），每次只使用其中一块。当这块内存使用完，进行垃圾回收时，会将还存活的对象一次性拷贝到另一块未使用的内存空间中，然后把原来使用的内存空间一次性清理掉。由于是将存活对象整体拷贝到新的区域，然后直接清理旧区域，所以清理过程非常高效，没有标记和清除的复杂操作，也不会产生内存碎片，使得内存分配更加连续和高效。需要将内存划分为两块，每次只能使用其中一半，这就导致内存的实际利用率只有 50% ，空间浪费较为严重。
Mark - Compack标记压缩算法：此算法的标记阶段和标记清除算法相同，但在完成标记之后，不是直接清理垃圾内存，将存活对象往内存一端移动，然后清除移动后存活对象所在区域边界之外的所有内存，有效解决了标记清除算法产生内存碎片的问题。

27. JVM的垃圾回收器及相关概念

这部分内容主要涉及JVM垃圾回收器的类型、工作原理，以及STW、三色标记等相关概念。

STW（Stop - The - World）：是垃圾回收算法执行过程中，将JVM内存冻结的一种状态。在STW状态下，除了GC线程外，Java的所有线程都停止执行，native方法虽然可以执行，但不能与JVM交互。减少STW时间是GC算法优化以及JVM调优的重点。
垃圾回收器分类及工作方式：
- Serial串行回收器：整体过程简单，进行GC时直接暂停，GC完成后继续。它是早期的垃圾回收器，仅由一个线程执行GC操作。在多CPU架构下，性能会严重下降，适用于几十兆的小内存空间。
- Parallel并行回收器：在串行回收器的基础上增加了多线程GC功能。PS + PO组合是JDK1.8默认的垃圾回收器，在多CPU架构下性能比Serial回收器高很多。
- CMS（Concurrent Mark Sweep）回收器：核心思想是将STW时间打散，使部分GC线程与用户线程并发执行。整个GC过程分为四个阶段：
  - 初始标记阶段：STW，仅标记出根对象直接引用的对象；
  - 并发标记：与应用程序并发执行，继续标记其他对象；
  - 重新标记：STW，对并发执行阶段的对象进行重新标记；
  - 并发清除：并行清除垃圾。但在清除过程中，应用程序会不断产生新的垃圾，即浮动垃圾，这些垃圾需留到下一次GC过程处理。
- G1回收器：其内存模型实际不分代，但逻辑上进行分代。堆内存不再划分老年代和新生代，而是被划分为一个个小内存块，称为Region，每个Region可隶属于不同年代。逻辑分代是通过不同 Region 承担类似传统分代中新生代和老年代的功能。GC分为五个阶段：
  - 初始标记：标记出GCRoot直接引用的对象，STW；
  - 标记Region：通过RSet标记出上一阶段标记的Region引用到的Old区Region；
  - 并发标记阶段：与CMS的步骤类似，但遍历范围仅为第二步标记出的Region；
  - 重新标记：与CMS中的重新标记过程相似；
  - 垃圾清理：与CMS不同，G1可采用拷贝算法，直接将整个Region中的对象拷贝到另一个Region，且此阶段只选择垃圾较多的Region进行清理。

28.三色标记算法

三色标记算法是一种在并发垃圾回收中常用的算法，它将对象标记为三种颜色：白色、灰色和黑色，以此来追踪对象的引用关系，判断对象是否存活。

白色对象：表示尚未被垃圾回收器访问过的对象，在垃圾回收开始阶段，所有对象默认都是白色。
灰色对象：表示自身被访问过，但它引用的对象还未全部被访问的对象。也就是说，灰色对象是那些已经被发现，但它所关联的对象还在待检查状态。
黑色对象：表示自身以及它引用的所有对象都已经被访问过的对象。在垃圾回收过程结束时，黑色对象被认为是存活的对象，白色对象则被判定为垃圾对象（在没有漏标和错标情况下）。

执行过程

初始标记阶段：从GC Roots开始扫描，将直接关联的对象标记为灰色，这一阶段会产生STW（Stop-The-World），暂停用户线程，以确保标记的准确性。
并发标记阶段：垃圾回收器开始并发地遍历灰色对象，将其引用的对象标记为灰色，同时把自身标记为黑色，放入黑色集合中。在这个过程中，用户线程可以继续运行，新创建的对象会被标记为白色。由于用户线程和垃圾回收线程并发执行，可能会出现对象引用关系的变化，这就可能导致错标记和漏标记问题。
最终标记阶段：再次短暂STW，处理并发标记阶段因用户线程执行导致的引用关系变化，确保所有存活对象都被正确标记为黑色，所有垃圾对象都为白色。

错标记和漏标记问题及解决方法

错标记问题：在并发标记阶段，由于用户线程和垃圾回收线程并发执行，可能会出现将垃圾对象错误标记为存活对象（即错标记为黑色）的情况。例如，一个白色对象原本是垃圾对象，但在垃圾回收器扫描到它之前，被一个灰色对象引用了，之后垃圾回收器将这个灰色对象及其引用的白色对象都标记为黑色，导致垃圾对象未被回收。
漏标记问题：是指将存活对象错误标记为垃圾对象（即漏标记为白色）的情况。比如，在并发标记过程中，一个黑色对象原本引用了一个白色对象（该白色对象是存活的），但在垃圾回收器扫描完这个黑色对象之后，用户线程将这个引用断开了，同时另一个灰色对象引用了这个白色对象，但由于垃圾回收器已经扫描过这个灰色对象，没有重新扫描它引用的对象，就导致这个白色存活对象被误判为垃圾对象。
解决方法：为了解决错标记和漏标记问题，通常采用“增量更新”和“原始快照”（SATB，Snapshot At The Beginning）这两种策略。
- 增量更新：当一个黑色对象引用了一个白色对象时，将这个引用关系记录下来（可以通过写屏障实现），在最终标记阶段重新扫描这些记录的引用关系，确保白色对象被正确标记。
- 原始快照：在垃圾回收开始时，对对象的引用关系进行一次快照记录。在并发标记过程中，当发现对象的引用关系发生变化时，对比快照中的引用关系，如果发现有对象的引用被删除，就将这个对象标记为灰色，确保其不会被误判为垃圾对象。

优势与意义

提高并发性能：三色标记算法允许垃圾回收器在一定程度上与用户线程并发执行，减少了垃圾回收过程中STW的时间，提高了系统的整体性能和响应速度。
适用于现代JVM：在现代JVM的垃圾回收器中，如CMS（Concurrent Mark Sweep）和G1（Garbage-First）等，三色标记算法都发挥着重要作用，帮助这些垃圾回收器实现高效的并发垃圾回收，更好地管理内存资源。

29. 确定对象是否为垃圾及GC Root的概念

确定一个对象是否为垃圾有以下两种方式：

引用计数：给堆内存中的每个对象记录一个引用个数，当引用个数为0时，认为该对象是垃圾。这是早期JDK使用的方式，但无法解决循环引用问题。
根可达算法：从内存中的引用根对象向下查找引用，找不到引用的对象即为垃圾。GC Root包括虚拟机栈（栈帧中的本地变量表）中引用的对象以及本地方法栈中引用的对象、class类、运行时常量池（run - time constant pool）、静态变量（static reference）。

30. 项目中排查JVM问题的方法

排查JVM问题，根据系统状态不同，有不同的排查方法：

对于正常运行的系统：
- 可以使用jmap查看JVM中各个区域的使用情况；
- 通过jstack查看线程的运行情况，比如是否有线程阻塞、是否出现死锁等；
- 利用jstat命令查看垃圾回收情况，尤其是fullgc，若发现fullgc频繁，就需要进行调优；
- 通过上述命令的结果，或者借助jvisualvm等工具进行分析；
- 初步猜测频繁发生fullgc的原因，如果频繁发生fullgc但未出现内存问题，说明fullgc回收了很多对象，这些对象最好在younggc阶段就被回收，避免进入老年代。此时可考虑是否因为存活时间不长的对象较大，导致年轻代放不下而直接进入老年代，尝试加大年轻代大小，若修改后fullgc减少，则证明修改有效；
- 找到占用CPU最多的线程，定位到具体方法，优化该方法的执行，看是否能避免某些对象的创建，从而节省内存。
对于发生OOM的系统：
- 一般在生产系统中会设置当系统发生OOM时，生成当时的dump文件（-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/base）；
- 使用jsisualvm等工具分析dump文件；
- 根据dump文件找到异常的实例对象和占用CPU高的异常线程，定位到具体代码；
- 然后进行详细的分析和调试。

JVM调优是一个反复的过程，需要不断分析、推理、实践、总结，才能最终定位并解决问题。

31. 线程的生命周期与状态

线程通常具有五种状态：

新建状态（New）：新创建了一个线程对象，此时线程尚未启动。
就绪状态（Runnable）：线程对象创建后，其他线程调用了其start方法，该线程进入可运行线程池，等待获取CPU使用权。
运行状态（Running）：就绪状态的线程获取到CPU资源，开始执行程序代码。
阻塞状态（Blocked）：线程因某种原因放弃CPU使用权，暂时停止运行。阻塞状态又分为以下三种情况：
- 等待阻塞：运行的线程执行wait方法，会释放占用的所有资源，JVM将其放入“等待池”。该状态下线程不能自动唤醒，必须依靠其他线程调用notify或notifyAll方法才能被唤醒，wait是Object类的方法；
- 同步阻塞：运行的线程在获取对象的同步锁时，若同步锁被其他线程占用，VM会把该线程放入“锁池”；
- 其他阻塞：运行的线程执行sleep或join方法，或者发出I/O请求时，JVM会将其置为阻塞状态。当sleep状态超时、join等待的线程终止或超时、或者I/O处理完毕时，线程重新转入就绪状态，sleep是Thread类的方法。
死亡状态：线程执行完所有任务或出现异常等情况后，生命周期结束。

PS:spring源码注解只有阻塞状态，没有细分。

32. sleep()、wait()、join()、yield()的区别

这几个方法在功能和使用场景上存在明显区别：

锁池和等待池：所有竞争同步锁的线程会被放入锁池。当对象的锁被某个线程获取后，其他线程需在锁池等待。当前面的线程释放同步锁后，锁池中的线程竞争同步锁，获取锁的线程进入就绪队列等待CPU资源分配。调用wait()方法后，线程会进入等待池，等待池中的线程不会竞争同步锁。只有调用notify()或notifyAll()后，等待池中的线程才会开始竞争锁，notify()随机从等待池选择一个线程放入锁池，notifyAll()则将等待池中的所有线程放入锁池。
方法区别：
- sleep是Thread类的静态本地方法，wait是Object类的本地方法；
- sleep方法不会释放lock，而wait会释放并加入等待队列。sleep会释放CPU执行资格和执行权，暂停线程运行，定时时间结束后重新获取CPU资源参与调度。若sleep时线程持有锁，该锁不会被释放，其他需要该锁的线程无法获取。如果在睡眠期间其他线程调用该线程的interrupt方法，线程会抛出InterruptedException异常返回，这点和wait相同；
- sleep方法不依赖于同步器synchronized，而wait需要依赖synchronized关键字；
- sleep不需要被唤醒（休眠结束后自动退出阻塞），wait则需要（不指定时间时需被其他线程中断）；
- sleep一般用于当前线程休眠或轮循暂停操作，wait多用于多线程之间的通信；
- sleep会让出CPU执行时间并强制上下文切换，wait则不一定，wait后可能有机会重新竞争到锁继续执行。
- yield()执行后线程直接进入就绪状态，释放CPU执行权，但保留CPU执行资格，因此下次CPU调度时该线程仍有可能获取执行权继续执行。
- join()执行后线程进入阻塞状态，例如在线程B中调用线程A的join()，线程B会进入阻塞队列，直到线程A结束或被中断。

33. 对线程安全的理解

线程安全本质上与内存安全相关。堆是共享内存，可被所有线程访问。当多个线程访问一个对象时，若无需额外的同步控制或协调操作，调用该对象的行为能获得正确结果，则称这个对象是线程安全的。

堆是进程和线程共有的空间，分为全局堆和局部堆。全局堆是未分配的空间，局部堆是用户分配的空间。堆在操作系统初始化进程时分配，运行过程中可向系统申请额外堆空间，使用完毕后需归还，否则会导致内存泄漏。

在Java中，堆是Java虚拟机管理的内存中最大的一块，是所有线程共享的内存区域，在虚拟机启动时创建，主要用于存放对象实例和数组。

栈是每个线程独有的，用于保存线程运行状态和局部自动变量。栈在线程启动时初始化，每个线程的栈相互独立，因此栈是线程安全的。操作系统在切换线程时会自动切换栈。栈空间无需在高级语言中显式分配和释放。

主流操作系统大多是多任务的，每个进程只能访问分配给自己的内存空间，这由操作系统保障。进程内的所有线程都可访问堆内存，这是可能出现线程安全问题的潜在原因。

34. 守护线程的理解

守护线程是为所有非守护线程提供服务的线程，它依赖整个进程运行，自身生死对进程影响不大。当所有非守护线程结束，程序结束时，守护线程会被直接中断。
使用守护线程时需要注意以下几点：

由于守护线程的终止不可控，不要将IO、文件操作等重要逻辑分配给它；
GC垃圾回收线程是经典的守护线程。当程序中没有运行的线程，不再产生垃圾时，垃圾回收器无事可做，此时若垃圾回收线程是JVM上仅剩的线程，它会自动离开。它在低级状态运行，实时监控和管理系统中的可回收资源；
应用场景方面，适合为其他线程提供服务支持，或者在程序结束时无需关注其是否正常结束的场景。对于关键事务，如数据库录入或更新等不能中断的操作，不应使用守护线程；
使用thread.setDaemon(true)设置线程为守护线程时，必须在thread.start()之前，否则会抛出IllegalThreadStateException异常。正在运行的常规线程不能被设置为守护线程；
在Daemon线程中产生的新线程也是Daemon线程；
守护线程不能用于访问固有资源，如读写操作或计算逻辑，因为它可能在任何时候甚至操作中途被中断；
Java自带的多线程框架，如ExecutorService，会将守护线程转换为用户线程，所以在该框架中使用后台线程时不能直接使用守护线程。

35. ThreadLocal的底层原理

ThreadLocal是Java提供的线程本地存储机制，可将数据缓存在某个线程内部，该线程能在任意时刻、任意方法中获取缓存数据。
其底层通过ThreadLocalMap实现，每个Thread对象（注意不是Threadlocal对象）都有一个ThreadlocalMap。ThreadlocalMap的key为ThreadLocal对象，value为需要缓存的值。

在线程池中使用ThreadLocal可能会导致内存泄漏。因为ThreadLocal对象使用完后，其设置的key、value（即Entry对象）应被回收，但线程池中的线程不会回收，线程对象通过强引用指向ThreadlocalMap，ThreadLocalMap又通过强引用指向Entry对象，从而导致Entry对象无法被回收。解决办法是在使用完Threadlocal对象后，手动调用其remove方法，清除Entry对象。

ThreadLocal的经典应用场景是连接管理，即一个线程持有一个连接，该连接对象可在不同方法间传递，且线程之间不共享同一个连接。

36. 并发、并行、串行的区别

串行：在时间上不存在重叠，前一个任务完成后，下一个任务才会开始。例如单线程依次处理多个文件的读写操作，必须按顺序逐个进行。
并行：多个任务在同一时刻同时执行，互不干扰。就像多核CPU可以同时处理不同的任务，提高整体处理效率。
并发：允许多个任务相互干扰。在同一时间点，只有一个任务在运行，但多个任务可交替执行。例如在单线程环境下，多个任务通过时间片轮转的方式交替执行，从宏观上看好像是同时进行。

37. 并发的三大特性

并发的三大特性涉及关键字volatile、synchronized、final ，具体内容如下：

有序性：虚拟机在编译代码时，对于改变顺序后不影响最终结果的代码，可能会进行重排序。虽然重排序对变量值可能无影响，但在多线程环境下可能导致线程安全问题。例如，对共享变量的操作顺序若被重排序，可能使数据不一致。
原子性：原子性指一个操作在CPU执行过程中不会被中断，要么全部执行完成，要么都不执行。以转账操作为例，从账户A向账户B转1000元，包含从账户A减去1000元，往账户B加上1000元这两个操作，这两个操作必须全部完成，否则会出现数据错误。关键字synchronized可保证操作的原子性。
可见性：当多个线程访问同一个变量时，一个线程修改变量值后，其他线程能立即看到修改后的结果。若两个线程在不同CPU上，线程1修改变量i的值后未刷新到主存，线程2使用i时，获取的仍是之前的值，这就是可见性问题。volatile关键字可保证变量的可见性，确保一个线程对变量的修改能及时被其他线程看到。

38. Java死锁的避免方法

造成死锁的原因：
- 资源独占性：一个资源每次只能被一个线程使用。
- 不可剥夺条件：一个线程在阻塞等待某个资源时，不会释放已占有的资源。
- 占有并等待：一个线程已经获得了一些资源，在未使用完之前，不能被强行剥夺。
- 循环等待：若干线程形成头尾相接的循环等待资源关系。只有这四个条件同时满足，才会产生死锁。
避免死锁的策略：在开发过程中，要避免死锁，只需破坏其中一个条件即可。由于前三个条件是锁的基本特性，难以改变，所以通常通过破坏循环等待条件来避免死锁。具体措施如下：
- 控制加锁顺序：保证每个线程按照相同的顺序获取锁。比如，如果线程A获取锁的顺序是lock1、lock2，那么其他线程也应遵循同样的顺序，这样可以有效避免循环等待锁的情况发生。
- 设置加锁时限：为锁设置一个超时时间。当线程等待锁的时间超过该时限时，线程放弃等待并释放已持有的资源，从而打破死锁的条件。
- 实施死锁检测：采用特定的工具或算法，定期检查系统中是否存在死锁。一旦发现死锁，及时采取措施进行解决，这是一种有效的预防机制。

39. 使用线程池的原因及线程池参数解析

使用线程池的原因：
- 降低资源消耗：通过复用已创建的线程，减少线程创建和销毁带来的资源开销，提高线程的利用率。
- 提高响应速度：当任务到达时，线程池中已有可用线程，无需等待线程创建即可立即执行任务，从而加快系统的响应速度。
- 便于线程管理：线程是宝贵的资源，使用线程池可以对线程进行统一的分配、调优和监控，增强线程的可管理性。
线程池参数解析：
- corePoolSize：表示核心线程数，即正常情况下创建的工作线程数量。这些线程创建后会一直存在，不会被轻易销毁，属于常驻线程。例如，在一个Web服务器线程池中，可根据日常平均请求量设置合适的核心线程数。
- maximumPoolSize：代表最大线程数，与核心线程数相对应。当任务量增加，核心线程数被用完且任务队列已满时，线程池会创建新的线程，但线程总数不会超过最大线程数。
- keepAliveTime、unit：用于设置超出核心线程数之外的线程的空闲存活时间。核心线程不会被销毁，而超出核心线程数的部分线程如果在指定的空闲时间内没有任务执行，就会被销毁。可以通过setKeepAliveTime方法来设置这个空闲时间。
- workQueue：用于存放等待执行的任务。当核心线程都在忙碌时，新的任务会被放入队列中。当队列已满且任务仍持续进入时，线程池会开始创建新的线程来处理任务。
- ThreadFactory：是一个线程工厂，负责创建执行任务的线程。可以使用默认的线程工厂，其创建的线程都在同一个组内，具有相同的优先级，且都不是守护线程。也可以根据业务需求自定义线程工厂。
- Handler：即任务拒绝策略。当出现以下两种情况时会触发任务拒绝：一是调用shutdown等方法关闭线程池后，若此时还有任务提交，线程池会拒绝；二是当线程池达到最大线程数，且任务队列已满，无法再处理新提交的任务时，也会拒绝该任务。